Rate Limits

The API is rate-limited to keep one integration's traffic from affecting another's.

How the limit is partitioned

Authenticated requests are limited per credential — that is, per bearer token, keyed on its tokenid. Your token's budget is yours alone: another partner's traffic, or another of your own tokens, cannot consume it. This is why rotating to a fresh token gives you a fresh budget, and why splitting heavy workloads across separate issued tokens is a legitimate scaling strategy.

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 PUT 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.