List, query, and search methods that return a list of entities may allow you to specify sorting and paging options in the request.
This articles provides a general overview of sorting and paging. The implementation syntax varies between methods. Check your API's documentation for specific details, including which fields are sortable.
Most APIs default to sorting by createdDate in DESC (descending) order, although some APIs have a different default sort order. You can often override the default sorting by specifying a new field and order.
List methods are designed to be lightweight requests. For this reason, sorting is applied in REST through query parameters, typically with sort field name and order fields.
For example, to list contacts by last name in ascending order:
Query methods offer more robust filtering capabilities.
When working with a Query method,
In REST, sorting is specified in an array in the request body,
typically query.sort, and is typically applied with the fieldName and order parameters.
In the SDK, sorting is specified with .ascending() and .descending() functions in the SDK's query chain.
For example, to list payment links by created date in ascending order, and by status in descending order:
When working with a Search method, sorting is typically specified in the search.sort parameter.
For example, to search payment links by created date in ascending order:
Paging allows you to control how many results are returned and where the result set starts. Wix APIs commonly support 1 or both of 2 paging strategies:
limit and skip/offset): Specify the number of items to skip and the number to return.nextCursor and prevCursor): Use a token (cursor) to fetch the next or previous set of results.List methods support paging through query parameters in REST requests and options objects in SDK calls.
For example, to list 100 contacts, starting from contact 21, with offset paging:
Should return items 21-120 in the results.
For calls that support cursor paging, after receieving a cursor in your first request, list the next set of entities with cursor paging:
Query methods handle paging through the request body in REST and chainable methods in the SDK. Generally either offset-based or cursor-based strategies are supported, and occasionaly both are supported.
For example, to query 100 contacts, starting from contact 21, with offset paging:
Should return items 21-120 in the results.
To query 100 payment links with cursor paging:
When working with a Search method, paging is typically specified in the paging or cursorPaging parameter. Search methods typically use cursor-based paging to ensure consistent results even when the underlying data changes during pagination.
For example, to search for 10 payment links, and return a cursor for paging:
Should return 10 items.
To retrieve the next 10 payment links with a cursor: