Hey folks,
I’m trying to build a simple dashboard that shows active conversation counts for specific queues in real-time. I’ve been using the /api/v2/conversations endpoint for a while, but I noticed the analytics endpoints exist too. Specifically /api/v2/analytics/conversations/queues/summary.
The thing is, when I hit /api/v2/conversations with a filter for status: active, I get a list of individual conversation objects. That’s great for debugging, but if I have 500 active calls, that’s a huge payload just to count them. Plus, I have to paginate through everything to get an accurate total.
I tried switching to the analytics endpoint:
GET /api/v2/analytics/conversations/queues/summary?dateFrom=2023-10-27T12:00:00Z&dateTo=2023-10-27T12:05:00Z&groupBy=queueId
The response is much cleaner:
{
"summary": {
"active": 42,
"waiting": 12
}
}
But here’s the kicker. The analytics data seems to lag by a few seconds. If I hang up a call, it still shows as active in the analytics summary for like 5-10 seconds. The /api/v2/conversations endpoint reflects the state immediately.
My question is: what’s the actual difference under the hood? Is the analytics endpoint pulling from a different data store that’s eventually consistent? Or is it just aggregated data that updates on an interval?
I need sub-second accuracy for my UI. If analytics is lagging, I might be stuck using the raw conversations endpoint and counting on the client side. That feels inefficient, but I don’t want to build something that shows stale data to my supervisors. Has anyone else run into this latency issue with the analytics API for near-real-time reporting?