Skip to main content
Só conversations, messages, contacts e cards são paginados. tags, pipelines, lost-reasons e connections devolvem a lista completa, sem count/hasMore (a conta raramente tem mais que algumas dezenas desses registros).

Parâmetros

GET /v1/conversations/{ticketId}/messages é exceção: pageSize tem default 100 e máximo 200, porque conversas costumam ter muito mais mensagens do que outras listas têm registros.
Toda resposta paginada traz:
  • count — total de registros que atendem ao filtro (não só os da página atual).
  • hasMore — true se existe próxima página.
  • o array em si, num campo com o nome do recurso — não existe um data genérico. GET /v1/contacts devolve contacts, GET /v1/cards devolve cards, GET /v1/conversations devolve conversations, GET /v1/conversations/{ticketId}/messages devolve messages.
O nome muda por endpoint — confira a referência do endpoint específico se não tiver certeza do campo.

Paginação completa em Node

Filtros de data

Endpoints com filtro de data (como createdAtAfter/createdAtBefore em cards) exigem offset de fuso explícito no formato ISO-8601:
Datas sem offset (2026-09-01T00:00:00) ou só a data (2026-09-01) são rejeitadas com 400 e code: ERR_INVALID_DATE_FILTER.
Um intervalo invertido (createdAtAfter maior que createdAtBefore) não é rejeitado — a API só valida o formato de cada data isoladamente. Nesse caso a resposta é 200 com a lista vazia, não um erro.
Use Z para UTC ou o offset da sua instância (ex.: -03:00 para horário de Brasília). Nunca envie a data sem offset — mesmo que pareça funcionar em testes locais, a API sempre recusa.