Rate limits

RateLimit headers, 429 responses and Retry-After.

The API limits how many requests a key can make in a window of time, so one runaway program cannot slow the service for everyone. Every response tells you where you stand.

Rate limit headers

HeaderMeaning
RateLimit-LimitRequests allowed in the current window.
RateLimit-RemainingRequests left in the current window.
RateLimit-ResetSeconds until the window resets.
Retry-AfterSent with a 429: seconds to wait before retrying.
Response headers
HTTP/1.1 200 OK
Request-Id: req_3f9a1c7e5b2d4a6c8e0f1a2b
RateLimit-Limit: 60
RateLimit-Remaining: 57
RateLimit-Reset: 42

Current limits

  • 60 requests per minute for each API key. This is the limit the headers report.
  • 300 requests per minute from one IP address, across all keys.
  • Repeated requests with a missing or wrong key temporarily block the address they come from.

Limits can change. Read the headers rather than hard-coding a number.

When you exceed the limit

The API returns 429 with the error code rate_limited and a Retry-After header. Wait that many seconds, then retry the same request.

Error response · 429
{
  "error": {
    "type": "rate_limit_error",
    "code": "rate_limited",
    "message": "Too many requests. Retry after 12 seconds.",
    "request_id": "req_3f9a1c7e5b2d4a6c8e0f1a2b"
  }
}

Staying under the limit

  • Check RateLimit-Remaining and slow down before it reaches zero.
  • Request up to limit=100 objects per page rather than many small pages. See Pagination.
  • Retry with exponential backoff and a little random jitter, and always honour Retry-After.
  • Use one key per program so one busy job cannot starve another.