Skip to main content
Los límites se cuentan por API key, no por IP. Dos integradores detrás del mismo proxy no se penalizan entre ellos. El cupo general es configurable por clave: si tu integración necesita más, pídeselo al organizador y lo sube desde el panel.

Cabeceras

Cada respuesta lleva:
Al agotarse, la respuesta es 429 con retry-after en segundos:
No inventes tu propia espera: usa el valor de retry-after. El servidor sabe exactamente cuándo se libera tu cupo.

Cómo no chocar con el límite

POST /tickets acepta hasta 500 entradas por llamada. Cargar 5.000 entradas son 10 llamadas, no 5.000. Con el cupo de escritura de 20 por minuto, la diferencia es entre medio minuto y cuatro horas.
Los listados aceptan limit=200. Recorrer 10.000 ventas son 50 llamadas en lugar de 200.
No vuelvas a bajar el histórico entero en cada pasada. Usa updated_since y since como se explica en Paginación.
Consultar el estado de las entradas cada segundo no te da información más fresca de la que hay: los terminales sincronizan por lotes. Cada 30 segundos es más que suficiente durante el evento.

Nota operativa

El contador vive en memoria del proceso que atiende la petición. En un despliegue de una sola instancia —el caso habitual— es exacto. Si el evento se sirve desde varias instancias, el cupo efectivo puede ser algo mayor que el nominal. Nunca menor, así que no tienes que hacer nada al respecto.