Pagination

Every list on the Kesk API is a Relay connection, paged with cursors. There is one model to write against, and the same paginator works on products, orders, locations, bots, webhooks, units and every vertical-specific list.

query {
  units(first: 50, after: $cursor) {
    nodes { id serialNo status }
    pageInfo {
      hasNextPage
      endCursor
    }
  }
}

Arguments: first / after to page forward, last / before to page backward.

The connection exposes:

Field	Meaning
`nodes`	The items directly — use this unless you need cursors
`edges`	`{ node, cursor }` pairs, when you need a per-item cursor
`totalCount`	Items matching the query, ignoring pagination
`pageInfo.hasNextPage`	Another page exists going forward
`pageInfo.endCursor`	Pass as `after` to fetch the next page
`pageInfo.hasPreviousPage` / `startCursor`	The backward equivalents

async function allUnits(client) {
  const out = [];
  let after = null;

  for (;;) {
    const { units } = await client.request(UNITS_QUERY, { first: 100, after });
    out.push(...units.nodes);
    if (!units.pageInfo.hasNextPage) break;
    after = units.pageInfo.endCursor;
  }
  return out;
}

Cursors are opaque. Do not parse, construct, or persist them long-term.

Counting results

Every connection exposes totalCount — the number of items matching the query with pagination ignored — so "142 orders" or a "page 3 of 12" control needs one request rather than a walk of every page.

query {
  orders(first: 25) {
    totalCount
    nodes { id status }
    pageInfo { hasNextPage endCursor }
  }
}

The schema defines it as the items "matching the query, ignoring pagination", so it reflects whatever filters you passed and changes when they do — it is not a total for the collection.

Rate limits apply

Paging a large set is many requests. At 1000 requests per minute you can exhaust the budget quickly with a small page size. Use the largest page size the field accepts, and see Rate limits.

Working with GraphQL Errors

Built with