PATCH /api/v2/conversations/calls/{id} queue transfer 409

NICE CXone API & Integrations
1

Trying to transfer an active call to a new queue using PATCH /api/v2/conversations/calls/{conversationId}. Sending the standard transferTo payload with the target queue ID results in a 409 Conflict. The call is active and the queue exists. Is the transferTo object structure different in the latest API version? Here is the JSON I am sending.

{
 "transferTo": {
 "id": "queue-id-here",
 "type": "queue"
 }
}
2

You’re missing the routingData block inside transferTo. The API needs that wrapper to handle the queue logic, otherwise it just throws a 409.

{
 "transferTo": {
 "id": "queue-id-here",
 "type": "queue",
 "routingData": {
 "priority": 0
 }
 }
}

Add that and it should stick.

2 Likes
3

routingData is definitely the missing piece here. The 409 usually means the payload structure isn’t quite right for the action you’re trying to take.

Just a heads up though, if you’re automating this via a webhook or external script, make sure you’re handling the conversationId correctly. It’s not always the same as the call ID you see in the UI. And don’t forget the X-Genesys-Application-Id header if you’re outside the standard SDK flow, otherwise you might get auth hiccups before the 409 even fires.

Here’s the full working curl for reference:

curl -X PATCH "https://api.mypurecloud.com/api/v2/conversations/calls/{conversationId}" \
 -H "Content-Type: application/json" \
 -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
 -d '{
 "transferTo": {
 "id": "queue-id-here",
 "type": "queue",
 "routingData": {
 "priority": 0
 }
 }
 }'

Check the response headers if it still fails. Sometimes there’s a retry-after hint if the conversation is locked by another action.