Stuck on a persistent 422 Unprocessable Entity error when attempting to retrieve data from a custom report via the Genesys Cloud Analytics API. The environment is Genesys Cloud UK Prod (v2.1) integrated with ServiceNow London Instance (Kyoto). The goal is to pull digital channel conversation metrics that include custom attributes pushed via Data Actions to ServiceNow, specifically for correlation in a unified dashboard. The endpoint being hit is /api/v2/analytics/conversations/summary with a POST body containing a custom query definition. The query includes a filter on the custom attribute ‘sn_ticket_id’ which is populated via the webhook payload during the conversation trigger. When the filter is applied, the API returns a 422 error with the message ‘Invalid query structure: field sn_ticket_id not found in schema’. This is confusing because the attribute is clearly visible in the conversation transcript and was successfully written to ServiceNow. I have verified that the attribute name matches exactly between the Data Action configuration and the Analytics query. The webhook payload shows the field is present in the ‘attributes’ object of the conversation event. I suspect there might be a delay in the indexing of custom attributes for analytics purposes, or perhaps a limitation on which custom fields can be queried in summary reports. I have checked the documentation for Analytics API v2 and it mentions that custom attributes must be indexed, but there is no clear indication of how to verify or force this indexing. The issue is blocking our ability to generate reports that link Genesys interactions with ServiceNow tickets. Any insights into how to debug this schema mismatch or ensure custom attributes are queryable in analytics would be greatly appreciated. I have tried clearing the cache and waiting for 24 hours, but the error persists. The request ID from the failed call is req_abc123def456. The full JSON payload used for the query is attached in the logs, showing the exact structure of the filter clause. This seems like a configuration issue rather than a code bug, given that other standard fields return data correctly.
Have you tried inspecting the exact payload structure sent by the conversation:updated event? ServiceNow Data Actions often reject updates if the input schema doesn’t match the initial creation format. Check the column reference validity.