Skip to main content

Parâmetros

Toda lista em /v1 aceita os mesmos dois parâmetros de query:
integer
padrão:"1"
Página, começando em 1 (não em 0). Valores menores que 1, negativos ou não numéricos são corrigidos silenciosamente para 1 — não há 400.
integer
padrão:"25"
Itens por página. Mínimo 1, máximo 100. Valores fora da faixa são grampeados, não rejeitados: pageSize=5000 devolve 100, pageSize=0 devolve 1.
Como os valores inválidos são corrigidos em silêncio, um bug no seu código (um page NaN, por exemplo) não estoura erro — ele simplesmente relê a página 1 para sempre. Se a sua varredura nunca termina, cheque primeiro se o page que você envia é realmente um número.
Quais endpoints paginam:

Envelope de resposta

Todas as listas respondem com a mesma forma:
string
Sempre "list" numa resposta de lista.
object[]
Os itens da página. Cada item traz o próprio campo object: member, post, event ou order. Lista vazia é [], nunca null — e não é erro.
integer
A página efetivamente servida, já grampeada. Compare com o que você pediu para detectar um parâmetro inválido.
integer
O tamanho efetivamente aplicado, já grampeado ao teto de 100.
boolean
true quando a página voltou cheia (data.length === pageSize). Veja a ressalva abaixo.
Respostas de item único, como GET /v1/members/{username}, são planas — não vêm embrulhadas em data, e trazem object: "member" na raiz.
hasMore é uma heurística, não uma contagem. Ele é derivado do tamanho da página retornada. Quando o total é múltiplo exato do pageSize — 50 membros com pageSize=25 — a última página cheia devolve hasMore: true, e a página seguinte volta vazia com hasMore: false. Isso custa uma requisição extra por varredura e é comportamento esperado; seu laço precisa lidar com uma página vazia no fim.

Como percorrer

1

Comece em page=1 com pageSize=100

O teto de 100 é sempre a escolha certa numa varredura: são 4× menos requisições que o padrão 25, e o teto de taxa é por requisição, não por item.
2

Processe data

A ordem é estável e definida pelo endpoint (tabela acima).
3

Pare quando hasMore for false OU data vier vazia

As duas condições — a segunda cobre o caso do múltiplo exato.
4

Imponha um teto de páginas

Um limite rígido evita que um bug transforme a varredura num laço infinito que consome o orçamento de requisições da chave.
Uma página

Varredura completa

A varredura acima consome 1 requisição por página. Com pageSize=100 e o teto de 120 req/min por chave, você percorre até 12.000 registros por minuto sem tocar no limite. Se precisar de mais, trate o 429 — não aumente o pageSize, que já está no máximo.
Não há total de registros. Nenhuma resposta traz total ou pageCount, e hasMore não é derivado de uma contagem. Contar a tribo inteira a cada página seria caro, e o número estaria desatualizado antes de você lê-lo. Se a sua interface precisa de “página 7 de 42”, ela precisa contar do seu lado — ou adotar rolagem infinita, que é o que o hasMore favorece.

A ressalva do offset

A paginação é por offset (OFFSET = (page − 1) × pageSize), calculado no banco a cada requisição. Duas consequências que importam de verdade:
Varreduras longas podem duplicar ou pular itens. Todas as listas são ordenadas por data decrescente, então registros novos entram no começo e empurram tudo para frente. Se a tribo receber 3 membros novos durante a sua varredura, 3 itens que estavam na fronteira entre as páginas 2 e 3 serão vistos duas vezes. Se registros saírem, itens são pulados.
Como conviver com isso:
  • Deduplique por id no destino. UPSERT por id (ou por username, em membros) torna a duplicata inofensiva. É a mitigação mais simples e a que resolve o caso real.
  • Varra do fim para o começo quando o objetivo for um retrato consistente: começar pela última página reduz o impacto de inserções, que só afetam o início.
  • Prefira webhooks para sincronização incremental. Varrer a lista em laço só para descobrir o que mudou é caro, é a maior fonte de 429, e é exatamente o problema que o evento resolve.
  • Páginas profundas ficam mais caras. Um OFFSET grande faz o banco percorrer e descartar todas as linhas anteriores. Numa tribo grande, a página 500 responde mais devagar que a página 5 — mais uma razão para preferir eventos a varreduras periódicas de tudo.

Próximo passo — erros e limites →

O cliente com retentativa usado nos exemplos acima, com backoff e jitter.