Pagination and versioning
Pagination
Pagination is a process that divides a large dataset into smaller chunks. All endpoints that return a list of resources support pagination.
When using a list method on a resource, our system supports parameters to specify the paging of the results returned.
For example, if you want to return the second page of your customer list with a 50-record page size, specify that in the request query string:
pageNumber integer Current page number determined by the total number of records and the number of records per page |
|
pageSize integer Number of records to list on a page. Maximum is 50. |
Results are wrapped in a standard paging object as follows:
id string Unique identifier |
|
name string Customer name |
|
pageNumber integer Current page number determined by the total number of records and the number of records per page |
|
pageSize integer Number of records to list on a page. Maximum is 50. |
|
hasPreviousPage boolean True if there is a previous page, otherwise false |
|
hasNextPage boolean True if there is a next page, otherwise false |
Paged Results
{
"results":[
{
"id":"123",
"name":"John C. Customer"
}],
"pageNumber":2,
"pageSize":50,
"hasPreviousPage":true,
"hasNextPage":false
}
Versioning
All API endpoints contain a numbered version in the URL. Whenever breaking changes are made to the API, a new major version will be created.
Breaking changes
-
Adding new required fields to request
-
Changes to the response format
-
Data type changes
-
Modifying an endpoint URL
-
Removing endpoints
Non-breaking changes
-
Adding new endpoints
-
Adding new optional fields to request
-
Adding new fields to response
-
Adding new values to fields (e.g. a new status value)
-
Bug fixes
Deprecated Versions
When we release a new major version, we will continue to support the previous version for a period of at least 6 months before it is deprecated.