The API is rate limited per API key to keep the platform fast and fair. Design integrations to observe the limit headers and back off when throttled.
Limit headers
Every response includes your current standing:
| Header | Meaning |
|---|---|
X-RateLimit-Limit | Requests allowed in the current window |
X-RateLimit-Remaining | Requests left in the window |
X-RateLimit-Reset | Unix time when the window resets |
When you exceed it
A throttled request returns 429 Too Many Requests with a Retry-After header
(seconds to wait):
HTTP/1.1 429 Too Many Requests
Retry-After: 12
Wait at least Retry-After seconds before retrying.
Backoff strategy
Tip
Use exponential backoff with jitter: on a 429 or 5xx, wait, then retry with a progressively longer delay plus a small random offset. This avoids retry storms where every client retries in lockstep.
- Respect
Retry-Afterwhen present. - Cap total retries; surface a clear error after the cap.
- Treat
5xxas retryable; treat4xx(other than429) as a bug to fix, not retry.
Avoiding limits
- Subscribe to webhooks instead of polling.
- Request only what you need — filter with
sinceand page withcursor. - Cache responses that do not change often.
- Use one key per integration so a noisy job cannot throttle a critical one.