Skip to main content
List endpoints return one page at a time, newest first, and tell you whether more exist. Pages move by a cursor, not by an offset, so a record created while you are walking never shifts the pages under you. Every page answers the same shape:

​
Walking every page

Read has_more. While it is true, send the id of the last record in data as starting_after and ask again. Stop when it is false.
Because pages run newest first, a record created after you start walking sorts ahead of the first page: it never shifts the pages you are reading, and you never see a record twice. A payment or refund is ordered by when its request began, so one whose request was still running when you started can land in a page you already read.

​
Cursors are scoped to your workspace

starting_after must be the id of a record from that same list, in your workspace and the same environment as the key you are sending. Anything else is 400 parameter_invalid naming starting_after, whether the id belongs to another workspace, to the other environment, or to nothing at all. The three read the same on purpose, so a cursor cannot be used to probe for ids that are not yours.