Skip to main content
List endpoints that can return many results are cursor-paginated. Each response returns one page of results plus a cursor you use to fetch the next page.

Endpoints that aren’t paginated

Not every list endpoint is paginated. Collections that are bounded per user return a bare JSON array — no envelope, and no limit or cursor parameters:
Every other list endpoint — on-ramps, off-ramps, card transactions, webhook deliveries, debit cards and the wallet-kit collections — uses the cursor envelope below. If you write one generic list helper, branch on Array.isArray(response) rather than assuming data is always present.

Response envelope

Paginated responses wrap the results in an envelope:
  • data: the results for this page
  • hasMore: whether more results exist after this page
  • nextCursor: pass this value as cursor to fetch the next page. It’s null when there are no more results

Fetch pages

Set the page size with limit (default 50), and fetch the next page by passing the previous response’s nextCursor as cursor.
Loop until hasMore is false:
Treat cursors as opaque. Don’t construct or parse them; just echo nextCursor back as cursor.

Filter and sort

Many list endpoints accept filters and a sort order alongside pagination. For example, GET /v1/off-ramps/ accepts status, chain, and accountId, plus sort (asc or desc). Filters apply consistently across pages. See each endpoint in the API Reference for its full set of parameters.