Skip to main content
List endpoints use opaque cursor pagination. Each page returns a pagination object; you follow the cursor it gives you until there are no more pages.

The pagination object

Every collection response carries a pagination block:
string | null
Opaque token for the next page. Pass it back as the cursor query param. It is null on the final page.
boolean
true while more pages remain; false on the final page. Use this as your stop condition.
integer
The page size in effect for this response.
integer
Total matching rows, included only when you request it (see below).

Request a page

integer
default:"50"
Number of items per page, 1200. A few endpoints cap it lower — GET /search and GET /creators/top allow 125 (default 10). Each endpoint’s reference page lists its exact range.
string
The previous response’s pagination.next_cursor. Omit it to fetch the first page.
boolean
default:"false"
When true, the response adds pagination.total_count. This runs an extra COUNT query, so request it only when you need the total.
A cursor is bound to the exact filter and sort combination it was issued for. Keep your filters and order_by/order_direction identical across pages — reusing a cursor under a different filter or sort returns 422.
List responses also include an RFC 8288 Link header with rel="first" and, when more pages exist, rel="next" — a ready-to-follow absolute URL:
Follow rel="next" if you prefer not to assemble URLs yourself; the absence of a next link mirrors has_next: false.

Fetch all pages

Loop while has_next is true, passing the previous next_cursor each time.
Combine cursors with filters and sorting — see Filtering and sorting. For per-endpoint parameters, see the API reference. For the page-size cap and the other ceilings around it, see Limits & quotas.