Data Action mapping fails with 400 Bad Request during Zendesk migration

Looking for advice on mapping Zendesk ticket comments to Genesys Cloud interactions via a custom Data Action. We are in the final stages of migrating our support workflow from Zendesk to Genesys Cloud. The goal is to preserve historical context by pushing past ticket notes into the GC interaction timeline.

The Data Action triggers successfully on new interactions, but fails when processing legacy data imports. The response returns a 400 Bad Request with the message: Invalid payload structure for interaction history update. The endpoint is /api/v2/interactions/history.

In Zendesk, we used a simple JSON array for comments. The GC documentation here suggests a nested object structure for external_source_id. I have tried flattening the JSON and wrapping it in a standard interaction envelope, but the 400 error persists.

Is there a specific schema requirement for the body field when using the genesys:interactions:history:update action? Or is this a known limitation with bulk imports? We need this resolved before go-live next Tuesday.

Check your payload structure in the JMeter test plan, because that 400 error usually means the JSON schema for the Data Action is malformed. When migrating legacy data, the Zendesk comment fields often contain nested objects or null values that the Genesys Cloud API rejects if not explicitly handled. You need to flatten the body and author fields before sending them to the /api/v2/architect/data/actions endpoint. In my recent load tests, I found that omitting the interactionId in the request body causes immediate validation failures, even if the authentication token is valid. Ensure your JMeter HTTP Request sampler uses application/json content type and that the body looks like this: {"interactionId": "${vc_interactionId}", "data": {"zendesk_comment": "${vc_comment_body}"}}. Also, verify that the target interaction actually exists in Genesys Cloud before the Data Action triggers, otherwise the system cannot attach the historical context. This strict validation prevents data corruption during high-volume imports.