Skip to content
TRIM FITTv1 · read
↑↓ to move↵ to openesc to close
Contents

Reference

Rate limits

Three ceilings, all enforced server-side. The minute window stops bursts; the day windows are the sustained budget.

The ceilings#

LimitValueWindow
Per credential, burst120 requestsminute
Per credential, sustained20,000 requestsday
Per partner, sustained60,000 requestsday

The partner ceiling is per organisation, so minting more keys does not multiply it. A single key therefore sustains about two requests per second, and a partner about 0.7 per second on average.

When you hit one#

The response is 429 rate_limited with headers that say when to come back:

http · 429
HTTP/1.1 429 Too Many Requests
retry-after: 12
ratelimit-limit: 120
ratelimit-remaining: 0
ratelimit-reset: 12

Retry-After and RateLimit-Reset are both delta-seconds.

Staying under them#

  • Cache the catalogue. It changes rarely. A full walk is around two pages at limit=100; do it on a schedule, not per user action.
  • Back off with jitter. Honour Retry-After, then add jitter so a fleet does not retry in lockstep.
  • Never retry a 401 or a 403. They cannot succeed on retry.
  • Retry a 503 with the same key, after Retry-After. It means we could not check, not that the key is wrong.

Need more?

If your design needs more than two requests per second on one key for a sustained period, talk to us before you build around it. The limits are a contract, and changing them is a deliberate decision rather than a workaround.

Related: errors and retries.