Límites de tasa

Un límite de tasa protege la API sobre una base por clave: las solicitudes se cuentan por clave de API en una ventana fija de un minuto. Las solicitudes de lectura y de escritura tienen límites separados (contadores independientes):

Operación	Método	Límite predeterminado
Lectura	GET	120 / minuto
Escritura	POST, PATCH, DELETE	60 / minuto

Los dos contenedores son independientes — leer de forma intensiva nunca agota tu presupuesto de escritura, y viceversa. Las cabeceras RateLimit-* de cada respuesta reflejan el contenedor correspondiente al método de esa solicitud.

Cabeceras RateLimit

Cada respuesta incluye el estado actual del límite, de modo que puedes limitar de forma proactiva en lugar de esperar a un 429:

RateLimit-Limit: 120
RateLimit-Remaining: 117
RateLimit-Reset: 1751380920

• RateLimit-Limit — el límite máximo para la ventana actual.
• RateLimit-Remaining — solicitudes restantes en la ventana actual.
• RateLimit-Reset — tiempo Unix (segundos epoch) en que la ventana se reinicia y Remaining se recarga.

Trata estas cabeceras como la fuente de verdad — el límite exacto puede cambiar con el tiempo, así que léelo desde RateLimit-Limit en lugar de codificar 120 de forma fija.

Cuando superas el límite

Una vez que Remaining llega a 0, las siguientes solicitudes en esa ventana reciben 429 Too Many Requests (rate_limit_error / too_many_requests) con una cabecera Retry-After:

HTTP/1.1 429 Too Many Requests
Retry-After: 2
RateLimit-Reset: 1751380920

• Respeta Retry-After — espera el número de segundos indicado y luego reintenta.
• Usa retroceso exponencial con jitter para limitaciones repetidas.
• Mejor aún: vigila RateLimit-Remaining y reduce el ritmo antes de llegar a 0.

Restricciones de rango

Los endpoints de listado de eventos requieren un rango from/to no mayor de 366 días. Un rango más amplio se rechaza con 422 validation_error (invalid_request).