Paginación | Lectico Docs

Por qué cursor en vez de offset

Las listas de Lectico (agentes, conversaciones, leads, mensajes, webhooks) pueden crecer indefinidamente. La paginación por offset (?page=2) falla en cuanto se insertan registros nuevos entre petición y petición: se repiten o desaparecen filas. La paginación por cursor evita ese problema usando el ID del último elemento visto como punto de anclaje.

Parámetros

Parámetro	Tipo	Descripción
`limit`	`number`	Cantidad de elementos por página. Por defecto `20`, máximo `100`.
`starting_after`	`string`	ID del último elemento recibido. La API devuelve los que vienen después.

Respuesta

{
  "data": [ { "id": "agt_a1..." }, { "id": "agt_a2..." } ],
  "meta": {
    "request_id": "req_...",
    "pagination": {
      "has_more": true,
      "next_cursor": "agt_a2..."
    }
  }
}

has_more — si hay más páginas después de la actual.
next_cursor — el ID que tienes que pasar en starting_after para la siguiente petición. null si has_more: false.

Recorrido manual

# Primera pagina
curl "https://api.lectico.com/v1/agents?limit=50" \
  -H "Authorization: Bearer $LECTICO_API_KEY"

# Siguiente
curl "https://api.lectico.com/v1/agents?limit=50&starting_after=agt_a2..." \
  -H "Authorization: Bearer $LECTICO_API_KEY"

Recorrido con el SDK

El SDK expone iterAll que auto-pagina:

for await (const agent of lectico.agents.iterAll({ type: "support" })) {
  console.log(agent.id, agent.name);
}

Funciona para todos los recursos que devuelven listas: agents, knowledge, conversations, leads, webhooks.

Orden

Los elementos se devuelven por fecha de creación descendente (más nuevo primero) salvo que la documentación del endpoint diga lo contrario.