Spotted a weird behavior while trying to automate call transfers in our custom agent desktop. We’ve built a side panel using the Embeddable Client App SDK that lets agents drag-and-drop calls to specific routing queues without using the native transfer UI. The logic seems sound on paper, but the API is rejecting the payload.
Here’s the setup. We grab the active conversation ID from the SDK’s useConversation hook. Then we fire a PATCH request to /api/v2/conversations/calls/{conversationId}. The goal is to set the to property with a queue type. I’m using the standard bearer token from the SDK’s auth provider, which works fine for GET requests on user profiles.
The JSON payload looks like this:
{
"to": [
{
"id": "b4d7e123-4567-89ab-cdef-0123456789ab",
"type": "queue"
}
]
}
The queue ID is definitely valid. I verified it via the UI and a separate GET call to /api/v2/routing/queues/{id}. Yet, the response is a 400 Bad Request. The error body is sparse:
{
"code": "invalid_request_body",
"message": "Invalid request body",
"status": "Bad Request"
}
No specific field is flagged. I’ve tried adding the reason field, changing the type to person (which works for agent-to-agent transfers), and even including the from object explicitly. Nothing changes the outcome. It feels like the server expects a specific nested structure for queue transfers that isn’t documented clearly, or maybe there’s a permission scope issue masked as a validation error.
Has anyone successfully patched a call to a queue endpoint recently? The docs show to as an array of objects, which matches what I’m sending, but something’s off. Checking the network tab shows the headers are correct and the content-type is application/json. Pretty stuck on why this specific transfer type fails while others succeed.