Pagination
List endpoints return a page of results together with a cursor. You ask for a page size with limit, read has_more to learn whether another page exists, and pass the last item's id as starting_after to fetch the next one. There are no page numbers, so adding or removing an item does not shift the items you have already read.
The request below runs in CI against an in-process core on FakeChain, so a response that stops matching its # expect line fails the build. The {{KEY}} placeholder works as in the quickstart.
Read a page
Ask GET /v1/counterparties for two items. The response is { "data": [...], "has_more": false }. limit is at least 1 and at most 100, and defaults to 50.
GET /v1/counterparties?limit=2
authorization: Bearer {{KEY}}
# expect 200
Follow the cursor
Every item has an opaque, prefixed id. Pass the last id of the current page as starting_after to read the items after it. has_more tells you whether more items exist after this page. Only GET /v1/events also accepts ending_before, to walk backwards.
GET /v1/counterparties?limit=2&starting_after={{CURSOR}}
authorization: Bearer {{KEY}}
# expect 200
Keep the cursor, never an offset. The cursor names an item, so it stays correct while the collection changes underneath you; an offset would skip or repeat items whenever one is inserted or deleted.
Where it applies
The list endpoints share the same query: limit and starting_after, and a has_more flag in the body. Only events also accept ending_before. GET /v1/transfers, GET /v1/counterparties, GET /v1/deposit-routes, GET /v1/events and GET /v1/webhook-endpoints all page this way, each with its own id prefix as the cursor.
Read until has_more is false, or until a page comes back empty; a client should not assume any particular page size or total.