Pagination

The getpaid API supports cursor pagination to efficiently handle large datasets. By using pagination, you can retrieve data in smaller chunks instead of fetching everything in a single request. This improves performance and reduces the likelihood of timeouts or excessive memory usage.

Pagination in the getpaid API is controlled through two query parameters and one response field:

1. first: Specifies the maximum number of elements to retrieve in a single request. This helps control the size of each page.
2. after: Represents the cursor pointing to the starting position for the next page of results. It allows the API to resume from where the previous request ended.
3. cursor: A base64-encoded string included in the API response. This string encodes the position in the dataset and contains all the information needed to fetch subsequent pages. Treat this value as opaque; do not attempt to decode or modify it.

These parameters work together to enable efficient navigation through large datasets, ensuring optimal performance and resource usage. The resources are returned in the array data.

Request format

Include first and after as query parameters in your API request. For example, GET /accounts?first=<PAGE_SIZE>&after=<CURSOR_VALUE>.

The after value is the cursor from the previous request.

Response format

The response includes:

• Optionally, the field cursor if the are more resources to fetch.
• Always, the data array with the resources retrieved. Empty if none.

200 OK

{
  "cursor": "Q3VyaW9zaXR5IEtpbGxlZCB0aGUgQ2F0Cg==",
  "data": [
    [...]
  ]
}

How to use pagination

In this scenario, there are 25 accounts and we fetch them in chunks of 10 records.

First request

There is no previous cursor because this is the first request. In this scenario, the request must be GET /accounts?first=10 indicating the number of records to retrieve in the first parameter.

The response includes the cursor for the next request and the 10 records inside data.

200 OK

{
  "cursor": "Q3VyaW9zaXR5IEtpbGxlZCB0aGUgQ2F0Cg==",
  "data": [
    [...]
  ]
}

Subsequent requests

To continue fetching the resources from the previous point, the subsequent request must include the after parameter including the value of the previous response cursor field. In this scenarion, the request must be GET /accounts?first=10&after=Q3VyaW9zaXR5IEtpbGxlZCB0aGUgQ2F0Cg==.

The response includes again the cursor for the next request because there are still records to fetch. Again, there are 10 records inside data.

200 OK

{
  "cursor": "Q3VyaW9zaXR5IEtpbGxlZCB0aGUgQ2F0IEFnYWluIQ==",
  "data": [
    [...]
  ]
}

Last request

The subsequent requests must be repeated using the after parameter with the value of the previoours response cursor field until the cursor is not present, indicating there are no more results.

In this scenario, as there were only 25 records, the third and last request must be GET /accounts?first=10&after=Q3VyaW9zaXR5IEtpbGxlZCB0aGUgQ2F0IEFnYWluIQ==.

The response does not include the cursor field because there are no more records to fetch and the data can include as many records as the number indicated at first parameter. In this scenario, it will include just 5 records.

200 OK

{
  "data": [
    [...]
  ]
}