API guides

Rate limits

Per key, with the headers to steer by.

Limits are counted per key, not per organization and not per IP. Two integrations with their own keys never spend each other’s budget — one more reason to mint a key per integration.

The headers

  • X-RateLimit-Limit — the key’s per-minute allowance.
  • X-RateLimit-Remaining — what is left in the current minute.
  • Retry-After — on a 429 only: seconds until the exhausted window resets.

The defaults are 120 requests a minute and 10,000 a day. Read the headers rather than hard-coding those numbers: they are what this deployment is actually enforcing, and the published contract is where any change to them appears first.

When you are limited

HTTPCodeWhen
429rate_limitedPer-key limit exhausted (default 120/min, 10,000/day). Honor `Retry-After`.

A 429 comes back in the standard envelope with Retry-After. Honoring it means waiting — sleep the interval, then continue. Retrying immediately, or in a tight loop across several workers, keeps the window exhausted and turns a pause into an outage of your own making. Rejected requests still count.

Staying under

  • Page with limit=100 rather than making five times as many small calls.
  • Filter with since / until instead of re-reading history on every run.
  • Spread scheduled jobs. Three syncs that all start on the hour are one burst; a minute apart they are three comfortable ones.
  • Back off exponentially on repeated 429s, with a little jitter, so a fleet of workers doesn’t retry in lockstep.
X-RateLimit-Remaining is the cheapest signal you have. If it is trending toward zero on every run, the fix is usually a narrower query, not a faster retry.