Pagination
Cursor-based pagination
Most 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)
- no need to manually keep track of the last ID
null
cursor indicate that no more results are available- the cursor includes any filters 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 include a cursor
property in the response object, for example:
If either cursor is null
it means there are no more pages available in that direction.
Cusors are also included in the Link
header of the response. This is useful
if you are retrieving results in CSV format, in which case the response body
will not include the cursors
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 recognized.
For example:
since_id
parameter pagination
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
to0
- Specify a
limit
- Make a request with your current
since_id
andlimit
- If the number of resources returned is less than your
limit
, finish - Otherwise, set
since_id
equal to theid
of the last resource in the response and repeat