Most list endpoints can be paginated with the following parameters. Check the endpoint’s reference page for where it takes them and what limits it sets.
The 1-based page number to fetch.
Records per page, up to the maximum the endpoint allows.
Two response shapes
Which shape comes back depends on whether you sent either parameter:
Paginated envelope
Plain array
Send page, page_size, or both: Omit both, on an endpoint that supports it: Pagination in the request body
The log list endpoints take page and page_size in the JSON body instead of the query string, because their filters do not fit in a URL. The parameters mean the same thing and take the same values.
For example, fetching the first page of 100 logs:
The response is the same paginated envelope as everywhere else, so a paging loop reads identically whichever way the parameters went out.
Paging through a full set
Read total from the first response to know how many pages to expect, then request each in turn.
Keep page_size the same across a sequence. Changing it partway through repeats or skips records, because the offset is derived from both values.
Offset pagination reads a moving target. Records written while a sweep is in progress shift rows
between pages, so a long run can miss a record or return one twice. Where the endpoint takes time
bounds, set both ends so the set stops changing underneath you, and deduplicate on the record’s
id downstream.
