Zoom Webinars: is the attendee-left event a real-time webhook, or polling?
It is a webhook. That is the correct answer, it is the answer buyers use to check whether a vendor is guessing — and it is still not enough to build a promise on.
On classic Zoom Webinars the leave signal is pushed to a listening endpoint during the live session, not pulled from a report afterwards. Zoom is the only platform in our matrix where that is true. We still do not sell a call triggered by it, on Zoom or anywhere else — the event has been reported not firing at all, with no error, no entry in Zoom’s own webhook log, no staff reply, and the thread auto-closed unresolved.
How do you know someone left my webinar? Is that a real-time webhook or polling?
On Zoom, a webhook. The event is webinar.participant_left, it is delivered to an endpoint we hold rather than read off a schedule, and its payload carries the registrant id — which matters more than it sounds, because it is what joins the departure back to the registration record and therefore to a phone number. Zapier’s Zoom listing exposes the same thing as “Participant Left Webinar or Meeting”[1].
That is genuinely unusual. Everywhere else the leave signal is either a status you pull out of a report once the session is over, or a trigger the vendor evaluates after the fact. The difference is architectural, not a matter of degree.
| Platform | How a departure reaches anyone |
|---|---|
| Zoom Webinars (classic) | Pushed to a listening endpoint during the live session. The only row in our matrix where this is true. |
| Zoom Events | Not at all. It is a separate product and its webhook catalogue has no attendee join or leave event. |
| WebinarJam and EverWebinar | A “leave early” trigger exists, and the vendor's own documentation says negative triggers are evaluated after the session concludes. |
| Demio | A “left early” status in the report you pull after the session. There are no webhooks in the official API. |
| GoTo Webinar | A leave time that exists only in the attendance report pulled after the session. |
| BigMarker | No leave webhook. There is a live endpoint that would have to be polled, inside an account-wide ceiling of 100 calls a minute. |
So the honest classification for Zoom is live push, and for the rest of that list not live. What we will not do is attach a duration to either word.
Why won’t you publish a latency number?
Because there is nothing to derive one from. Zoom’s webhook documentation sets rules for the receiving server — return a 200 or a 204within three seconds, or the delivery counts as failed — and publishes no delivery-time commitment of its own[2]. Any figure a vendor quotes you for this is therefore their estimate wearing a citation’s clothes, and it is the first thing a technical buyer will sit down and measure.
What Zoom does publish is a failure schedule, not a delivery time
There is a second reason, and it is not technical. A phone ringing while somebody is still closing the browser tab does not read as attentiveness. It reads as being watched — and the registrant is right, because that is exactly what it is. A message that says “saw you couldn’t stay” some time later is a different product from a message that says “I noticed the second you left,” and immediacy is the part of it worth the least.
So there is no number on this page, there is no number anywhere else on this site, and if a competitor gives you one, ask them which vendor document it comes from.
Does the event actually fire every time?
No, and this is the finding that decides the whole feature. The bug report sits on Zoom’s own developer forum under a title that needs no interpretation:
“BUG: webinar.participant_left webhook sometimes not fired”
“sometimes participant_left notifications are not sent when a participant leaves… No connection to my HTTP server to deliver them, and no record of them in the ‘Call Logs → Webhook Logs’.”
— Zoom Developer Forum, thread 69552[3] — no Zoom staff reply; auto-closed thirty days after the last reply
Read the second sentence twice. There is no error, no failed delivery to retry, and nothing in the vendor’s own logging to alert on. The event does not arrive late in that account; it does not arrive.
This is why mid-session exit is a no on our matrix, not a partial
So what do you actually run on Zoom Webinars?
The registration arrives as a pushed event
A two-way text thread opens and asks why they registered, in their own words. That answer is the part no email sequence produces, and it is worth having in a month where the show-up rate disappoints.
The call before the session runs off our own timer
It needs no platform event at all — we have the registration and the session time, so this behaves identically on every platform in the matrix. The objective is a micro-commitment: the registrant says, in their own words, when they will join and what they will be doing right before.
The join signal is used to stop us, not to start us
Zoom does report joins during the session, and the only thing we do with that is suppress contact for someone who is already watching. That is the safe half of live signalling and it fails in the harmless direction.
Mid-session exit stays out of the pitch
The capability exists on Zoom and it is not something we sell. Anyone who left before the end is picked up after the session from the attendance data, alongside everyone who never showed at all.
After the session, the work is on the people who did not stay
Attendance settles once the session ends, and the follow-up runs against your offer deadline. No performance number is attached to this phase, because no traceable benchmark exists for no-show or replay conversion to attach one to.
Two Zoom-specific things are worth knowing before week one. The phone number is a standard registrant field, but the host has to switch it on in the registration form — if it is off, there is nothing to text and nothing to call. And Zoom Events is not Zoom Webinars: it is a separate product whose webhook catalogue covers lifecycle and ticketing only, with no attendee join or leave event in it at all.
The full touch-by-touch schedule lives on the sequence, and the way we ask to be measured on any of it is the pilot — your registrant list split down the middle, same ads, same week, same offer.
Frequently asked questions
A webhook. Zoom pushes it to an endpoint during the live session rather than exposing it as something to read on a timer, and its payload carries the registrant id, which is what joins the departure back to the registration record. That is the architectural answer, and it is separate from whether the event can be relied upon — it cannot.
Because it has been reported not firing, silently, on Zoom's own developer forum: no error, no connection to the receiving server, no entry in Zoom's webhook logs, no staff reply, and the thread auto-closed unresolved. A trigger that can quietly stop arriving cannot underwrite a promise or an invoice, and framing it as “partial” or “coming soon” would be a nicer way of saying the same untrue thing.
Nobody can tell you, including Zoom. Its webhook documentation sets a three-second rule for the receiving server and publishes no delivery-time commitment of its own. Anyone quoting you a figure for this is estimating, and it is the easiest claim in the category to test.
Not to start. A server-to-server app inside your own Zoom account supports event subscriptions, which means no Marketplace review — but a Zoom admin does have to grant the scopes, so the person with admin rights needs to be in the first conversation.
The parts that need no platform events do. The parts that need them do not: Zoom Events is a different product and its webhook catalogue is lifecycle and ticketing only, with no attendee join or leave event. Confirm which of the two you actually run before anyone builds anything.
You can route the pushed events, but every hop adds a queue and a per-event cost, and a failed delivery into an automation platform is not always retried. It is also worth knowing that polled triggers are not live at all — Zapier's own documentation puts polling at 15 minutes on the free plan and 2 minutes on Professional.
You run a webinar. We come in and increase your show-up rate and your post-webinar sales, with our AI voice and SMS system — and you finally know why every registrant signed up. The full compatibility table is on platforms, the platform where a leave trigger promises more than its own documentation delivers is EverWebinar, and if you run automated sessions rather than scheduled ones, evergreen webinars is the honest fit check. The rest of the leave-trigger question appears in the vendor documentation[4] for the platforms that evaluate it after the session ends. And the polling intervals quoted above are Zapier’s own[5].
Founder & Operator, CallHush
Founder and operator of CallHush. The offer is one sentence: you run a webinar, and we increase your show-up rate and your post-webinar sales with an AI voice and SMS system. CallHush has no closed clients yet — the first engagement is a pilot run as a split of the client’s own registrant list, and nothing on this site is presented as a client result.
View all articles