Per-token request limits and the headers that report them.
Each token has two limits. A request must fit within both.
| Limit | Value |
|---|---|
| Sustained | 600 requests per minute |
| Burst | 100 requests per 10 seconds |
Limits apply per token. One token reaching its limit does not affect your other tokens.
Headers
Every response reports the token's current state:
| Header | Description |
|---|---|
X-RateLimit-Limit | Sustained limit (600). |
X-RateLimit-Remaining | Requests left in the current sustained window. |
X-RateLimit-Reset | Unix timestamp, in seconds, when the sustained window resets. |
X-RateLimit-Burst-Limit | Burst limit (100). |
X-RateLimit-Burst-Remaining | Requests left in the current burst window. |
X-RateLimit-Burst-Reset | Unix timestamp, in seconds, when the burst window resets. |
Exceeding a limit
The API returns 429 with a Retry-After header giving the number of seconds to wait:
HTTP/1.1 429 Too Many Requests
Retry-After: 4
X-RateLimit-Burst-Remaining: 0
{ "error": { "code": "rate_limit_exceeded", "message": "Rate limit exceeded" } }Recommendations
- Wait for
Retry-Afterbefore retrying. Retrying earlier fails again. - Use
limit=50on lists to fetch more records per request. - Sync incrementally with
updatedAfterinstead of re-reading full lists. - Spread scheduled jobs over time rather than starting them all at once.