Skip to main content

Paginación y sincronización

Paginación por cursor

Las listas devuelven hasta limit resultados del más nuevo al más viejo, más un cursor para seguir:
Para la página siguiente, pasá ese valor tal cual en cursor:
Cuando has_more es false, terminaste.
Por qué cursor y no page=2. Si alguien compra mientras vos estás paginando, un offset te haría saltear o repetir filas: la ventana se corre bajo tus pies. El cursor apunta a una fila concreta, así que sigue exactamente donde quedaste pase lo que pase.

Recorrer todo

Sincronización incremental

Después de la primera carga completa no hace falta volver a traer todo.

Ventas

Filtrá por updated_after con el updated_at más alto que tengas guardado:
updated_at se mueve cuando la orden cambia de estado (se aprueba, se rechaza, se reembolsa), no solo cuando se crea. Por eso updated_after te trae tanto las ventas nuevas como las que cambiaron — que es justo lo que un sistema espejo necesita.
No uses created_after para sincronizar: una compra creada ayer y reembolsada hoy no aparecería, y tu copia quedaría mostrándola como válida para siempre.

Ingresos en la puerta

Guardá el checked_in_at más alto que viste y usalo como próximo scanned_after.

Entradas emitidas

Las credenciales emitidas antes del 11 de agosto de 2026 tienen todas la misma fecha de issued_at (el momento en que agregamos ese campo). Para ubicar en el tiempo una venta vieja, usá created_at de la orden, que sí es la fecha real.

¿Webhooks o polling?

Los webhooks son la forma correcta de enterarte de que algo pasó: llegan en el momento y no gastás llamadas. El polling incremental es el complemento: corré una sincronización cada tanto (cada 15 minutos, o una vez por día) para reconciliar. Si tu servidor estuvo caído más de las ~21 horas que dura nuestra escalera de reintentos, el polling es lo que te recupera lo que te perdiste.