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.

On this page