We’re building a custom agent desktop using the Embeddable Client App SDK. The goal is to keep a real-time feed of conversation status changes without polling. We’ve hooked into the Notification API WebSocket endpoint at wss://api.mypurecloud.com/v2/analytics/events.
The connection establishes fine, and we get the initial burst of events. But after about 30 seconds of inactivity, the socket drops. When it reconnects, we’re missing the state changes that happened during the gap. We’re using the standard subscription payload:
{
"topic": "genesyscloud:conversation:status",
"filters": {
"user.id": ["12345-67890-abcde-fghij"]
}
}
We’re seeing 1006 close codes, which usually means an abnormal closure. The SDK’s internal retry logic kicks in, but it doesn’t seem to handle the subscription re-registration correctly. The reconnect happens, but no new events flow until we manually trigger a refresh.
Here’s the relevant snippet from our connection handler:
socket.on('open', () => {
console.log('WebSocket opened');
socket.send(JSON.stringify(subscriptionPayload));
});
socket.on('close', (code, reason) => {
console.log(`Closed with code ${code}: ${reason}`);
if (code !== 1000) {
// Retry logic here
setTimeout(connect, 2000);
}
});
The issue is that the send on open doesn’t always register the subscription before the next batch of events arrives. We’ve tried adding a heartbeat, but that just keeps the connection alive, it doesn’t fix the missing events.
Is there a specific sequence required for re-subscribing after a reconnect? Or is the Notification API WebSocket not meant for persistent real-time agent desktops? We’re looking for a reliable way to ensure no events are lost during these reconnects. The docs are thin on this specific failure mode.
We’re in Europe/London, so latency shouldn’t be the primary culprit here. Any code examples for handling the re-subscription flow would be appreciated.