Rate limits and headers
Each key has its own budget of requests, and every answer tells you where you stand.
The limit#
A key may make 120 requests a minute unless your administrator set another value. The budget refills continuously, so Retry-After is short. Every request with an accepted key counts, including refused ones (403 scope_missing, 404, 409, …) and idempotent replays.
A general limit per client address may also apply. Its 429 can come without the JSON body; treat it like any other 429.
curl -si "$MASK/integration/key" -H "Authorization: Bearer $KEY" # the 11th call within a minute on a key limited to 10
HTTP/1.1 429
X-Request-Id: 3f9b7d78-a8e5-463e-b3ee-4a0d64caa934
Cache-Control: no-store
X-RateLimit-Limit: 10
X-RateLimit-Remaining: 0
Retry-After: 6
Content-Type: application/json;charset=UTF-8
{"status":"error","code":"rate_limited","message":"Rate limit of 10 requests per minute exceeded","requestId":"3f9b7d78-a8e5-463e-b3ee-4a0d64caa934"}
Back off on 429 for Retry-After seconds, and on 503 unavailable with an increasing delay.
Headers on every answer#
| Header | Meaning |
|---|---|
X-Request-Id |
a UUID the server made for this request, also in every error body (requestId). Quote it when you report a problem. A request id you send is ignored |
Cache-Control: no-store |
always |
X-RateLimit-Limit |
the key's requests per minute; present once the key is accepted (not on a 401, nor on 403 ip_not_allowed) |
X-RateLimit-Remaining |
requests the key has left after this one |
Retry-After |
on 429: seconds until the next request is allowed. On 409 idempotency_in_progress: 1 |
Idempotent-Replayed: true |
on an answer served from the idempotency store |