Todo endpoint de listagem da API pública usa o mesmo contrato de paginação, os mesmos parâmetros de página e o mesmo formato de resposta. Os filtros mudam de recurso para recurso, mas seguem convenções previsíveis.

​
Paginação

Duas variáveis de entrada:
Valor fora do intervalo devolve 422 com o campo apontado. A API não corrige o número em silêncio, então pedir pageSize=500 é erro, e não 200.

​
Formato da resposta

A resposta é sempre um objeto com os registros em Items e os contadores ao lado. Nunca um array solto na raiz.

​
Percorrendo todas as páginas

Use HasNext como condição de parada, e não uma comparação sua entre Page e TotalPages:
A paginação é por deslocamento, com page, e não por cursor. Se registros forem criados ou excluídos durante a varredura, um item pode aparecer duas vezes ou nenhuma, porque ele muda de página no meio do caminho. Em cargas grandes, prefira filtrar por um intervalo de datas fechado, algo como criacaoInicio e criacaoFim, que não se move enquanto você lê.

​
Filtros

Filtros vão na query string e são todos opcionais. Combiná-los aplica E lógico: ?ativo=true&search=camiseta devolve produtos ativos que também casam com “camiseta”. As convenções que se repetem em toda a API: Parâmetro desconhecido é ignorado, sem erro. Confira o nome exato na página do endpoint, porque um filtro escrito errado não reclama: ele só não filtra, e a resposta parece boa demais.

​
Ordenação

O parâmetro sort recebe o nome do campo. Prefixe com - para inverter, e separe por vírgula para ordenar por mais de um campo:
O nome do campo não diferencia maiúsculas de minúsculas.

​
Campos aceitos por recurso

Cada recurso aceita a sua própria lista. Campo fora dela é ignorado, e a listagem volta para a ordenação padrão.
Os recursos que ficaram fora da tabela (contatos, reuniões, ações agendadas, negócios, atividades e motivos de venda) aceitam o parâmetro sort na requisição mas têm ordenação fixa. Enviá-lo não muda nada. Ordene do seu lado, ou acompanhe o Changelog da API.