Skip to main content
Endpoints that return lists of resources use pagination. Paginated responses include a paging object:

Requesting a specific page

Use the page and page_size query parameters:

Pagination on POST endpoints

POST-based search and reporting endpoints paginate the same way as GET endpoints: page and page_size are read from the query string, not from the JSON request body. The body carries the query itself (date range, columns, filters); paging sits alongside it in the URL.
page and page_size placed inside the JSON body are ignored. The request still succeeds and still returns data, so a body-paginated loop silently re-reads page 1 forever. If your pages all look identical, this is why — move them into the query string.
The response includes the paging envelope:

Iterating all pages

Not every endpoint paginates. Aggregated reporting endpoints such as Entity Table return the full result set in one response with no paging object at all — reading data["paging"] against one of those raises a KeyError. Check the endpoint’s own reference page before writing a paging loop.
Aggregated reporting endpoints cap responses at 10,000 rows total. They are not paginated, so there is no way to reach rows beyond the cap by paging — if your result set exceeds it, use the Entity Table Export endpoint, which returns a full CSV without a row cap.

Defaults and limits

  • On a paginated endpoint, omitting page and page_size returns page 1 with a page size of 50. Endpoints that are not paginated ignore both and return their full (capped) result set.
  • The maximum page size is typically 2,000, though some endpoints enforce a smaller limit.
  • Endpoints that return paginated responses are identified as such in their documentation.