Hey folks,
Running into a weird discrepancy in our reporting dashboard. We’re pulling call data for a specific queue to audit handle times. I’ve been using the GET /api/v2/conversations endpoint with filters for type: voice and the queue ID. It works fine for real-time stuff, but the numbers don’t match our historical reports.
So I switched to GET /api/v2/analytics/conversations/queries/summary. This one gives me the exact numbers we see in the GUI. But here’s the kicker - the analytics endpoint is way slower and the JSON structure is totally different. It returns aggregated buckets instead of individual conversation objects.
Is there a hard rule here? Like, should we only ever use the analytics endpoint for anything older than 24 hours? Or is the /api/v2/conversations endpoint just missing some post-processing steps?
Here’s the filter payload I’m sending to the analytics query:
{
"date_from": "2023-10-01T00:00:00.000Z",
"date_to": "2023-10-02T00:00:00.000Z",
"filter_type": "and",
"filters": [
{
"type": "queue",
"id": "some-queue-id"
}
],
"metrics": ["talkDuration", "holdDuration"]
}
The response comes back with talkDuration in milliseconds, but the raw conversations endpoint gives me separate talk and hold objects. Makes mapping a pain.
Anyone else hit this wall? Just want to make sure we’re not building something that’ll break when Genesys changes the underlying storage.