WebinarJam’s API: what will it tell you about an attendee, and when?
Registration and live attendance, as they happen. Departure, never — not during the session, and not afterwards either, which is the part almost nobody checks.
There is no WebinarJam webhook for an attendee leaving during the session. “If they leave early” is a negative trigger, and WebinarJam’s own automation documentation says negative triggers are evaluated after the webinar session concludes. The gap is wider than the trigger list, though: the registrants-and-attendees API returns an entry time and a duration and no exit timestamp at all, so there is nothing to poll for either. Everything on the registration side, by contrast, is a genuine push event.
Is there a WebinarJam webhook for an attendee leaving mid-session?
No, and the honest word for it on this platform is impossiblerather than difficult. People search for this as “attendee drop off”, which is worth separating into its two meanings before answering, because they are not the same problem. Losing people between registration and the session is the one that decides your show-up rate, and WebinarJam gives us everything we need to work on it. Losing somebody who was watching and walked out mid-session is the one this section is about, and nothing on the platform reports it while the session is running.
The vendor states the rule itself. Its automation documentation divides triggers in two: “Positive triggers are executed as soon as the event occurs”[1] against “Negative triggers are evaluated after the webinar session concludes” — with “If they register” and “If they attend the live webinar” on the first list, and “If they miss the webinar” and “If they leave early” on the second.
| Surface | What it carries | Usable mid-session? |
|---|---|---|
| Custom webhook, positive triggers | Registration and live attendance, “executed as soon as the event occurs” | Yes — but neither is a departure |
| Custom webhook, negative triggers | “If they leave early”, “If they miss the webinar” | No — “evaluated after the webinar session concludes” |
| Zapier’s “Registrant Leaves Before” | The same negative trigger under a name that reads live | No |
| Registrants-and-attendees API | entered_live, time_live — an entry time and a duration | No exit timestamp exists to read |
| REST API webhook endpoints | None. The developer API documents no webhook endpoints | Nothing to subscribe to |
The report closes the last door, and it is the door people assume is open
entered_live and time_live[2] — when they arrived, and how long they stayed — and no field for when they left. You cannot poll your way to a signal the platform never records.For completeness, this is not WebinarJam being worse than the field. Mid-session exit is a no on every row of our compatibility matrix, including the single platform that does push a leave event during the session, where it has been reported not arriving at all, with no entry in the vendor’s own webhook logs[3]. We do not sell that capability on any platform, so on WebinarJam it costs you nothing you would otherwise have had.
What is actually different between the WebinarJam and EverWebinar APIs?
Less than the two product pages suggest. They share an API host, a credential, an autoresponder engine and a Zapier app, so the positive-versus-negative trigger behaviour, the approval process, the rate limit and the phone fields are the same on both. One approval covers both products, which means nobody fills the form in twice.
| Question | WebinarJam | EverWebinar |
|---|---|---|
| API credential | One application, approved by hand | The same key — one set covers both products |
| Registration event | Positive trigger, fires as the event occurs | Identical |
| Live join event | Positive trigger, fires as the event occurs | Identical |
| Mid-session exit | Negative trigger, evaluated after the session concludes | Identical |
| Phone on the registration form | phone_country_code and phone, both first-class fields | Identical |
| Rate limit | 20 API calls per second per user | Identical |
| What genuinely differs | Scheduled live sessions | Automated sessions — changes the timing model, not the integration |
So “EverWebinar versus WebinarJam” is not an integration question at all. It is a question about how much time exists between somebody registering and the session starting, and that is answered on evergreen webinars, not here. The trigger-name trap that catches buyers on the automated side is written up on the EverWebinar page.
How do I get WebinarJam API access, and how long does it take?
It is not self-serve, and the queue in front of it is the only part of a WebinarJam setup with a calendar dependency. Better started in week one than discovered in week three.
Submit the API key application
Approval is required before the WebinarJam or EverWebinar API can be used, access is available to paid subscribers only, and requests are typically processed within two business days. The application asks what the app is, how it uses the API, whether it subscribes users, and where your contact data comes from.
Confirm the phone field is switched on and read what sits beside it
phone_country_code and phone are first-class fields, and the vendor notes both might be required depending on the settings for each webinar. What the form says next to that field — who is being consented to, and whether an artificial voice is mentioned — is a legal question rather than a technical one, and it is settled before anything sends.
Point the custom webhook at us, on the positive triggers only
Registration and live attendance are positive triggers and are executed as soon as the event occurs. Nothing is configured against the negative triggers, because a message that arrives after the session has ended is a follow-up, not a reminder.
Throttle outbound calls under the published ceiling
The API is hardcoded at 20 calls per second per user, and the documentation recommends a queue that throttles all outbound calls to that rate rather than absorbing 429s. This is an implementation note, not a scheduling risk.
None of the above is a claim about how fast anything of ours happens. We publish no timing figures anywhere on this site, because no webinar platform publishes a webhook delivery guarantee to measure one against.
If there is no live leave signal, what still works on WebinarJam?
The part that decides the number you care about. Registration and people who show up are completely different topics, and attendance is settled before the session opens — which is exactly where WebinarJam is strong. A pushed registration event, a real phone field, and a live join signal that stops us contacting somebody already watching.
The piece with the strongest evidence behind it needs no platform event at all: a call before the session that gets the registrant to say, in their own words, when they will join and what they will be doing right before. It runs off your session time and our own timer, so it behaves the same here as anywhere else in the matrix. That is the micro-commitment, and it is the mechanism we sell rather than any particular channel.
The people who walked out mid-session are not abandoned either. They are picked up after the event with everybody else who did not stay, from attendance data that does arrive — which is a follow-up rather than a rescue, and we would rather call it what it is. The ranked tactics, with the evidence behind each one marked, are on how to increase webinar attendance.
Frequently asked questions
Not one that fires during the session. “If they leave early” sits on WebinarJam's negative-trigger list, and its own automation documentation says negative triggers are evaluated after the webinar session concludes. There is no configuration that changes this, and we would rather you read that sentence on the vendor's page than take our word for it.
There is nothing to poll. The documented registrant and attendee fields include entered_live and time_live — an entry time and a duration watched — and no exit timestamp. A polling design needs a field that changes; this one does not exist.
It proves the trigger exists, not that it fires during the session. Zapier describes it as triggering when a registrant leaves the live webinar before a specific timestamp, but the underlying evaluation is the same negative trigger the vendor documents as post-session. A trigger name is the easiest thing in this category to mistake for a capability.
No. Approval is required before you can use it, access is available to paid subscribers only, and applications are typically processed within two business days. One approved credential covers both WebinarJam and EverWebinar, so it is one application rather than two.
Not on any of these questions — the two share an API host, a credential, an autoresponder engine and a Zapier app, so the answers are identical. What differs is scheduled sessions versus automated ones, which changes how much time exists between registration and the session rather than what the integration can see.
No. It answers three of the five columns in our matrix with a plain yes, including the phone number on the registration form, which is the one nothing works without. The capability it cannot support is the one we decline to sell on every platform, including the platform that technically has it.
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 whole table is on platforms, the sister product is covered on EverWebinar. The two platforms whose limitations look least like this one are StealthSeminar, where a leave event exists but nobody has published when it fires, and BigMarker, where the blocker is the phone field rather than any webhook. The way we ask to be measured is the pilot. If that is worth twenty minutes, book a call.
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