Pagination
List operations return one page at a time and hand you an opaque cursor for the next page. Cursor pagination stays correct while the underlying data changes, so you never skip or repeat a row because something was inserted between page reads.
The list envelope
Every paginated list returns the same envelope. The data array holds the page, and the two
sibling fields tell you whether and how to continue.
{
"data": [ { "...": "..." } ],
"next_cursor": "eyJpZCI6...",
"has_more": true
}
| Field | Meaning |
|---|---|
data | The items on this page, in the operation's defined order. |
next_cursor | An opaque token to fetch the next page. It is null on the final page. |
has_more | True when another page exists, false when this is the last page. |
Request parameters
| Parameter | Type | Behavior |
|---|---|---|
cursor | string | The opaque token from a prior response's next_cursor. Omit it (or pass null) for the first page. |
limit | integer | Maximum items per page. Default 25, maximum 100. |
Walking every page
Request the first page without a cursor, process data, then keep passing the returned
next_cursor back as the cursor parameter until has_more is false (or
next_cursor is null).
// first page
GET /v1/payments?limit=50
// each subsequent page
GET /v1/payments?limit=50&cursor=<next_cursor from the previous response>
// stop when has_more is false
You can combine the cursor with an operation's own filters, such as a token or a date range. Keep the filters identical across pages; changing a filter mid-walk invalidates the cursor's position.
Bounded lists
A small number of genuinely-bounded lists, where the result set is naturally short and complete, return
a { data } envelope with no cursor. The interactive reference documents which response shape
each operation returns.
Related
See the operations list for which endpoints are lists, the interactive reference for each operation's exact parameters and response shape, and Rate Limits before paging through a large result set quickly.