Pagination is a process used to divide a large dataset into smaller chunks (pages). All Square API endpoints that return a list of resources support pagination. For example, the
SearchCustomers endpoint (Customers API) and
ListCustomerRefunds endpoint (Refunds API) support pagination. Each request to these endpoints returns a page of the result set.
When the result is truncated (there are more resources to retrieve), the response also returns a
For example, suppose your
SearchCustomers result set is 100 customers but the page returned in the response has only 10 customers. In this case, the response includes a
In your subsequent
SearchCustomers request, include the
cursor along with the same original request body to retrieve the next page (next set of customers). As long as each call results in a response that includes a
cursor, you continue to send
SearchCustomers requests (in each request include the
cursor returned in the previous response). The last page of the result set doesn't include a
All Square API endpoints that support pagination also support a
limit field that the application can use to indicate the page size (the number of items to return in the response). If you don't specify a
limit, the default limit applies. The
maximum page sizes vary from one endpoint to another. The Square API technical reference provides page size details for each paging endpoint.
A page of retrieved records has a limited lifespan. Pages can become stale when other endpoints add, update, or delete records, which changes the set of returned records if a given page is requested again.
In your initial call to a paginated endpoint, there's no need to include a
cursor: the first page of results is returned. Optionally, you can constrain the number of results returned using a
limit. The following applies when specifying
limit fields in these endpoint requests:
POST requests - Include the
limitfields in the request body. For example, SearchCustomers is a POST request. The following
SearchCustomersrequest specifies a limit of 2 customers in the response. Note that the
limitis set in the request body.
The sample response shows a
cursorin the response, indicating that there are more customers to retrieve.
In your subsequent
SearchCustomersrequest, use the same request body as before, but include the
cursorin the body as shown:
Note that each request can specify a different page size (the
A cursor has a 5-minute lifetime. If you cache the cursor for each page you retrieve, you can use one of these page cursors to retrieve a previous page again. However, after a cursor expires, it can no longer be used.
GET requests - The GET requests don't have a body. Therefore, you include a cursor as a query parameter. For example, ListPaymentRefunds is a GET request. The following
GetPaymentRefundrequest specifies a
limitof 2 refunds in the response:
The sample response includes a
cursorindicating that there are more refunds to retrieve.
You then send a subsequent request to retrieve the next set of refunds by adding
cursoras query parameter.
As long as the response includes a
cursor, you continue to make the
GetPaymentRefundsrequest. Eventually, there are no more refunds to return and the last response doesn't include the
The Square SDK documentation provides libraries and sample code for several programming languages. For examples of paginated requests, see the following:
Pagination works differently for Connect V1 endpoints and Square API endpoints. In Connect V1 endpoints, paginated results include a
Link field in the response header with the following format:
To retrieve the next set of results, send a follow-up request (including all the usual headers) to the
next URL. When the endpoint sends the final set of results, the response doesn't include the
batch_token parameter included in the
next URL is a short-lived token that should be used only once to retrieve the next set of results for a particular query. Don't persist or reuse this value.
There are other Square API patterns. For more information, see Common Square API Patterns.