Rate limits
Limits are per API key, not per org. Two windows apply at once: a per-minute cap and a per-second burst.
| Mode | Sustained | Burst |
|---|---|---|
Live (abr_live_…) |
100 requests / minute | 20 / second |
Test (abr_test_…) |
30 requests / minute | 20 / second |
If a header disagrees with this table, trust the header.
Headers
Every authenticated /v1 response includes these (success and errors):
| Header | Meaning |
|---|---|
X-RateLimit-Limit |
Sustained (per-minute) limit |
X-RateLimit-Remaining |
Requests left in this minute |
X-RateLimit-Reset |
Unix timestamp (seconds) when the minute window resets |
A request with no X-API-Key is not rate-limited — it fails 401 first.
When you hit the cap
429 with error.code rate_limited, plus Retry-After (seconds to wait):
{
"error": {
"code": "rate_limited",
"message": "Rate limit exceeded",
"request_id": "…"
}
}
Wait for Retry-After (or until X-RateLimit-Reset). Tight retry loops stay at 429.
What to do
- Read
X-RateLimit-Remainingon normal calls. - On
429, sleepRetry-Afterseconds, then retry. - Keep
request_idif a 429 looks wrong and you contact support.