Working on a real-time dashboard that needs to show active conversation counts and some basic attributes (channel type, direction) for a specific routing queue. Currently using the Node SDK to hit /api/v2/conversations with a filter for the queue ID. The response is fast enough for our UI, but I’m seeing a discrepancy when comparing the count against what the analytics team is pulling.
They are using /api/v2/analytics/conversations/interval with a very short interval window. The numbers don’t match. Specifically, the /api/v2/conversations endpoint seems to include conversations that are technically ‘closed’ in our internal state but still linger in the API response for a few seconds after the conversation:updated event with state: closed. The analytics endpoint, however, seems to have a lag or a different aggregation window.
Is there a definitive rule on when to use which endpoint for ‘current’ state? The docs say /api/v2/conversations is for real-time, but the data model feels inconsistent with the analytics view.
Here is the snippet I’m using for the real-time fetch:
const client = await GenesysCloudClient.init({
clientId: process.env.CLIENT_ID,
clientSecret: process.env.CLIENT_SECRET
});
const response = await client.platformClient.conversationsApi.getConversations({
query: {
filter: `routing.queue.id:eq:${queueId}`,
expand: ['participants', 'wrapup']
}
});
The analytics call looks like this:
const analyticsResponse = await client.platformClient.analyticsApi.postAnalyticsConversationsInterval({
body: {
interval: 'PT1M',
dateTo: new Date().toISOString(),
filters: {
routingQueueId: { type: 'string', value: [queueId] }
},
metrics: ['conversationCount']
}
});
The conversationCount from analytics is consistently lower by about 5-10% during peak hours. Is this a known caching issue in the analytics pipeline, or am I misinterpreting the ‘real-time’ nature of the conversations endpoint? Need to know which source of truth to trust for the live dashboard.