Just noticed that the analytics data returned via the /api/v2/analytics/interactions/details endpoint is not aligning with the real-time dashboard metrics for our custom disposition codes. This discrepancy is causing significant issues for our client’s monthly reporting automation, which relies heavily on the consistency between live views and historical API pulls.
We are operating in the us-east-1 region with a multi-org setup. The specific issue arises when filtering by custom disposition codes that were recently migrated from a legacy IVR system. While the Architect flow correctly captures and assigns these dispositions, the analytics API seems to lag or omit them entirely for interactions that occurred in the last 24 hours. Specifically, interactions tagged with DISP_LEGACY_MIGRATION_01 appear in the real-time agent view but return a count of zero when queried via the API with a startTime and endTime window covering the same period.
We have verified that the analytics:read and report:read scopes are correctly assigned to the service account used for these API calls. Additionally, we are using the standard pagination parameters with a page size of 1000. The request headers include the correct X-Genesys-Application-Key and the OAuth token is valid and refreshed appropriately. We have also ensured that the data retention settings in the organization configuration are set to the maximum allowed duration, so data purging is not the culprit here.
Has anyone encountered similar latency or aggregation issues with custom dispositions in the Analytics API v2? We are considering if there is a known delay in the data pipeline for custom attributes or if we need to adjust our query parameters to force a refresh of the aggregation cache. Any insights into how the analytics engine handles custom disposition indexing would be greatly appreciated, as this is blocking our automated report generation for the current billing cycle.