Skip to main content
List endpoints return an items array and pagination metadata:
  • count is the number of items in the current response.
  • nextCursor is present when another page may be available.
  • An omitted nextCursor means the current page is the last page.
  • When the collection ends exactly on a page boundary, the final nextCursor may return an empty page (count: 0, no nextCursor). Treat that as the end of the list.
Pass nextCursor back as the next request’s cursor query parameter:
Treat cursors as opaque strings. Do not decode, modify, or construct them. A cursor carries the filters, page size, and ordering of the listing it came from, so later pages need only cursor. To change filters, start a new listing without cursor.

​
Page size

Pass limit (1 to 100) to choose how many items a page holds. The page size is carried in nextCursor, so later pages keep it without repeating limit; pass limit again only to change it. Without limit, each endpoint uses its default page size.
Process every item and continue until nextCursor is absent or a page comes back empty. Do not rely on count equalling limit to detect the last page.

​
Sorting

Every list endpoint accepts two optional parameters: Most endpoints order by a single date field, so sort has one value and sortDirection is the parameter you will actually use, for example to read a collection oldest first:
Endpoints with more than one ordering, such as recipients (createdAt, name, lastPaidAt), take sort to pick one:

​
Sorting and cursors

A cursor marks a position within one ordering, so on later pages:
  • Omitting sort and sortDirection keeps the ordering the cursor was issued with. It does not fall back to the default.
  • Repeating the same sort and sortDirection alongside cursor is accepted.
  • Passing different ones is rejected with 400 invalid_request; details is keyed by the offending parameter:
To change the ordering, start a new listing without cursor.