All API endpoints are rate-limited to protect the service. Rate limits are enforced per IP address and backed by Redis.
Every response includes the following headers:
| Header | Type | Description |
|---|
X-RateLimit-Limit | integer | Maximum requests allowed in the current window |
X-RateLimit-Remaining | integer | Requests remaining in the current window |
X-RateLimit-Reset | number | Unix timestamp (seconds) when the window resets |
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 42
X-RateLimit-Reset: 1711234567
Rate limit windows
Different endpoint groups have different limits:
| Endpoint group | Limit | Window |
|---|
| Conversations | 60 requests | 1 minute |
| Audit log | 30 requests | 1 minute |
| Audit log export | 10 requests | 1 minute |
| Community (public) | 30 requests | 1 minute |
| Stats (public) | 30 requests | 1 minute |
| Moderation | 120 requests | 15 minutes |
| Warnings | 120 requests | 15 minutes |
| Members | 120 requests | 15 minutes |
| OAuth initiation | 10 requests | 15 minutes |
| OAuth callback | 10 requests | 1 minute |
When you are rate limited
When you exceed the rate limit, the API returns a 429 Too Many Requests response:
{
"error": "Too many requests"
}
X-RateLimit-Reset to determine when you can retry.
# Example 429 response headers
HTTP/1.1 429 Too Many Requests
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1711234600
Best practices
- Check
X-RateLimit-Remaining before making requests in a loop.
- When you receive a
429, wait until X-RateLimit-Reset before retrying.
- Use exponential backoff for retries to avoid hammering the server.
- Cache responses where possible — public endpoints like
/community and /stats already have server-side Redis caching.
Rate limiting is backed by Redis. If Redis is unavailable, rate limiting falls back to in-memory tracking per process.
