Rate limiting
The API is limited to 60 requests per minute per account by default. Exceeding the limit returns `429 Too Many Requests`. Requests may occasionally be throttled with the same status code during periods of high load.
Rate-limit headers
Every response includes headers describing your current rate-limit window so you can pace requests without guessing.
Response headers
| Parameter | 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 | integer | Unix timestamp (seconds) when the window resets. |
Retry-After | integer | On a `429`, the number of seconds to wait before retrying. |
Handling 429 responses
- When you receive a `429`, read the `Retry-After` header and pause for that many seconds.
- Retry the request with exponential backoff (for example, 1s, 2s, 4s) plus a little random jitter.
- Keep your steady-state request rate under the limit by spacing calls or queueing work.
- For large batch jobs, prefer endpoints that accept multiple inputs per request over many single-item calls.
Design for idempotent retries
Read endpoints (GET) are safe to retry. For metered operations, a `429` means the request was rejected before any credits were charged - retrying does not double-charge.