nextPageToken that you pass back to fetch the next page. This approach is stable across inserts and deletes and scales to arbitrarily large result sets.
Request parameters
List endpoints accept two query parameters:| Parameter | Type | Default | Description |
|---|---|---|---|
pageSize | integer | 20 | Number of resources to return per page. Most endpoints cap at 100. |
pageToken | string | (none) | Opaque cursor returned by the previous response. Omit on the first request. |
Response field
Every paginated response includes a top-levelnextPageToken:
nextPageToken is omitted or returned as an empty string. That is the signal to stop iterating.
The collection field name is resource-specific, not a generic
data. For example, GET /v2/transfers returns transfers, GET /v2/accounts returns accounts, and GET /v2/deposit-destinations returns depositDestinations. Check the endpoint’s response schema for the exact field name.Example: fetch the first page
Example: fetch the next page
Iterating through all results
A typical pattern: keep calling the endpoint with the previous response’snextPageToken until it stops coming back.
Best practices
- Use the largest
pageSizeyour workload can handle to reduce the number of round-trips. For bulk reads, prefer100over the default20. - Persist the
nextPageTokenif you need to resume iteration across processes or sessions. - Don’t reorder results between requests. Cursors encode the result set’s ordering at the time of the first request; sorting client-side after each page is safe, but changing query filters mid-iteration is not.
- Stop on missing or empty
nextPageToken— that’s the end-of-results signal, not an error. - Combine with rate limits in mind: pull pages serially rather than in parallel.
What to read next
Conventions
Shared formatting standards (IDs, amounts, timestamps)
Rate limits
Per-window limits and backoff guidance