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.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.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
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:
Como conviver com isso:
- Deduplique por id no destino.
UPSERTporid(ou porusername, 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
OFFSETgrande 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.

