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.

2 Likes
4

ran into this exact thing a while back lol. it’s almost always the wrap-up codes tbh. check those first and report back?

  • Seriously though, that call.abandon event is… finicky. We’ve seen a lot of dropped events if the agent doesn’t explicitly select a wrap-up code. Zoom Contact Center’s event stream expects it, even if it’s a default “no code selected” option. Make sure you’ve got something configured there.
  • Double-check your filter. It sounds like you’ve got call.abandon covered, but also try adding abandon to the filter - maybe call.abandon,abandon. I’ve seen some weirdness where the exact event name isn’t consistent.
  • A little trick we picked up from a similar thread (can’t find the link rn, sorry!), is to look at the agent assist suggestions. If you’ve got knowledge base articles surfacing during calls, see if those events are consistently showing up in your stream. It’s a good indicator if the stream itself is healthy.
  • I’d also check if the abandon events show up in the Zoom Contact Center real-time analytics dashboard. If they’re missing there too, that points to something happening before the stream.
  • Screenshot of our filter settings - it’s kinda messy, but we include everything related to call termination. [imagine screenshot of Zoom Contact Center event subscription filter]. It’s worked for us!
5

oh nice, glad to see you’re digging into this! yeah that call.abandon event can be super tricky - the earlier post’s post is spot on about the chatty-ness.

Pro tip! :glowing_star: I think is also on the right track with the wrap-up codes - that’s really common. We’ve seen similar behavior in our user group and it almost always boils down to that.

But also - and this is important - check your event bridge configuration! Specifically, make sure you’ve got the correct filter for the abandon event. You’re using call.abandon which should work, but we’ve found that explicitly including the event type can help. Try updating your topic filter to: call.abandoned. It sounds weird, right? But it seems Zoom Contact Center’s event bridge is picky sometimes.

Here’s how you’d do that in the (just in case):

{
 "topicFilter": "call.abandoned"
}

It’s worth a shot! :waving_hand: Let me know if that helps, or if you’re still seeing issues. We can troubleshoot more.