Rate limits

API requests are limited per key and per plan. See the limit on each plan and how to handle a 429 response.

Rate limits by plan

Authenticated requests are limited per API key and per account plan. The stricter bucket controls the response headers for the current request.

The limit is counted per clock minute: each count starts at zero on the minute and ends at the next, so it is a fixed window, not a rolling 60 seconds and not a per-second cap. X-RateLimit-Reset is the end of the current window, in Unix seconds. There is no separate requests-per-second ceiling to pace against. Spread requests evenly across the minute and the window never fills early.

Handling 429s

When a key or account window is exhausted, the API returns 429 with rate-limit headers and Retry-After, the whole seconds until that window ends. Wait that long, then retry; back off exponentially only when a 429 carries no Retry-After:

{
  "success": false,
  "error": {
    "code": "RATE_LIMITED",
    "message": "Rate limit exceeded. Retry after 37 seconds.",
    "request_id": "10cf9db1-90f7-493f-ab85-93e1e155c18f"
  }
}

Use X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, X-RateLimit-Policy, and Retry-After to pace retries.

Best practices

• On a 429, wait for Retry-After (or until X-RateLimit-Reset); use exponential backoff with jitter only when neither header is present
• Use batch endpoints to reduce request count
• Cache verification results when appropriate