Rate Limits

Response Headers

Every API response includes rate limit headers:

429 Too Many Requests

When you exceed your rate limit, the API returns:

HTTP/1.1 429 Too Many Requests
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1741305660

{
  "error": {
    "code": "RATE_LIMIT_EXCEEDED",
    "message": "Rate limit exceeded. Retry after 1741305660."
  }
}

Best Practices

• Check headers proactively — Monitor X-RateLimit-Remaining to throttle before hitting the limit.
• Use exponential backoff — On 429, wait until X-RateLimit-Reset before retrying. Add jitter to avoid thundering herd.
• Batch where possible — Use batch endpoints (e.g. POST /v1/compliance/batch/status) instead of individual calls.
• Use webhooks — Instead of polling for status changes, subscribe to webhook events to reduce API calls.
• Separate keys by use case — Use different API keys for different services so one noisy service doesn't exhaust the limit for others.

Implementation Details

Rate limiting uses a Redis sorted set sliding window. Each request adds an entry with the current timestamp. The window spans 60 seconds. Expired entries are pruned on each request. This provides smooth, accurate rate limiting without the burst issues of fixed windows.