Skip to main content
List endpoints return a fixed-size page of results. To fetch the next page, pass the nextCursor from the previous response back as startingAfter. Cursors are opaque — never parse, persist, or generate them yourself.

Parameters

integer
default:"20"
Number of results per page. Minimum 1, maximum 100.
string
Opaque cursor from the previous response’s nextCursor. Returns the page of results immediately after that cursor.

Response shape

Every list response uses the same envelope:

Walking through every page

Loop until hasMore is false:

Rules of thumb

Cursors are opaque base64url strings whose internal layout is an implementation detail. Do not parse them, build them, or rely on their length — the format may change.
  • Don’t persist cursors long-term. They are scoped to the sort order and filters of the request that produced them. A cursor from ?sort=-createdAt is meaningless against ?sort=updatedAt.
  • Hold filters constant while paging. Changing status, q, or sort mid-loop will produce inconsistent pages.
  • Use hasMore, not data.length. A page can return fewer items than limit and still have more pages waiting (e.g. when results have been filtered after fetching).
  • Hard cap at 100 per page. Higher values are rejected with 422 invalid_query_parameter.