I’m building a custom interval report using the Analytics Conversations Aggregates query API. The goal is to fetch conversation metrics broken down by 15-minute intervals for the last 24 hours.
The API endpoint is GET /api/v2/analytics/conversations/aggregates.
Here’s the query payload I’m sending:
{
"dateFrom": "2023-10-25T00:00:00.000Z",
"dateTo": "2023-10-26T00:00:00.000Z",
"granularity": "FIFTEEN_MINUTES",
"metrics": [
"conversationCount",
"avgHandleTime"
],
"filter": {
"type": "and",
"clauses": [
{
"type": "field",
"path": "conversation.type",
"op": "eq",
"value": "voice"
}
]
}
}
The first response returns data for the first few intervals, but it cuts off. The response includes a nextPageUri.
When I follow the nextPageUri, I get another chunk of data. The issue is that the intervals in the second page don’t always align perfectly with the granularity I requested, or sometimes there are gaps in the timestamps.
I’m trying to stitch these responses together to build a continuous timeline for my custom agent desktop widget. The widget needs to show a smooth graph of call volume.
Is there a specific way to handle the pagination so I get all intervals, even if they have zero data? Or do I need to fill in the gaps client-side?
Also, the nextPageUri seems to expire quickly. If I’m processing a large date range, do I need to re-authenticate or is there a token refresh mechanism I should be aware of in the SDK?
Here’s the relevant part of my Node.js code:
const analyticsClient = new PlatformClient.AnalyticsApi();
let allData = [];
let nextPageUri = null;
async function fetchAllIntervals() {
let currentUri = '/api/v2/analytics/conversations/aggregates';
while (currentUri) {
const response = await analyticsClient.getAnalyticsConversationsAggregates({
body: queryPayload,
uri: currentUri
});
allData = allData.concat(response.body.entities);
currentUri = response.body.nextPageUri;
// Wait a bit to avoid rate limiting
await new Promise(r => setTimeout(r, 1000));
}
}
The loop seems to work, but the data alignment is off. The timestamps in the second batch start at a weird offset. I’m not sure if this is a backend quirk or if I’m missing a parameter in the initial query.