Raju
03/17/2025, 4:37 AMRaju
03/17/2025, 4:37 AMRaju
03/17/2025, 5:43 AMSlaviSavanovic
03/17/2025, 5:54 AMShubham Bajaj
03/17/2025, 1:33 PMpageNo
or offset
parameters as mentioned in the support conversation. Instead, it supports cursor-based pagination using a combination of:
1. The limit
parameter (to control how many records to return)
2. Date-based filtering parameters like createdAtGt
, createdAtLt
, etc.
This is exactly what the user SlaviSavanovic was suggesting in the conversation - you need to:
1. Set the limit
parameter to control how many records you want per page
2. To get the next page, use the createdAt
of the last record in your current page as the starting point for your next query
Here's how the pagination works in practice:
1. First request: GET /call?limit=100
(returns first 100 records)
2. For next page: GET /call?limit=100&createdAtLt=<last_record_timestamp>
(where <last_record_timestamp>
is the createdAt value of the last record from previous response)
The API supports several timestamp comparison parameters that can be used for pagination:
- createdAtGt
- greater than
- createdAtLt
- less than
- createdAtGe
- greater than or equal to
- createdAtLe
- less than or equal to
The response also includes metadata in the format of a CallPaginatedResponse
that contains:
- `results`: the array of Call objects
- `metadata`: pagination metadata including totalItems
, itemsPerPage
, and currentPage
This cursor-based pagination approach is common in APIs that handle large datasets as it's more efficient than offset-based pagination, especially with time-series data like call records.
For implementation, you would:
1. Make your first API call with just a limit
2. For subsequent pages, use the timestamp of the last record to set your filter parameter
3. Continue until you have all the records you need or reach the end of the datasetRaju
03/17/2025, 11:05 PMRaju
03/17/2025, 11:21 PM