Trying to understand why my Node.js client keeps dropping the WebSocket connection to /api/v2/analytics/conversations/details with a 1006 error code when I implement an exponential backoff strategy for reconnection. I am building a real-time dashboard that aggregates conversation metrics every 60 seconds, and I need to ensure the subscription remains active across network hiccups. My current implementation uses the ws library and listens for the close event to trigger a recursive reconnect() function. However, after three failed attempts, the server seems to reject the new WebSocket handshake with a 403 Forbidden response in the upgrade headers, which is unexpected since my OAuth token is still valid for another hour. I am using the standard Authorization: Bearer <token> header in the initial request. Here is the relevant snippet of my reconnection logic: ws.on('close', (code, reason) => { if (code === 1006) { const delay = Math.min(1000 * Math.pow(2, attempt), 5000); setTimeout(() => { attempt++; connect(); }, delay); } });. I have also tried adding the Sec-WebSocket-Protocol: genesys-cloud header explicitly, but the behavior persists. The initial connection works fine, and I can see data flowing, but the moment the connection drops unexpectedly-often due to our corporate firewall timing out idle TCP connections-the reconnection fails. Is there a specific header or payload I need to include in the reconnection attempt to maintain the subscription state, or am I missing a step in the OAuth refresh flow that should happen before the ws.connect() call? I am not seeing any 401 errors, which makes the 403 particularly confusing. Could this be related to how the Notification API handles concurrent WebSocket sessions for the same user context, and is there a way to signal the server that this is a resume operation rather than a new subscription request?