Paginating using the since_id parameter

All collection endpoints support a since_id parameter.

When a since_id is specified, the collection is ordered by id ascending, and contains only resources with an ID greater than the specified since_id.

To fully paginate through a collection, follow the algorithm:

  • Initialize your since_id to 0
  • Specify a limit
  • Make a request with your current since_id and limit
  • If the number of resources returned is less than your limit, finish
  • Otherwise, set since_id equal to the id of the last resource in the response and repeat


Note: some data is omitted from the example responses for clarity.
curl \
  --url '' \
  --header 'Content-Type: application/json'

Paginating using cursors

Some API endpoints return a cursor which can be used to get the previous or next page of results. This is usually better than using since_id to paginate because:

  • the results are always ordered in descending order (newest first)
  • you don’t need to manually keep track of the last ID
  • you can tell when no more results are available because the next cursor will be null
  • the cursor includes any filters you applied in the initial request, so subsequent requests need only provide the single cursor param to retrieve the next page with the same filters applied

These endpoints will include a cursor property in the response object, for example:

  "transactions": [...],
  "cursor": {
    "prev": null,
    "next": "eyJsYXN0SWQiOjE0NjgsImRpcmVjdGlvbiI6Im5leHQifQ"

If either cursor is null it means there are no more pages available in that direction.

To retrieve the previous or next page of results, pass the cursor as a cursor query param. You do not need to pass any other params; if you initially provided other params to filter the response, these will be part of the cursor already, and any other filtering params will be ignored. Only the limit parameter will be recognised.

For example:

curl \
  --url '' \
  --header 'Content-Type: application/json'