Pular para o conteúdo

Paginação

Lista longa não sai numa resposta só. A API corta em páginas e devolve, junto com os dados, a marca de onde parou. Você pede a próxima página mandando essa marca de volta.

Duas coisas entram na consulta:

ParâmetroO que é
limitQuantos registros você quer na página. Padrão 20, máximo 100
cursorA marca de onde continuar. Na primeira chamada, não mande

A resposta tem sempre este formato:

{
"object": "list",
"data": [],
"has_more": true,
"next_cursor": "Y3JlYXRlZF9hdDoy..."
}
CampoO que é
objectSempre "list". É como você reconhece uma resposta de lista
dataOs registros desta página, na ordem da consulta
has_moretrue quando ainda existe página depois desta
next_cursorA marca para pedir a próxima página

Só o next_cursor. Nada mais.

Não guarde o número da chamada, o total de registros lidos nem o último id visto para tentar continuar por ele. O cursor já carrega tudo o que a API precisa para retomar do lugar certo.

Pare quando has_more for false. Enquanto ele for true, mande o next_cursor de volta no parâmetro cursor e peça de novo.

Não use o tamanho de data como sinal de fim. Uma página pode vir menor que o limit e ainda ter continuação.

O valor do cursor é um texto que só a API entende. Trate como caixa-preta:

  • Não interprete. Ele parece legível em alguns casos, mas o conteúdo dele é assunto interno e pode mudar sem aviso, porque isso não quebra ninguém que só devolve o valor.
  • Não construa na mão. Cursor inventado é recusado.
  • Não mexa. Mande exatamente o texto que veio, sem cortar, sem decodificar, sem trocar caractere.

Com número de página, a página 2 quer dizer “pule os 20 primeiros”. Se alguém criar um registro entre a sua chamada da página 1 e a da página 2, tudo desce uma posição: o vigésimo registro da página 1 vira o primeiro da página 2, e você o lê duas vezes. Se alguém apagar um registro, acontece o contrário e um registro nunca aparece.

O cursor não conta posição, ele marca um ponto na ordenação. Registro criado depois da sua primeira página não empurra nada, e a varredura termina sem repetir nem pular.

É por isso também que não existe offset nem page na API.

Toda lista aceita os mesmos três filtros de data:

FiltroO que faz
created_afterSó o que foi criado depois deste instante
created_beforeSó o que foi criado antes deste instante
updated_afterSó o que mudou depois deste instante

A ordem padrão é created_at decrescente, do mais novo para o mais antigo.

Com updated_after, a ordem vira updated_at crescente. Esse é o modo de sincronização: você guarda o maior updated_at que viu, e na próxima rodada continua dali, sem reler o que não mudou. As datas seguem o formato de Datas e dinheiro.

Não existe ordenação livre nem filtro por campo qualquer. Cada recurso declara os filtros próprios dele na Referência.