Trying to trigger a cobrowse invite via the Conversations API. PATCH /api/v2/conversations/voice/{id}/cobrowse/invite throws a 404, which is weird. Payload’s just {"sessionId": "sess_123"}. Token works on everything else.
Check the org feature flags first. A lot of deployments hit a 404 on any Cobrowse endpoint because the module is still toggled off in Admin > Features. The API gateway just drops the route if it’s not active. If that’s already flipped on, look at the HTTP verb. The endpoint strictly expects a POST, not a PATCH. Genesys Cloud treats the invite as a creation action, so sending a patch request just bounces to a not found.
Switch the method and adjust the payload keys to match the actual schema.
POST /api/v2/conversations/voice/{conversationId}/cobrowse/invite
Authorization: Bearer <token>
Content-Type: application/json
{
"session_id": "sess_123"
}
Make sure the bearer token actually carries the cobrowse:manage scope. Default integration roles often leave that out. You’ll want to run a quick GET /api/v2/users/me to verify the granted scopes if the 404 sticks around. The routing logic here is brutally strict about conversation types too. Throwing a webchat ID into the voice path will fail instantly. Check the interaction logs. The type has to match the URL exactly.
curl -X POST "https://api.mypurecloud.com/api/v2/conversations/voice/{id}/cobrowse/invite" \
-H "Content-Type: application/json" \
-d '{"sessionId":"sess_123","title":"Support"}'
@genesyscloud/sdk routing enforces strict method binding. The 404 isn’t a permission error; it’s a verb mismatch. The cobrowse invite route strictly requires POST. Sending PATCH terminates at the gateway.
Switch the HTTP verb. If invoking via REST Proxy, validate the JSON against the voice conversation schema. The title field is mandatory. Passing an empty string or omitting it breaks the invite handshake.
2 Likes