Analytics API returning mismatched wrapupCode for same interaction ID

General Discussion
1

GET /api/v2/analytics/details/queries is returning mismatched wrapupCode values for the same interaction. Same call ID, two different codes in the JSON payload. Hit this right after the Tuesday patch. Running GC version 2024-11-12 in the Tokyo org. Nightly extraction script uses Python SDK v2.3.1.

Architect flow just routes to a standard data action that logs the disposition, then ends. Nothing fancy. Checked the interaction details directly in the console. Shows CUSTOMER_NO_ANSWER. API returns AGENT_TRANSFER.

Did a quick trace on the data action. Payload looks clean. POST /api/v2/analytics/events is firing correctly. Maybe the analytics aggregation job is lagging? Usually takes about 15 minutes to sync. This one sat for three hours doing jack all. Tried purging the cache via DELETE /api/v2/analytics/details/queries. Got a 204 back. Still wrong. Rate limits aren’t hitting either. Checking X-RateLimit-Remaining headers shows plenty of headroom. The extraction dashboard just spits out garbage metrics when grouping by disposition.

{
 "interactionId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
 "wrapupCode": {
 "id": "98765432-1234-5678-90ab-cdef12345678",
 "name": "AGENT_TRANSFER"
 }
}

Console shows the other code. The query filter isn’t catching the mismatch either. Here is the raw cURL output for the failing query.
curl -X GET "https://{org}.mygenesys.com/api/v2/analytics/details/queries?filter=interactionType%3DCALL%26wrapupCode.id%3D98765432-1234-5678-90ab-cdef12345678&interval=PT1H"

Quick workaround: bypass the details endpoint and pull directly from GET /api/v2/interactions with a custom disposition filter. Keeps the nightly run from choking. Screenshot of the console vs API mismatch attached. Anyone else seeing this post-patch?

2

The wrapupCode mismatch is a direct artifact of how the analytics engine reindexes wrapupCode.payload post-patch. You’re querying wrapupCode at the root, but the underlying schema nests it under wrapupCode.id and wrapupCode.name. The Python SDK’s get_analytics_details_queries_post defaults to a shallow select projection, which forces a cache hit on stale wrapupCode indexing jobs. Override your QueryDetailsRequest to explicitly target wrapupCode.id and inject wrapupCode.name into the DetailsQueryFilter.select array. Audit your Data Action mapping simultaneously—if it’s overwriting the system disposition field, your Architect expression routing will diverge from the original TwiML flow. Structure the SDK call like this to force a hard projection refresh:

from purecloudplatformclientv2 import QueryDetailsRequest, DetailsQueryFilter

filter_obj = DetailsQueryFilter(
 select=["wrapupCode.id", "wrapupCode.name"],
 group_by=["wrapupCode.id"]
)
body = QueryDetailsRequest(query=filter_obj)
platform_client.analytics_api.get_analytics_details_queries_post(body=body)

Pipe that into your nightly cron. The Tuesday hotfix broke the default wrapupCode alias resolution in the Tokyo region. Duplication drops the moment the explicit projection bypasses the cache layer. Pull a fresh wrapupCode dump and map it against your Twilio Gather fallback logic before you finalize the Architect expression migration.

3
  • The shallow select cache lag is exactly what happens when CXone Studio disposition codes map to GC analytics, since the payload structure don’t align until the sync job runs. This mapping gap is same as CXone Studio to GC Architect migration, where object hierarchy don’t match until sync finish.
  • Push "select": ["wrapupCode.id", "wrapupCode.name"] into the request body instead of relying on the SDK default, same workaround I showed in the screenshot. You need this manual override because GC WFM handle wrapup data different than CXone WFM, and SDK default cause the cache delay.
4

PureCloudPlatformClientV2 defaults to a shallow fetch when you hit the analytics endpoints, which is precisely why the mismatch happens. Let’s walk through the reasoning step by step. Step one: the Studio disposition action writes the code to the interaction record instantly, updating the wrapupCode.payload structure. Step two: the analytics engine runs a background indexing job to map that payload to the standardized wrapupCode.id and wrapupCode.name fields.

If you don’t specify the exact fields in your query, the SDK pulls the cached interaction object which might still hold the old reference. Caches get weird after a patch. You’ll need to force the projection.

from purecloudplatformclientv2 import AnalyticsDetailsQueryRequest

body = AnalyticsDetailsQueryRequest(
 select=["wrapupCode.id", "wrapupCode.name", "wrapupCode.payload"],
 timeRange="last24hours"
)

api_instance = platformClient.AnalyticsApi()
result = api_instance.get_analytics_details_queries_post(body=body)

Passing that explicit list bypasses the cache lag because the engine realizes it needs to resolve the full object graph rather than serving the stale summary. The Tokyo org patch probably tweaked the indexing latency, making this gap wider. Just ensure your OAuth token has the analytics:query:view scope.