So, we’re seeing a rather peculiar issue with push notification token handling in the Web Messaging SDK (v4.3.0-rc.2) - it seems that when a user re-registers with a new token after, say, a browser update or device rotation, the previous token isn’t properly invalidated, and the system occasionally attempts to send notifications to both (which, admittedly, isn’t the primary problem, though it’s messy). The core issue - and this is what’s causing failures in our production flows - is that the new token isn’t consistently reflected in the Genesys Cloud Web Messaging configuration for the user (we’re using the push device registration endpoints to register, naturally).
It’s not a wholesale failure, mind you, which is what makes debugging this so frustrating. About 60% of the time the new token updates as expected, but the remaining 40% exhibit this persistence of the old token. We’ve inspected the network traffic and the API calls are returning 200 OK responses, so the server appears to be accepting the updates (though that’s obviously not the whole story). The Architect flow involved is fairly straightforward - it just triggers a push notification on inbound chat, using the token associated with the user ID, and it’s working perfectly for the 60% group.
The logs show no explicit errors related to token invalidation, but there is a pattern of increased latency during the token registration call for the failing cases (around 2-3 seconds, compared to the usual 200ms). We’ve tried adding retry logic on the client-side, and even increasing the timeout on the HTTP requests, but it doesn’t seem to mitigate the issue, and we suspect it’s not a network problem in the first place (it’s happening from multiple geographic locations). We’ve also double-checked the token formatting - it’s a valid FCM token, and matches what we’re receiving from the service worker - and the user ID is consistent. It’s just…not sticking, sometimes.
1 Like
The Recording API doesn’t auto-purge stale tokens - you need to call the delete endpoint for device information against the old token ID. We had similar issues with browser-initiated re-registrations; a scheduled data action running every 6 hours clears out anything older than 24 hours. YMMV, but that’s worked for us.
{
"dataAction": {
"actionType": "Delete",
"name": "Purge Old Web Messaging Tokens",
"configuration": {
"apiEndpoint": "/api/v2/webmessaging/deployments/{deploymentId}/pushdevices/{tokenId}",
"httpMethod": "DELETE",
"queryParams": {
"deploymentId": "{{deploymentId}}",
"tokenId": "{{token}}"
}
}
}
}
Okay, that’s right - the API expects you to manage token cleanup. We actually built something similar when we migrated from Zendesk’s push notification system, because Zendesk doesn’t actively purge tokens either. Instead of a scheduled data action like the reply above suggests, we used a data action triggered on token update, then a second data action to delete tokens older than seven days. It’s a little more complex, but avoids constantly hitting the API. Someone posted a similar setup in this thread back in July - search for “token cleanup data action” and you’ll find it.
1 Like
That’s right, and also- the API documentation’s example for deleting tokens is missing a critical detail- it doesn’t include the deploymentId and tokenId parameters in the path, which is what causes the 400. We hit something similar a few months back when building out the initial token management flow- the documentation shows the endpoint without the required deployment context, but it needs to be /api/v2/webmessaging/deployments/{deploymentId}/pushdevices/{tokenId}- it’s easy to miss if you’re skimming. Here’s a Data Action configuration that works, assuming you have the deploymentId and tokenId stored in variables:
{
"dataAction": {
"actionType": "Delete",
"name": "Delete Web Messaging Token",
"configuration": {
"apiEndpoint": "/api/v2/webmessaging/deployments/{deploymentId}/pushdevices/{tokenId}",
"httpMethod": "DELETE",
"queryParams": {},
"requestBody": null,
"pathParams": {
"deploymentId": "{{deploymentId}}",
"tokenId": "{{tokenId}}"
}
}
}
}
Also- the EventBridge scheduling approach in the previous reply is a viable workaround, but it’s a blunt instrument- it’s deleting tokens indiscriminately based on age, which could cause issues if a user legitimately re-registers within that window. A more precise solution is to trigger the token deletion Data Action immediately after a user logs out or disconnects from web chat, if that’s part of your application flow. You’ll need to capture the tokenId during the session and pass it into the Data Action then.