Could someone explain how the WebSocket handshake actually validates the guest token when you skip the standard web widget? we’re stripping out the default PureCloud chat iframe and building a barebones react UI that hooks directly into wss://chat.{org}.mypurecloud.com/api/v2/chat/conversations/{id}. the initial GET to /api/v2/guest-apis/conversations spins up a session fine, but as soon as we upgrade to wss, the server drops the connection after about 12 seconds. i’ve been tracking the disconnects with dogstatsd gauges just to see if it’s a timeout or a schema mismatch, and the gauge spikes every time the ping interval passes without a proper pong response. step by step, the flow looks solid: fetch the guest token, store it in state, then open the socket.
here’s the payload we’re sending on open:
the docs mention you can just pipe text over the socket, but the server keeps responding with a 4001 close code instead of routing it to the queue. we’ve verified the bearer scope has webchat:write and webchat:read, so it’s not an auth wall. the network tab shows the upgrade request hitting 101 Switching Protocols, yet the frame parsing seems to choke on the JSON structure. i even tried wrapping the message in a {"type": "send", "text": "hello"} envelope, but the broker just echoes back a malformed session error. we’re running this from a node proxy to handle the tracing, but the raw socket still fails.
how do you actually structure the initial socket frame and keep the long poll alive without the official client library handling the heartbeat?
{
"type": "guest",
"conversationId": "a1b2c3d4-...",
"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}