Rate limits
What each key and each IP address may send, and the headers that tell you where you stand.
Each key may make 120 requests per 60 seconds unless its limit was raised, and each client IP address 300. Every authenticated response tells you where you stand, in the IETF RateLimit header fields and the common X-RateLimit-* headers:
| Header | Example | Meaning |
|---|---|---|
RateLimit-Policy | "key";q=120;w=60 | The policy: q requests per w seconds. |
RateLimit | "key";r=87;t=34 | r requests left; the window resets in t seconds. |
X-RateLimit-Limit | 120 | Requests allowed per window. |
X-RateLimit-Remaining | 87 | Requests left in this window. |
X-RateLimit-Reset | 1762165234 | When the window resets, in Unix seconds. |
Retry-After | 34 | On 429 only: seconds to wait before retrying. |
Over the limit you get 429 Too Many Requests. Wait for Retry-After seconds, then retry; spread requests out rather than retrying in a loop.
The two limits
The per-key limit is the one you'll normally see. It counts every request made with the key, including GET /auth/verify, and its current state is in the rateLimit field of that endpoint's response. Ask support to raise it if your integration needs more.
The per-IP limit is applied before authentication, so unauthenticated and refused requests count too: 300 requests per minute from one address, and at most 30 failed authentications per minute from it. Several keys calling from the same server share this limit.
Staying under them
- Read
X-RateLimit-Remainingas you go and slow down before you hit zero, rather than waiting for a429. - On a
429, sleep forRetry-Afterseconds. Add a little jitter so parallel workers don't all retry at the same moment. - Retry
5xxresponses with exponential backoff, but never retry a401or403with the same key. - Cache what doesn't change often instead of polling it in a loop.