Pagination

List endpoints take pageNumber (1-based) and pageSize, and return the page alongside its position:

{
  "data": [],
  "currentPage": 1,
  "pageSize": 20,
  "totalCount": 137
}

pageSize defaults to 20 and is clamped server-side, so asking for a very large page returns the maximum rather than an error. Read pageSize back from the response rather than assuming you got what you asked for.

Paging happens in the database, not in the response, so a later page costs about what the first one did.

When totalCount is null

Some searches run in a bounded mode that deliberately skips counting the full result set, because counting it is more expensive than returning it. Those responses carry totalCount: null and a hasMore boolean:

{ "data": [], "currentPage": 3, "pageSize": 20, "totalCount": null, "hasMore": true }

Page until hasMore is false. Treat totalCount as a hint that may be absent — code that assumes a number will break on exactly the queries that matter most.

Stable ordering

Results are ordered newest-first. Rows created while you page can shift later pages, so for a consistent snapshot narrow the query (by job, by date) rather than paging a large moving set.