Skip to main content
Every response carries its own limits, so a client can pace itself instead of discovering them by being refused. The headers follow the IETF RateLimit draft.

Headers

integer
The ceiling of the tightest policy that applies to this request.
integer
Requests left in the current window for that policy.
integer
Seconds until that window resets.
string
Every policy that applies, so a burst ceiling is discoverable without hitting it, for example "burst";q=30;w=1, "sustained";q=120;w=60.
Each request is counted against the API key, so one partner’s traffic never spends another’s budget. A key carries a burst policy (per second) beside its sustained one (per minute): a per-minute quota alone lets a client spend the whole minute in one second, and that spike is what the burst limit smooths out.

When you are limited

A refused request is answered 429 with the standard error envelope and a Retry-After header. The detail names which policy was hit and how long to wait - a burst clears in a second, the sustained window in a minute:

Pacing

  • Read RateLimit-Remaining and slow down before it reaches zero.
  • On a 429, wait for Retry-After seconds, then retry. Do not hammer.
  • Back off exponentially if 429s persist.

Handling it in code

Retry on 429, honoring Retry-After, and give up after a few attempts so a sustained limit does not become an infinite loop.