We are refactoring our Terraform modules to validate conversation routing metrics and noticed a significant divergence in the data returned by these two endpoints. When querying for a specific conversation ID using the standard /api/v2/conversations/{id} endpoint, the response contains the full interaction lifecycle and participant details, but lacks the aggregated routing statistics we need for our state drift detection logic. Conversely, the /api/v2/analytics/conversations/details/summary endpoint provides the necessary wait time and queue duration metrics, yet it requires a date range query which feels inefficient for single-entity lookups.
The documentation implies that the analytics endpoint is designed for reporting purposes, but we need this data programmatically within our CI/CD pipeline to ensure our infrastructure definitions match the actual flow performance. Is there a recommended pattern for joining this data, or should we be sticking to the analytics API for all metric-related queries even if it means handling pagination for single IDs? The payload structure from the analytics endpoint also seems to normalize the data differently, making it harder to map directly to our Terraform state files without additional transformation logic.