Skip to main content
All endpoints that list objects use cursor-based pagination. For instance, you can list workers, list charges or list payments. Most list endpoints return items in reverse chronological order—the most recently created object appears first, and the oldest appears last. Endpoint reference pages call out documented exceptions such as stable lexicographic order.

Parameters

number
default:"10"
A limit on the number of objects to be returned, at least 1. A value above 100 is treated as 100. You can change it from one page to the next.
string
The next_cursor from the previous response, to fetch the next page. It carries the filters of the request that started the list, so you can send it alone. Treat it as opaque: it is encrypted, and you can’t decode or build one. A cursor stays valid for at least 24 hours.

Returns

A list response carries a page of records and next_cursor:
Older endpoints return their records under the resource name instead of data, such as workers or payments. Each endpoint’s reference page shows its shape.
string | null
Pass this value alone as cursor, with at most a new limit, to fetch the next page. It is always present, and null when you have reached the end of the list. A page can hold fewer than limit records while more remain, so stop only when next_cursor is null.
string
The same value as next_cursor, present only while more results exist. Prefer next_cursor; cursor remains for existing integrations.

Filters and cursors

A cursor continues the request that issued it, filters included, so send it alone, with at most a new limit. Any other parameter sent with it is refused with a 422 invalid error naming it. To change a filter, start again without a cursor. A cursor from another list or account, one that has been changed, or one more than 24 hours old may be refused with a 422 invalid error whose reason has the code cursor.invalid. Start again without a cursor.

Paging by object ID

List workers and list payments also accept starting_after, an object ID from the previous page. Prefer cursor; starting_after remains only for existing integrations. Send one of cursor or starting_after, not both.

Parameters lists no longer take

Lists don’t page backward and don’t count. A request that sends ending_before or count, or starting_after to a list other than workers or payments, is refused with a 422 that names the parameter and what to send instead. To learn about changes as they happen, use webhooks rather than polling a list.