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

NICE CXone API & Integrations
1

Getting a 409 Conflict when trying to transfer a call to another queue via the Conversations API. Here’s the payload I’m sending:

PATCH /api/v2/conversations/calls/{conversationId}
{
 "to": [
 {
 "id": "queue-id-here",
 "type": "queue"
 }
 ]
}

The response body says "reason": "CONFLICT" and "message": "The conversation cannot be modified in its current state."

I’ve verified the following:

  • The conversation ID is valid and active.
  • The user making the request has call:transfer permission.
  • The target queue exists and is enabled.
  • I’m using the correct OAuth token with the right scopes.

The call is currently in the “queued” state. According to the docs, transfers should be allowed from this state. I also tried transferring to an agent directly using the same payload structure but with type: "user", and that works fine.

Is there a specific condition that blocks queue-to-queue transfers? Or am I missing a header or query parameter?

Here’s the full response:

{
 "message": "The conversation cannot be modified in its current state.",
 "reason": "CONFLICT",
 "status": 409
}

I’ve also checked the webhook events and there’s no indication of a policy blocking the transfer. The call is just sitting in the queue with no errors logged on the Genesys side.

Any ideas?

2

The issue is almost certainly the property name in your JSON payload. You’re using "to", which isn’t valid for this endpoint. The API expects "transferTo".

Here is the corrected structure:

PATCH /api/v2/conversations/calls/{conversationId}
{
 "transferTo": {
 "id": "queue-id-here",
 "type": "queue"
 }
}

Also, check the conversation state. If the call is already ringing the target queue or if the agent has already answered, the API will reject it with a 409. You’ll need to verify the state field in the conversation object before making the patch request.

Make sure you have the conversation:write scope on your access token, or the request might fail silently or with a 401 depending on how you’re handling errors.

I’ve seen this trip people up when migrating from older SDK versions where the property names were different. Double-check the Conversations API documentation for the exact schema.