Rate limits
Per-key limits, the response headers, and how to behave on 429.
Every key carries its own request limit — 10 requests per minute by default, measured over a rolling 60-second window. The limit is per-key configuration on our side: if your integration legitimately needs more headroom, ask your account contact; it's a setting change, not a code change.
For a typical sync (a page of 1000 loads per request, polling twice a day), the default limit is far more than you'll ever touch.
Response headers
Every authenticated response includes:
| Header | Meaning |
|---|---|
X-RateLimit-Limit | Your key's per-minute cap. |
X-RateLimit-Remaining | Requests left in the current window. |
X-RateLimit-Reset | Unix epoch seconds when the window resets. |
When you exceed the limit
The API returns 429 with a Retry-After header (seconds):
HTTP/1.1 429 Too Many Requests
Retry-After: 22
X-RateLimit-Limit: 10
X-RateLimit-Remaining: 0
{"error": "Rate limit exceeded"}Wait Retry-After seconds and resume. Two details worth knowing:
- Refused requests don't consume quota. A burst of 429s doesn't dig you deeper into the hole; the window drains on schedule.
- The window is rolling, not aligned to clock minutes —
Retry-Afteris the accurate signal, not "wait until the next minute".
If you page through large result sets, a simple
if remaining == 0: sleep until reset check between page fetches is
all the client-side throttling you need.