Most list endpoints in the Acclaim API use cursor-based pagination. This approach allows you to efficiently navigate through large result sets without the inconsistencies of offset-based pagination.
How It Works
When you request a list of resources (such as wallets, payees, or payouts), the response includes a few helpful fields for pagination:
{
"data": [
{ "id": "po_123", "object": "payout" },
{ "id": "po_124", "object": "payout" }
],
"has_more": true,
"next_cursor": "eyJ2IjoiMTI0In0="
}
| Field | Type | Description |
|---|
| data | array | A list of returned objects. |
| has_more | boolean | Indicates whether there are additional results beyond this page. |
| next_cursor | string | A token to retrieve the next page of results. Pass this value to the next request. |
Request Parameters
You can control pagination with the following query parameters:
| Parameter | Type | Description |
|---|
| limit | integer | The maximum number of objects to return (default: 25, max: 100). |
| cursor | string | A cursor token from a previous response to fetch the next page. |
GET /v1/payouts?limit=25&cursor=eyJ2IjoiMTI0In0=
Example Flow
- Request the first page:
- Check the
has_more field in the response.
If true, use the next_cursor value to request the next page:
GET /v1/payees?cursor=eyJ2IjoiMTI0In0=
- Repeat until
has_more is false.
Tips
- Always use the
next_cursor value from the previous response; cursors may expire after some time.
- Avoid guessing cursor values or reusing them across unrelated queries.
- If you need sorted results, apply consistent filters (e.g., by creation date).
- Treat each page of data as immutable — do not assume previously retrieved pages will remain identical over time.
Last modified on March 24, 2026
