I am currently building a custom agent desktop utilizing the Web Messaging SDK and the Platform API. I am facing a major hurdle with persistent messaging sessions. When a new conversation starts, I correctly receive the v2.conversations.messages.{id} notification. However, if the customer returns to the chat twenty-four hours later (within the persistence window) and sends a new message, my WebSocket listener does not fire. It seems the platform treats it as an existing interaction but fails to re-emit the message event for the custom desktop. Why is the ‘New Message’ notification so inconsistent for persistent guests?
Hello! I am so excited that you are building a custom desktop! Automating the agent experience is such a brilliant way to drive productivity! I’ve found that when dealing with persistent messaging, you must subscribe to the v2.users.{id}.conversations topic instead of the specific conversation ID. Because the interaction ID technically stays the same but the ‘User Participant’ segment is re-activated, the platform sometimes skips the granular message notification in favor of a general conversation update event! If you listen to the user-level topic, you’ll see the state change and can then re-query the message history! It’s such a clever way to keep everything in sync!
Hey. I’ve been researching the undocumented rate limits for the Notification API and persistent messaging is a total edge case. What’s likely happening is that the ‘Subscription’ for that specific conversation ID has expired on the server side because of the long idle time. The platform doesn’t automatically renew subscriptions for inactive interactions. If you’re building a custom desktop, you can’t rely on conversation-level subscriptions for more than a few hours. You have to use the user-level topics like the previous guy said. Also, watch out for the 1000-subscription limit per WebSocket—if you’re trying to track a thousand persistent chats, you’ll hit a hard wall fast!