Skip to main content
Los listados devuelven siempre la misma envoltura:
Para pedir la página siguiente, repite la llamada con starting_after:
Cuando has_more es false, next_cursor es null y has llegado al final.

Por qué cursores y no números de página

Porque el evento sigue en marcha mientras tú lees. Con ?page=2 y un OFFSET, cada entrada nueva desplaza el contenido y acabas saltándote filas o repitiéndolas. El cursor apunta a un elemento concreto, así que avanzar es siempre «lo que viene después de esto», pase lo que pase por detrás.

Sincronización incremental

Combina el cursor con un filtro temporal. Guarda cuándo terminó tu última pasada y arranca la siguiente desde ahí.
Usa updated_since, que filtra por la última modificación. Así recibes tanto las entradas nuevas como las que hayan cambiado de estado —por ejemplo, las que se hayan acreditado desde tu última pasada.
Solapa un poco la ventana. Un terminal sin cobertura puede sincronizar una venta horas después de haberla hecho, y esa venta tiene un occurred_at anterior a tu última pasada: si arrancas exactamente donde lo dejaste, no la verás nunca. Retrocede el margen que tolere tu operación —unas horas suele bastar— y deduplica por id en tu lado.

Recorrer un listado entero

Una página puede venir con menos elementos que el limit pedido y aun así tener has_more: true. Ocurre cuando tu clave está limitada a ciertos tipos de entrada y la página contenía registros fuera de tu ámbito. Fíate de has_more, no del número de elementos: parar porque una página vino corta te dejaría datos sin leer.