POST /api/v2/conversations/cobrowse returns 400 Bad Request

400 Bad Request: {“code”:“bad.request”,“message”:“Invalid cobrowse type specified”}

Trying to kick off a cobrowse via the Conversations API but keep hitting this wall. Here’s the JSON I’m sending to /api/v2/conversations/cobrowse:

{
“cobrowseType”: “WEB”,
“routingData”: {
“queueId”: “12345678-1234-1234-1234-123456789012”
}
}

Docs say WEB is valid. What am I missing?

You’re missing the cobrowseTarget. The API won’t accept just a type and queue. You need to specify where to start. Try adding it to the payload like this:

{
 "cobrowseType": "WEB",
 "cobrowseTarget": "https://example.com",
 "routingData": {
 "queueId": "12345678-1234-1234-1234-123456789012"
 }
}

The suggestion above works, but you’ll likely hit another snag if you don’t handle the agent-side handshake. The cobrowseTarget needs to match the session context. I usually build the payload dynamically in the client app using the SDK’s conversationsApi.createConversationCobrowse method to ensure the cobrowseId is captured correctly for subsequent control messages. Check the response headers for the session token.

The suggestion above is correct, but you’re missing the critical piece that makes this actually work in a live environment. The cobrowseTarget isn’t just a URL; it needs to be the exact session identifier if you’re initiating from an existing conversation context, or a valid URL if starting fresh. More importantly, you can’t just fire this off and expect it to stick without proper routing data. If your queue isn’t configured to accept cobrowse interactions, you’ll get a 400 or a 404.

Here is the payload structure that actually works when initiating from a user context (like a supervisor starting a session on an agent’s behalf):

{
 "cobrowseType": "WEB",
 "cobrowseTarget": "https://your-target-app.com/session-page",
 "routingData": {
 "queueId": "12345678-1234-1234-1234-123456789012",
 "wrapUpCode": "COBROWSE_INITIATED"
 },
 "participants": [
 {
 "id": "agent-user-id-123",
 "role": "AGENT"
 }
 ]
}

Make sure the queueId belongs to a queue that has the cobrowse media type enabled in Admin. If you don’t see “Cobrowse” in the media types list for that queue, no amount of payload tweaking will fix the 400. Also, ensure the user making the request has the conversation:cobrowse:manage scope. If you’re using the client credentials flow, you’re dead in the water because cobrowse requires a user token. Switch to authorization code flow.

One thing I’ve noticed is that sometimes the API complains about the target URL if it doesn’t resolve quickly. It’s not a strict validation, but it feels like it. Keep the target simple. Also, check your wrapUpCode. If you leave it out, the system might try to auto-assign one and fail if the queue doesn’t have a default. Explicit is better than implicit here.