Cursor-based pagination
Most API endpoints return acursor 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
nullcursor 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
cursorparam to retrieve the next page with the same filters applied
cursor property in the response object, for example:
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 cursorscursor 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_idto0 - Specify a
limit - Make a request with your current
since_idandlimit - If the number of resources returned is less than your
limit, finish - Otherwise, set
since_idequal to theidof the last resource in the response and repeat
Example
Some data is omitted from the example responses for clarity.