The total result set for a query may exceed the maximum number of items allowed in a single response. This limit is typically 100 items by default but can be increased to up to 1000 items in most cases by providing a value for the limit query parameter. If the number of items matching the query (see filtering syntax) is greater than the limit, the response object’s has_more property will have the value true and the next property will be a string which is the API URI providing the next “page” of items for the same query. These properties can be used to easily and efficiently traverse the full result set one page at a time without missing items or traversing the same item twice as can happen when using offsets due to race conditions. The following pseudo-code example demonstrates how you can traverse a full result set one page at a time using has_more and next properties of the response: 
let uri = '/api/global/v1/inventory/products?limit=1000&filter=is_active{eq:true}'
do {
    let result = fetch(uri)
    doSomething(result.collection)
    uri = result.next
} while (result.has_more)

​
Previous Page

Similarly to next, a previous property is included in the response when the result has a previous page. This can be used to traverse backwards in a result set. When traversing backwards (which uses cursor_end) the has_more property in the response will be false when there are no more pages in the “previous” direction.

​
Metadata

The query parameters cursor_start and cursor_end are used to implement the basic paging mechanism, but these parameters are specified automatically in the URI which is returned in the next and previous properties respectively and so do not need to be provided manually. However, the appropriate values of these fields for the next and previous pages of results are also returned in the response’s meta object with the properties cursor_start and cursor_end respectively. These can be used in case you prefer or need to construct the URIs for paging on your own.

​
Count

If the query includes count=1 then the meta object will also include a total count which can be useful for predicting the total number of pages in a query result. The count is not included by default since in some edge cases it can have an impact on performance and is many times not required by the implementation.

​
Example

First page:
Request
GET /api/global/v1/inventory/products?count=1&limit=10
Response
{
  "collection": [
    {...},
    {...},
    {...},
    {...},
    {...},
    {...},
    {...},
    {...},
    {...},
    {...}
  ],
  "has_more": true,
  "next": "/api/global/v1/inventory/products?count=1&cursor_start=11",
  "previous": null,
  "meta": {
    "processing_time": 0.2312367235115
    "cursor_start": 11,
    "cursor_end": null,
    "count": 15
  } 
}
Second page:
Request
GET /api/global/v1/inventory/products?count=1&limit=10&cursor_start=11
Response
{
  "collection": [
    {...},
    {...},
    {...},
    {...},
    {...}
  ],
  "has_more": false,
  "next": null,
  "previous": "/api/global/v1/inventory/products?count=1&cursor_end=11",
  "meta": {
    "processing_time": 0.2312367235115
    "cursor_start": null,
    "cursor_end": 11,
    "count": 15
  } 
}

​
Sorting

See sorting syntax for more info on sorting the result set.