--- category: [Administration & Integrations, Administration & Integrations/Workday API, Platform and Product Extensions, Platform and Product Extensions/Integration] nav: wcp_docs parent_url: /wcp_docs/ title: >- Concept: Workday REST API Pagination layout: subsection --- ## Pagination Pagination is the mechanism by which an application retrieves a data collection 1 page at a time. The application sends a series of paginated requests until the application receives all of the requested data. Use pagination to: - Avoid reaching timeout and resource limits when requesting data collections with large amounts of data. - Avoid missing data when the full data set might exceed the 100 default, 1000 maximum, or a specified limit. - Enable quick responses with clients that have scrollable user interfaces. A client can initially load an appropriate number of items into the scrollable list or grid. Then the client can use the returned total to determine how many additional empty rows are necessary. As a user scrolls, the client can send additional paginated requests to fetch and populate the data for additional rows. Pagination is available with GET collection endpoints that provide the `limit` and `offset` query parameters. To determine whether a GET collection endpoint supports pagination, see the GET collection endpoint in the REST API documentation. To request paginated data from a GET collection endpoint, specify the `limit` and `offset` query parameters:

Pagination parameter	Description
`limit`	The maximum number of items to include in a single response. The default value is 20, and the maximum is 100. Some REST APIs override this value with a maximum of 1000. Nested prompt endpoints have a default and maximum of 1000.
`offset`	The index position of the first object in a response collection. The default is 0, which points to the first object in the collection.

Workday sorts the paginated data in ascending instance ID order. The default sort order ensures that applications get consistently ordered data collections across paginated REST API calls. Any sort parameters provided by a REST web service take precedence over the default sort order. ## Pagination Example These examples use pagination with the `GET /workers` endpoint: ``` GET https://{hostname}/staffing/{version}/{tenant}/workers ```

Paginated request Description

Paginated request	Description
`GET /workers`	The initial request, with default pagination. Returns the first 20 workers in the result set, or all workers if there are fewer than 20. It's equivalent to this request: ``` GET /workers?limit=20&offset=0 ``` The response includes the total number of items in the entire result set. The `total` helps you to determine the number of subsequent requests.
`GET /workers?limit=20&offset=20`	The second page request. Returns the next 20, which are the 21st through 40th workers.
`GET /workers?limit=20&offset=40`	The third page request. Returns the next 20, which are the 41st through 60th workers.

GET /workers

The initial request, with default pagination.

Returns the first 20 workers in the result set, or all workers if there are fewer than 20. It's equivalent to this request:

``` GET /workers?limit=20&offset=0 ```

The response includes the total number of items in the entire result set. The total helps you to determine the number of subsequent requests.

GET /workers?limit=20&offset=20

The second page request.

Returns the next 20, which are the 21st through 40th workers.

GET /workers?limit=20&offset=40

The third page request.

Returns the next 20, which are the 41st through 60th workers.