Each page is denoted by the ID of the last object it holds, rather than its page. For example, if a 'page' returns 10 customers, then the ID of the last customer will be passed in the URL to get the next page.
| Option | Summary |
|---|---|
Suppose we set the following options:
| Option | Value |
|---|---|
The following URL will be generated to get the first page:
Notice our link parameter path (limit) and the actual limit value (10) at the end of the request. Our first page would look something like the example below:
When pagination runs, it will look for the last id key in the payload, and use that as the starting point for the next request. So the request for page 2 will be:
Notice our link parameter path (limit) and the actual limit value (10) at the end of the request, followed by our Last ID parameter name (starting_after) set to the last id in the response.
A sample response for this request is below:
Pagination continues until the the number of items in the payload is less than the limit, or the page returns an error code.
Link parameter path
Enter the dot notation path for the data element in your response which contains the maximum number of items that the API should return in a single page of a paginated response. Commonly (though not necessarily), this would be a path to a limit field.
Last ID parameter name
Enter the name of the query parameter to be passed into the URL to tell the receiving system the last record we received (so the receiving system knows where to start for the next page of data to return). A commonly used name is: last_id .
Limit
Enter the number of items to be returned per page. For example: 10.
ID key
Enter the unique identifier key for each item in your data. For example, if the endpoint is pulling a list of users, this might be: user_id.
Link parameter path
limit
Last ID parameter name
starting_after
Limit
10
ID key
id