Skip to main content
List endpoints use cursor-based pagination. Results are returned in stable order, and you page through them using a cursor rather than an offset.

​
Response structure

Every paginated response includes these fields:

​
Parameters

​
integer
default:"100"
Number of results per page. Minimum 1, maximum 500.
​
string
Pass the next_cursor value from the previous response unchanged to fetch the next page.

​
Paginated endpoints

​
Unpaginated list endpoints

These return a list envelope but always deliver the full set in a single response. Their sets are small and bounded, so there is nothing to page through: They do not accept limit or starting_after, and their envelopes carry only object, url, and data. There is no has_more and no next_cursor field at all, so a generic pagination helper must treat an absent has_more as “this is the only page” rather than reading it as false off an object that never had it.

​
Endpoints with no list envelope

GET /team is not a list endpoint, even though it returns collections. It returns a single team document whose members and invitations arrays sit directly on the response:
There is no object: "list", no url, and no data, so a generic helper that reaches for response.data will read undefined rather than an empty page. Branch on object before treating any response as a list. Both arrays are always present and are [] when empty, never null, and neither accepts limit or starting_after.

​
Example

Fetch the first page of transactions:
If has_more is true, use next_cursor to get the next page:

​
Fetching all pages

Use larger limit values (up to 500) to reduce the total number of requests, especially if you are syncing all data.
Writing a generic helper that paginates any list endpoint? Use the url field from the response instead of hardcoding the path: append ?starting_after={next_cursor} to response.url and the same function works across /transactions, /journal_entries, and /parties/merchants.