Rate limits
Every API key on your account shares two limits:
- A request rate. It works like a token bucket: you can send your plan’s burst all at once, and it refills at your plan’s sustained rate.
- A monthly allowance. This is the total number of requests your plan includes for each billing period.
Only successful responses (2xx and 304) count against the allowance. Errors, including 403, 404 and 429, are free.
When you hit a limit
Both limits answer with 429 Too Many Requests, a Retry-After header in seconds, and no data. The problem code says which limit you hit:
If the API briefly can’t check your account or its limits, it returns 503 with code unavailable rather than serving the request unmetered. Wait Retry-After seconds and try again.
Usage headers
Every response that counts toward your limits carries two headers, including errors and 429s. They follow the IETF RateLimit header fields draft.
Some things to keep in mind:
ris a snapshot. A response that doesn’t count, such as an error, reportsrunchanged. Your other keys draw from the same allowance, so the next response can report less than you expect.Retry-Afterwins. Onquota_exhausted,ris0andtequalsRetry-After. Onrate_limited,rcan still be positive, because the rate limit isn’t reported in these headers. FollowRetry-Aftereither way.- Some responses don’t carry the headers. A
401, a403for an account without active access, a503, or a request from a plan without REST access is rejected before it’s counted. - Parse the headers leniently. They’re Structured Field lists. Ignore policies and parameters you don’t recognize, because more may be added.