refactoring our CX-as-Code pipeline to handle historical data reconciliation. The team is debating whether to use the real-time conversation endpoints or the analytics API for data that is more than 24 hours old.
I have been using the genesyscloud_conversation data source in Terraform to fetch active call details, which maps to /api/v2/conversations. This works fine for live events. However, when we need to pull historical logs for auditing, the documentation suggests using /api/v2/analytics/conversations/details/query.
The issue is that the response schema is significantly different. The real-time endpoint returns a flat object with immediate participant details. The analytics endpoint requires a complex JSON query body and returns an aggregated result set. Here is the payload structure I am trying to construct for the analytics call:
{
"dateRange": {
"start": "2023-10-01T00:00:00.000Z",
"end": "2023-10-02T00:00:00.000Z"
},
"groupBy": ["conversationId"],
"filter": [
{
"type": "eq",
"field": "mediaType",
"value": "voice"
}
]
}
When I run this query, I get the data, but the participant attributes are nested differently than in the real-time response. We are seeing a 400 Bad Request if we try to use the real-time endpoint for old data, which is expected. But the analytics endpoint feels heavy for what should be a simple lookup.
Is there a hard cutoff where the real-time endpoint stops returning data? The docs say 24 hours, but we have seen inconsistencies. Also, does the analytics API guarantee eventual consistency for all participant attributes, or are some fields dropped after a certain period?
We want to avoid building two separate data fetching modules in our Terraform provider if possible. One module for live, one for history. It adds maintenance overhead.
Can someone confirm the exact behavior when a conversation transitions from real-time to analytics storage? We need to know if we can rely on the analytics endpoint for precise participant state at the exact moment of disconnect.
The current workaround is to cache the real-time response before the conversation ends, but that feels brittle. We are looking for a cleaner API-driven solution.