Pagination

List endpoints return records in blocks. You navigate with the page parameter, and most endpoints accept per to choose the block size.

curl --request GET \
  --url 'https://app.azchat.digital/api/v1/accounts/1/products?page=2&per=50' \
  --header 'api_access_token: SUA_CHAVE_AQUI'

Parameter	Default	Description
page	1	The page you want, starting at 1.
per	15	Records per page.

The ceiling is 200 records per page: higher values are silently clamped to 200, without an error.

:::caution Not every endpoint accepts per per is available on the CRM endpoints (products, services, organizations, among others). Several older endpoints — contacts and conversations, for example — have a fixed page size of 15 and ignore the parameter. Check the specific endpoint in the Reference. :::

Finding the total

Paginated endpoints usually return the total count alongside the payload, which lets you work out how many pages there are:

{
  "payload": [ ... ],
  "meta": {
    "count": 342,
    "current_page": 2
  }
}

The shape of meta varies between endpoints — some use count, others total_count, and some return no count at all. Treat an empty result as the end of the list.

Walking through everything

The safe pattern is to ask for pages until an empty one comes back:

async function allProducts(host, accountId, token) {
  const records = [];
  let page = 1;

  for (;;) {
    const response = await fetch(
      `${host}/api/v1/accounts/${accountId}/products?page=${page}&per=200`,
      { headers: { api_access_token: token } }
    );
    const { payload } = await response.json();

    if (!payload?.length) return records;

    records.push(...payload);
    page += 1;
  }
}

:::tip Mind the rate limit Walking through many pages in a row is the most common way to run into the rate limits. Use per=200 to cut down the number of calls, and handle the 429. :::

Lists that change while you read them

Pagination is offset-based: if records are created or removed while you page through, an item may show up twice or be skipped. For large synchronizations, prefer filtering by a stable date range, or deduplicate by id at the end.