Rate Limits
Requests are limited per credential. The default is 500 requests per minute. Exceeding it returns 429 with a Retry-After header.
The API is rate-limited to keep one integration's traffic from affecting another's.
The default limit
The default limit is 500 requests per minute, per credential. Your token's budget is yours alone: another partner's traffic cannot consume it.
Requests that arrive without a valid token share a single small budget, so unauthenticated traffic can never eat into authenticated capacity.
When you exceed it
Over the limit, the API returns 429 with the standard envelope and a Retry-After header (in
seconds):
HTTP/1.1 429 Too Many Requests
Retry-After: 42
Content-Type: application/json{
"error": {
"code": "rate_limited",
"message": "Too many requests. Retry after the period indicated.",
"requestid": "8f3c1a9b2d7e4f60"
}
}Handling it well
- Honour
Retry-After. Wait the indicated number of seconds before retrying. Don't hammer. - Back off on repeats. If you keep hitting the limit, add exponential backoff with jitter rather than retrying on a fixed interval.
- Batch where you can. A single settings update with several keys is one request; several single-key writes are several. Prefer the former.
- Spread scheduled work. If you run periodic syncs, stagger them rather than firing everything at the top of the minute.
If your integration has a legitimate need for a higher limit, talk to your platform contact. Treat
Retry-After as the source of truth for when to retry.