Skip to main content
List endpoints that can grow without bound use keyset (cursor) pagination. You page forward by handing each response’s cursor back to the next request.

Request parameters

string
Opaque position token from a previous response’s nextCursor. Omit it on the first request. Never construct or modify cursors.
integer
default:"20"
Items per page. Minimum 1, maximum 100 on public list endpoints. Most lists default to 20; the assets list defaults to 50.

Response envelope

  • items — the page of results, in the endpoint’s documented order.
  • nextCursor — pass as cursor to fetch the next page. null means you have the last page.

Iterating all pages

Rules and edge cases

  • Cursors are tied to the endpoint and its sort mode. Changing sort or filters invalidates a cursor — start over without one.
  • An invalid or corrupted cursor returns 400 validation. Restart from the first page.
  • Pages are stable against inserts and deletes: keyset pagination never skips or duplicates items because of concurrent writes elsewhere in the list.
  • Treat nextCursor: null as the only end-of-list signal. A short page is not one — a page can legally hold fewer than limit items.

Endpoints that differ

  • CMS items (GET /v1/cms/collections/{collectionId}/items) additionally supports 1-based page offsets as an alternative to cursor (the two are mutually exclusive) and returns { items, nextCursor, nextPage }. It also accepts filter, search, sort, and depth — see the endpoint page.
  • Fixed-cardinality reads return plain objects or arrays with no envelope, because a product rule caps how many results can exist: website domains (one platform domain plus your custom-domain quota), CMS collection fields (a per-collection field limit), notification preferences (a fixed category catalog), and analytics (explicit top-N and max-points limits, with truncation reported in the response).