The API limits the number of requests per IP address and time window. Once the limit is exceeded, the request is rejected with 429 without being executed: it consumes no quota and produces no effects.
The window is one minute and the counter starts on each clock minute, not on the first request. A burst straddling two minutes is split across both counters.
Applicable limit
The limit depends on the host serving the request:
| surface | requests per minute |
|---|---|
API (api.…) | 80 |
| Dashboard | 80 |
| Documentation | 50 |
| Public site | 40 |
Certain operations apply stricter limits of their own because of their cost or sensitivity — sign-in, OTP delivery, broadcasts — and declare them on their reference page.
The 429 response
{
"errors": [
{
"status": "429",
"code": "rate_limit_exceeded",
"detail": "Request limit exceeded."
}
],
"meta": { "version": "1.57.0", "api_version": "v1", "request_id": "e6f7a8b9c0d1" }
}The response includes the headers needed to retry without guessing:
| header | content |
|---|---|
Retry-After | Seconds left before the window renews |
X-RateLimit-Limit | Maximum requests for the window |
X-RateLimit-Remaining | Requests left; on a 429 it is always 0 |
X-RateLimit-Reset | Renewal time, in seconds since the epoch |
The X-RateLimit-* headers are emitted only on 429 responses. A successful response does not report accumulated consumption; GET /v1/usage/limits covers that.
Recommended handling
The Retry-After value is the only data needed to retry: wait that margin and repeat the request. Retrying earlier consumes the counter again and extends the block.
Rate limits protect the system against bursts, not against total volume. Monthly volume is governed by the plan quota and its own error codes, described in the error taxonomy.