2026-07-13 — Límites por clave de API
Entrada histórica en inglés sobre los límites de peticiones por clave de API.
Historial en inglés correspondiente al 2026-07-13. Se conserva el texto publicado y su contexto temporal; para implementar una integración, consulta la referencia actual.
API version: 2026-05-15 (non-breaking change)
Added
Per-key rate limits
Every request to /v1/* is now counted against two independent sliding windows per API key:
| Window | Limit |
|---|---|
| Burst | 150 requests per 10 seconds |
| Steady | 600 requests per 60 seconds |
A request must fit in both windows. Previously the API was subject to the platform's general per-IP limit, which was lower than this contract and shared with the dashboard traffic; the public API is now exempt from that limit and governed only by the per-key windows.
Response headers
Every response carries the state of the more restrictive window: Ratelimit-Limit, Ratelimit-Remaining, Ratelimit-Reset (Unix seconds) and Ratelimit-Policy (150;w=10, 600;w=60). X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset are sent as aliases with the same values.
429 in the standard envelope
Exceeding either window returns 429 Too Many Requests with a Retry-After header and the usual error body:
{
"error": {
"type": "rate_limit_error",
"code": "rate_limit_exceeded",
"message": "Burst limit reached (150 req / 10s). Retry after 4 seconds.",
"request_id": "req_3f9a1c7e5b2d8f4a6c0e9b1d3f"
}
}Limits are tracked per key, so splitting workloads across keys multiplies your budget. See rate limits for the retry strategy we recommend.