Skip to main content
Toda ruta que devuelve una lista (GET /sessions, GET /clients, GET /bookings…) pagina con cursores, nunca por número de página ni por offset: cada página sigue desde el último elemento de la anterior.

​
La respuesta

  • data: los elementos de esta página, en el orden de la ruta.
  • has_more: true si hay más elementos después de esta página.
  • next_cursor: lo que pasas para pedir la página siguiente; null si no hay más.

​
Los parámetros

​
Recorrer una lista completa

  1. Pide la primera página con los filtros que quieres y limit=100.
  2. Mientras has_more sea true, repite el mismo pedido, con los mismos filtros, agregando starting_after con el último next_cursor.
  3. Cuando has_more es false, terminaste.

​
Un cursor está atado a su búsqueda

Un cursor sirve solo para:
  • la misma ruta,
  • con exactamente los mismos filtros,
  • y con una clave del mismo entorno (de prueba o de producción), contra el mismo estudio de prueba si es de prueba.
Si cambias un filtro, usas el cursor en otra ruta o restableces el estudio de prueba, la respuesta es invalid_cursor: vuelve a pedir la primera página. El contenido de un cursor es opaco: no lo armes ni lo modifiques.

​
Rangos de fechas

Algunas listas piden un rango de fechas obligatorio. Por ejemplo, GET /sessions pide local_date[gte] y local_date[lte], con 31 días como máximo. Para sincronizar un período largo, recórrelo por tramos y pagina cada tramo hasta el final.