WFM Quality API 409 Conflict When Mapping Zendesk Satisfaction Surveys

I’m trying to figure out why the WFM Quality API is throwing a 409 Conflict during our Zendesk-to-Genesys Cloud migration. We are attempting to map Zendesk CSAT survey responses to Genesys Cloud Quality evaluations via the POST /api/v2/wfm/quality/evaluations endpoint. The payload includes the interaction ID and a custom form ID that mirrors our Zendesk survey structure.

In Zendesk, creating a new evaluation for an existing ticket was idempotent or simply updated the existing record. Here in Genesys Cloud, the API seems to strictly enforce uniqueness constraints on the interaction ID within the evaluation form scope. The error response indicates: "code": "CONFLICT", "message": "Evaluation already exists for this interaction and form."

We assumed we could use this endpoint to sync historical Zendesk survey data into GC Quality for unified reporting. However, every attempt to push data for interactions that already have a manual evaluation results in this conflict. Is there a specific PUT endpoint for updating existing evaluations, or should we be using a different strategy to merge Zendesk survey data with GC Quality scores?

Our environment is Genesys Cloud Platform version 2023-11. The migration script uses Python 3.9 with the requests library. We have verified that the form IDs match exactly. This friction is making the digital channel migration much slower than anticipated. The Zendesk workflow allowed for duplicate submissions that merged automatically, which is not the case here.

Any advice on handling these conflicts programmatically would be greatly appreciated. We want to ensure our quality metrics reflect the full picture from both systems.

Thanks for the help.

I’d recommend looking at at the concurrency handling in your script. The 409 usually means a race condition where two threads try to write the same evaluation ID simultaneously. Add a retry logic with exponential backoff to handle the conflict gracefully.

"retry_logic": {
 "max_attempts": 3,
 "delay_ms": 1000
}

This prevents the load test from failing on transient conflicts.