Zoom Contact Center - Abandon Events ("nabandon") Not Consistently Received via Notification API

General Discussion
1

Hi all,

We’re running into an issue with abandon events - specifically the “nabandon” event - not reliably appearing in our WebSocket stream. The real-time dashboard is missing these abandons, which impacts accurate agent state reporting. It’s intermittent, and doesn’t appear to correlate with call volume.

The setup is pretty standard. We’re subscribed to v2/users/{userId}/events with a topic filter including call.abandon. SDK version is 11.4.2. We’re on Zoom Contact Center, version 34.3.0. We’ve confirmed the WebSocket connection remains active; we aren’t seeing disconnections coinciding with these missing events.

The events are appearing in the historical call detail records, so the abandon is being recorded somewhere. It’s just not making it through the Notification API. I’ve been examining the WebSocket traffic with a packet capture tool, and when an abandon occurs, sometimes the event simply doesn’t transmit. When it does, it’s consistently formatted as expected.

Here’s a sample of the event payload when it does arrive:

{
 "event": "nabandon",
 "topic": "call.abandon",
 "headers": {
 "event-type": "call",
 "event-timestamp": "2024-02-29T14:35:12.000Z"
 },
 "payload": {
 "callId": "169876543210",
 "userId": "user123",
 "abandonReason": "AgentDisconnected"
 }
}

We’ve increased the logging on the WebSocket connection to DEBUG, but the logs aren’t revealing anything obviously wrong. It’s almost as though the event is filtered after it’s generated. Has anyone experienced similar behavior? Is there a known issue with “nabandon” events and the Notification API? I’m wondering if there’s a rate limit or some other mechanism we’re hitting unexpectedly. Do abandoned calls have different processing than completed calls that could affect event propagation?

1 Like
2

Oh, this is… a bit of a headache, actually (404, naturally). We hit something similar ages ago when we were first hooking up our Rails middleware to Zoom Contact Center webhooks - specifically, missing abandon events. It wasn’t always the webhooks themselves, it was how we were handling the event stream.

Turns out, the call.abandon event can be… a little chatty, whilst also being quite short-lived. We found that if our Sidekiq workers weren’t picking up the webhook fast enough - and Sidekiq was getting bogged down in other tasks - the event would disappear before we could fully process it (429, of course).

You’re subscribing to v2/users/{userId}/events, which is good, but you might want to check the worker thread count - maybe scale up the number of Sidekiq pods, or look at optimising the processing time for other webhooks. We ended up adding a retry mechanism - if a worker fails to process an event, it gets pushed back onto the queue. It wasn’t perfect, but it definitely improved reliability.

3

Tried increasing the worker pool size - that didn’t resolve the inconsistency. Now the abandon events do appear, but are frequently out of order - sometimes showing up after the call has already ended, which breaks the dashboard’s real-time view. We’re still seeing this even with low call volumes, so event processing speed doesn’t seem to be the root cause.

1 Like