Rate limits
Los planes limitan cuántos requests podés hacer por minuto.
API v2ActualRequests por minuto
Cada plan define una cantidad máxima de requests por minuto. El límite se comparte entre todas las API keys de tu cuenta: crear varias keys no multiplica los requests disponibles.
Cuentan las consultas de vehículo, el inicio de módulos, el polling, las consultas de uso y la administración de webhooks.
| Plan | Requests por minuto |
|---|---|
| Free | 30 |
| Basic | 60 |
| Growth | 120 |
| Scale | 240 |
Headers
En las respuestas que pasan la comprobación del límite podés leer estos headers:
| Header | Descripción |
|---|---|
| X-RateLimit-Limit | Cantidad máxima de requests permitidos en la ventana actual. |
| X-RateLimit-Remaining | Requests restantes en la ventana actual, después del request realizado. |
| X-RateLimit-Reset | Momento en que se reinicia la ventana: timestamp Unix, en segundos. |
Si tu plan Custom no tiene límite de RPM, se omiten X-RateLimit-Limit y X-RateLimit-Remaining.
Cuando alcanzás el límite
Cuando alcanzás el límite, la API responde 429 Too Many Requests con error.code: rate_limit_exceeded.
Retry-After indica cuántos segundos esperar antes de volver a intentar. El error también incluye details.resetAt con la fecha y hora de reinicio.
- Respetá Retry-After antes de reintentar.
- Reducí la frecuencia de requests y evitá polling innecesariamente frecuente.
- Usá backoff: aumentá la espera entre reintentos si el problema continúa.
Rate limit y consumo
El rate limit mide tráfico HTTP; es independiente del consumo de consultas.
Hacer polling con GET /v2/operations/:id no consume consultas de patente ni de módulos, pero sí cuenta dentro del rate limit.
Una request autenticada puede contar para el rate limit aunque luego sea rechazada por validación.