Skip to main content
Todos os endpoints de listagem da API Repass usam paginação por cursor, com o mesmo conjunto de parâmetros e o mesmo envelope de resposta. Como os IDs de recurso são ordenáveis (prefixo + ULID), eles próprios servem de cursor: você nunca calcula offsets nem números de página.

Parâmetros de query

Toda listagem aceita os mesmos três parâmetros, mais expand[] para materializar relacionamentos.
integer
default:"25"
Quantidade de itens por página, entre 1 e 100. Aceita string (é coagido para inteiro). Valores fora da faixa (0, 101) são rejeitados com 400 parameter_invalid.
string
ID de recurso usado como cursor. Retorna a página seguinte ao item informado (avança para frente). Use o ID do último item da página anterior.
string
ID de recurso usado como cursor. Retorna a página anterior ao item informado (volta para trás). Use o ID do primeiro item da página atual.
Informe apenas um cursor por requisição: use starting_after para avançar ou ending_before para voltar. Sem nenhum cursor, você recebe a primeira página.

Envelope da resposta

Toda listagem responde com o mesmo envelope Page<T>:
array
Array com os recursos da página atual (no máximo limit itens).
boolean
true quando existe pelo menos mais uma página na direção da paginação; false quando esta é a última página.
Os cursores (starting_after / ending_before) são IDs de recurso opacos: não embutem offset, timestamp ou estado decodificável. Trate-os como tokens: passe de volta exatamente o valor que veio em data, sem parsear nem construir cursores à mão.
A resposta não inclui um campo next_cursor dedicado. Para avançar, você deriva o cursor do último item de data (data[data.length - 1].id) e o envia em starting_after na próxima requisição.

Como funciona

Para detectar se há mais páginas, a API busca limit + 1 linhas internamente, devolve no máximo limit em data e reporta hasMore: true se a linha extra existir.

Exemplo

Listando afiliados, dois por página, com GET /affiliates:

Iterando por todas as páginas

Avance enquanto hasMore for true, sempre usando o ID do último item como próximo cursor:
Pseudo-loop (bash + curl)
Use limit=100 ao varrer coleções inteiras para reduzir o número de requisições. Para UIs paginadas, prefira páginas menores (ex.: limit=25, o default) e mantenha o cursor do último item para “próxima” e o do primeiro item (ending_before) para “anterior”.
Não derive o cursor de um item que você filtrou no cliente: passe sempre o ID de borda real retornado pela API (data[-1].id para avançar, data[0].id para voltar). Cursores são apenas IDs de recurso; qualquer string fora desse formato pode produzir resultados inesperados.
A referência completa de campos de cada listagem está na aba Referência da API. As regras de formato dos IDs usados como cursor estão em IDs e recursos.

Próximos passos

IDs e recursos

Formato dos identificadores que servem de cursor.

Expand

Materialize relacionamentos nas listagens.

Erros

Envelope de erro e o código parameter_invalid.

Idempotência

Replay seguro de requisições POST.