### Answer To retrieve 5k calls from a specific agent on a certain day, you'll need to use pagination since the maximum limit per request is 1000 [(1) ]() . Here's a sample payload to get started:

json
{
  "filter_criteria": {
    "agent_id": ["agent_oBeDLoLOeuAbiuaMFXRtDOLriT12345"],
    "start_timestamp": {
      "lower_threshold": 1738475411000,
      "upper_threshold": 1738475421000
    }
  },
  "sort_order": "descending",
  "limit": 1000
}

For the timestamp range, use Unix timestamps in milliseconds for the specific day you want . To retrieve all 5k calls, you'll need to make multiple requests using the

pagination_key

parameter [(1) ]() [(2) ]() . After your first request returns 1000 calls, use the last call ID from that response as the

pagination_key

in your next request :

json
{
  "filter_criteria": {
    "agent_id": ["agent_oBeDLoLOeuAbiuaMFXRtDOLriT12345"],
    "start_timestamp": {
      "lower_threshold": 1738475411000,
      "upper_threshold": 1738475421000
    }
  },
  "sort_order": "descending",
  "limit": 1000,
  "pagination_key": "last_call_id_from_previous_response"
}

The

pagination_key

is exclusive, meaning the call associated with that ID won't be included in the next fetch . You'll need to repeat this process approximately 5 times to retrieve all 5k calls [(2) ]() .

​ To learn more, see the sources I considered: [[1] List Calls](https://docs.retellai.com/api-references/list-calls) [[2] Unable to get call logs from API](https://discord.com/channels/1186424376300679209/1308107545453264896) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

### Answer Correct—you don't need to modify the timestamps between pagination requests [(1) ]() . The

start_timestamp

filter defines the time window for the entire query (8 AM to 8 PM in your case) , and the

pagination_key

handles fetching the next batch of results within that same time window . Your workflow would look like this: First request:

json
{
  "filter_criteria": {
    "agent_id": ["agent_oBeDLoLOeuAbiuaMFXRtDOLriT12345"],
    "start_timestamp": {
      "lower_threshold": 1738490400000,
      "upper_threshold": 1738533600000
    }
  },
  "sort_order": "descending",
  "limit": 1000
}

Subsequent requests (same timestamps, different pagination_key) :

json
{
  "filter_criteria": {
    "agent_id": ["agent_oBeDLoLOeuAbiuaMFXRtDOLriT12345"],
    "start_timestamp": {
      "lower_threshold": 1738490400000,
      "upper_threshold": 1738533600000
    }
  },
  "sort_order": "descending",
  "limit": 1000,
  "pagination_key": "last_call_id_from_previous_response"
}

The

pagination_key

is the last call ID from your previous response and is exclusive (not included in the fetched calls) . Keep the same timestamp filter across all requests—it defines your 8 AM to 8 PM window—and only update the

pagination_key

to continue fetching the next page [(1) ]() [(2) ]() .

​ To learn more, see the sources I considered: [[1] List Calls](https://docs.retellai.com/api-references/list-calls) [[2] Unable to get call logs from API](https://discord.com/channels/1186424376300679209/1308107545453264896) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

Thanks for the follow-up, @K Rudy. I'll get back to you soon.

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

### Answer The

sort_order

parameter determines how calls are ordered by their

start_timestamp

[(1) ]() . When set to

"descending"

, the calls are returned with the most recent calls first (newest to oldest) . If you set it to

"ascending"

, the calls would be returned with the oldest calls first (oldest to newest) . The default value is

"descending"

. So in your case with

"descending"

, you'll get the calls from 8 PM first, then working backwards toward 8 AM .

### Answer When sorting by descending, you should use the last call ID from the response as your

pagination_key

for the next request [(1) ]() . The documentation states: "The last call id from the list calls is usually used as pagination key here" . Since the

pagination_key

is exclusive (not included in the fetched calls) , using the last call ID ensures you continue fetching the next page without gaps or duplicates . So with descending sort (newest to oldest) , your workflow is: 1. First request returns calls 1-1000 (newest first) 2. Grab the last call ID from that response (call #1000) 3. Use that as

pagination_key

in your next request 4. Second request returns calls 1001-2000 5. Repeat until you've retrieved all 5k calls

​ To learn more, see the sources I considered: [[1] List Calls](https://docs.retellai.com/api-references/list-calls) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

### Answer No, you should still use the last call ID from the response as your

pagination_key

, regardless of whether you're sorting ascending or descending [(1) ]() . The documentation states: "The last call id from the list calls is usually used as pagination key here" . This applies to both sort orders. Here's why it works the same way: With ascending sort (oldest to newest) : 1. First request returns calls 1-1000 (oldest first) 2. Grab the last call ID from that response (call #1000) 3. Use that as

pagination_key

in your next request 4. Second request returns calls 1001-2000 (continuing chronologically forward) With descending sort (newest to oldest) : 1. First request returns calls 1-1000 (newest first) 2. Grab the last call ID from that response (call #1000) 3. Use that as

pagination_key

in your next request 4. Second request returns calls 1001-2000 (continuing chronologically backward) The

pagination_key

is exclusive (not included in the fetched calls) , so using the last call ID ensures continuous pagination without gaps or duplicates in either direction.

​ To learn more, see the sources I considered: [[1] List Calls](https://docs.retellai.com/api-references/list-calls) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

​ To learn more, see the sources I considered: [[1] List Calls](https://docs.retellai.com/api-references/list-calls) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

### Answer For the first request, you should simply omit the

pagination_key

parameter entirely [(1) ]() . The documentation states: "If not set, will start from the beginning" . So your first request should look like this:

json
{
  "filter_criteria": {
    "agent_id": ["agent_oBeDLoLOeuAbiuaMFXRtDOLriT12345"],
    "start_timestamp": {
      "lower_threshold": 1738490400000,
      "upper_threshold": 1738533600000
    }
  },
  "sort_order": "descending",
  "limit": 1000
}

Don't include

pagination_key

at all in your first request—just leave it out . Only add it starting with your second request using the last call ID from the previous response .

### Answer The issue is with your timestamp format—you're using timestamps in seconds, but Retell requires timestamps in milliseconds [(1) ]() . Your timestamps: - `lower_threshold`: 1773665400 (seconds) - `upper_threshold`: 1773709800 (seconds) Should be: - `lower_threshold`: 1773665400000 (milliseconds) - `upper_threshold`: 1773709800000 (milliseconds) Corrected payload:

json
{  
  "filter_criteria": {
    "agent_id": ["agent_a805cc151a1cdc5df54cd85555"],
    "call_status": ["ended"],
    "call_type": ["phone_call"],
    "direction": ["outbound"],
    "start_timestamp": {
      "lower_threshold": 1773665400000,
      "upper_threshold": 1773709800000
    }
  },
  "sort_order": "descending",
  "limit": 1000
}

The timestamps need to be in milliseconds since epoch . When using seconds instead of milliseconds, the API likely doesn't find any calls matching that far-future date range (your timestamps in seconds would represent dates in the year 2026, while in milliseconds they represent dates in 2026 as well but correctly formatted) . Multiply your Unix timestamps by 1000 to convert from seconds to milliseconds .

​ To learn more, see the sources I considered: [[1] List Calls](https://docs.retellai.com/api-references/list-calls) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

@AI Evy can you add the date and time to that payload? so the records also return that, and the agent name

### Answer The payload you're using doesn't need to be modified—the API response automatically includes the timestamp and agent name in the returned call objects [(1) ]() . When you make the request with your current payload, each call object in the response will already contain : - `start_timestamp`: Begin timestamp in milliseconds since epoch - `end_timestamp`: End timestamp in milliseconds since epoch - `agent_name`: Name of the agent The response structure looks like this :

json
[
  {
    "call_id": "Jabr9TXYYJHfvl6Syypi88rdAHYHmcq6",
    "agent_id": "oBeDLoLOeuAbiuaMFXRtDOLriTJ5tSxD",
    "agent_name": "My Agent",
    "start_timestamp": 1703302407333,
    "end_timestamp": 1703302428855,
    "duration_ms": 10000,
    ...
  }
]

You don't need to add anything to your request payload—these fields are automatically included in every call object returned by the List Calls endpoint . The

start_timestamp

and

end_timestamp

are in milliseconds since epoch, and

agent_name

is the name of the agent used for that call .

​ To learn more, see the sources I considered: [[1] List Calls](https://docs.retellai.com/api-references/list-calls) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

### Answer The

start_timestamp

field in the response is the date and time each call happened [(1) ]() . It's returned in milliseconds since epoch, which you'll need to convert to a human-readable date/time format in your code . Each call object in the response includes : - `start_timestamp`: When the call began (in milliseconds since epoch) - `end_timestamp`: When the call ended (in milliseconds since epoch) - `agent_name`: Name of the agent To convert the timestamp to a readable date/time, you'll need to handle that conversion in your application code. For example, in JavaScript:

javascript
const readableDate = new Date(start_timestamp) .toLocaleString() ;

The API doesn't return a pre-formatted date string—you receive the Unix timestamp in milliseconds and convert it to your preferred date/time format on your end .

​ To learn more, see the sources I considered: [[1] List Calls](https://docs.retellai.com/api-references/list-calls) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.