createdAt first - and use cursor-based pagination. Unlike offset pagination, cursor pagination stays stable as new records are created between requests: you never see duplicates or skip items mid-page.
Response envelope
Every list response wraps its results in the following shape:data- the array of resource objects for the current page.hasMore-trueif there are more records beyond this page;falsewhen you have reached the end.
Pagination parameters
Control page size and position with these query parameters:startingAfter and endingBefore are mutually exclusive. Supplying both in the same request returns a 400 Bad Request.
Walking forward through pages
To iterate through all records, start with your desiredlimit, check hasMore, and use the last item’s ID as startingAfter on the next request. Repeat until hasMore is false.
Filtering
Each list endpoint exposes its own filter parameters. The following filters are available across most endpoints:
The payments list endpoint also supports these additional filters:
Example - find all completed payments for an invoice:
Sorting
The sort order is fixed: results always come back newest-first bycreatedAt. There is no sortBy parameter.
All filters combine with AND logic - every filter you supply must match for a record to appear. Filters also compose cleanly with pagination: once you have a filtered result set, use
startingAfter and endingBefore exactly as you would on an unfiltered list to walk through its pages.