Pagination
Endpoints that return arrays of data that don't have a small fixed size will be paginated using cursor-based pagination.
Certain GET endpoints will correspond to large amounts of data. In such cases the endpoint will return the results using cursor-based pagination: each response will contain a subset of the results along with information on how to get subsequent subsets if there are more.
Paginated endpoints always have a limit parameter which is capped at a specific value (usually 10 or 100). When paginated endpoints have more than limit results available, they will also return one or two "cursors" that allow you to request more results. A cursor is an opaque string marking a specific item in a list; a call to a paginated endpoint with at least one result will return a before cursor for the first result and an after cursor for the last result.
Cursors can become invalid if the item they refer to is no longer a part of the result set, so you should never store cursors. For example, a cursor pointing to the last Merit in endpoint results for all of an Org's Pending Merits will become invalid if a User accepts that Merit.
When making a call to a paginated endpoint, you can pass a cursor from a previous call to the same endpoint via the ending_before and starting_after parameters.
If a paginated endpoint has no results, no cursors will be provided. If a paginated endpoint has exactly one result, the
beforeandaftercursors will refer to the same item.
Updated over 3 years ago