Clarification on /api/v2/conversations vs /api/v2/analytics/conversations for real-time data

Can anyone clarify the precise boundary between using /api/v2/conversations and /api/v2/analytics/conversations when building a custom real-time dashboard? I am currently fetching live interaction data via the Platform SDK (genesys-cloud.platformAPI.conversationsApi.getConversations). The latency is acceptable, but I notice that certain metric fields, specifically wrapup_code and queue_wait_time_ms, are either null or inconsistent in the /api/v2/conversations response compared to the historical data I pull from /api/v2/analytics/conversations/summary.

I understand that the analytics endpoints are designed for historical aggregation and have a delay, but my use case requires near-real-time visibility into active queues. If I switch to the analytics endpoint, I risk getting stale data. However, staying on the conversations API means I have to manually calculate durations and map wrap-up codes, which feels inefficient. Is there a specific threshold or recommendation for when to switch from the operational API to the analytics API? I want to avoid hitting rate limits on the conversations endpoint while ensuring data accuracy for active agents. I have tried paging through the analytics endpoint with interval_start set to the current minute, but the data often appears empty for active sessions.

Thanks for the help.

The documentation actually says /api/v2/analytics/conversations is superior for metric aggregation.

  1. Switch to the analytics endpoint.
  2. Use filter=queue_wait_time_ms>0 in your request body.
  3. Apply OAuth scope analytics:read.

This avoids null values from the standard conversation API.