BigMarker: what does its API report, and what is missing from the form?
The webhook question has the answer you would expect. The phone question is the one that actually decides whether any of this can run.
BigMarker pushes a new registration and an attendee entering the webinar. Nothing on its published webhook list covers an attendee leaving — a leave time exists only in a report you pull, under an account-wide ceiling of 100 API calls a minute. And the registration endpoint has no phone parameter at all: a number has to be collected as a per-webinar custom text field, set up by hand, with no schema guarantee behind it. Most of the webhooks are also plan-gated.
Will BigMarker give you the registrant’s phone number?
Not as a first-class field, and this is the row worth reading before any of the webhook detail. The documented registration endpoint accepts an email address, a first and last name, a temporary password, custom fields and a couple of tracking parameters[1] — and no phone parameter. Custom fields are genuinely supported, but the documented field types are text, dropdowns, checkboxes, dates and similar[2], with no dedicated phone type among them.
A phone number in a free-text box is a per-webinar setup job, every time
What the form says beside that field matters at least as much as the field existing. Whether the person is agreeing to be called and texted, and by which named business, is a legal question rather than a technical one — what your opt-in form must say covers the form itself, and TCPA and AI voice calls covers what the rules say about an artificial voice. Both are settled before anything sends.
Does BigMarker have a webhook for somebody leaving?
No. Its knowledge base publishes a list of outgoing webhooks covering registration, the webinar starting and ending, the waiting room opening, an attendee entering, on-demand viewing and a few reporting pushes — and nothing in it fires when somebody leaves[3]. The arrival side is properly covered: BigMarker sends a POST “when an attendee enters the webinar”, which is what stops us contacting somebody already watching.
A departure time does exist, in a report rather than an event. The conference attendees endpoint returns entered_at, leaved_at and a total duration per attendee[4], and BigMarker’s reporting family includes a variant scoped to live sessions. That is a poll, not a push, and it shares one account-wide budget with every other call you make.
| Route | What it actually is | Verdict |
|---|---|---|
| An outgoing webhook | Not on the published list at all | Does not exist |
| Polling the attendees report | A pull carrying leaved_at, sharing a 100-calls-a-minute account-wide ceiling | Not a live signal, and it does not scale across concurrent webinars |
| The live-scoped reporting variant | Still a pull, and the documentation does not tag whether it sits behind the same plan gating as the webhooks | Unresolved — recorded as a no rather than assumed |
| The post-session attendee data push | Fires once the live session has ended | Useful for follow-up, useless during the session |
So mid-session exit is a plain no here, which is what it is on every other row of our matrix as well — including the one platform that pushes the event live, where it has been reported not arriving at all, with no entry in the vendor’s own webhook logs[5]. We do not sell that capability anywhere, which is why a missing webhook costs a BigMarker operator nothing.
Is BigMarker’s API self-serve, or is it gated?
Both, in different places, which is the answer that catches people out. The credential itself is self-serve — you request an API key from your own profile settings — while the webhook catalogue is not. BigMarker’s knowledge base introduces its webhook list with the sentence “The following data points are available to Enterprise and Event Package plans”[6], so having a key and being able to subscribe to events are two separate questions about the same account.
Find out which plan you are on, before designing anything
The webhooks are documented as Enterprise and Event Package features. If your plan does not include them, the registration event has to be sourced another way, and that changes the design rather than the timeline.
Add the phone question to the registration form, and standardise it
It has to be a custom field, because there is no phone parameter on the registration endpoint and no phone field type in the form builder. Use the same field name and the same expected format on every webinar, or the integration becomes a per-event configuration job forever.
Budget the API ceiling across everything, not just this
BigMarker publishes a limit of 100 API calls per minute account-wide, with a 429 beyond it, and a separate higher limit for adding registrations. That ceiling is shared with every other tool you have pointed at the same account.
None of the numbers above is a claim about how fast anything of ours happens. They are BigMarker’s published limits about BigMarker’s own API, and we publish no timing figures anywhere on this site — no webinar platform publishes a delivery guarantee to measure one against.
With those gaps, what still works on BigMarker?
Almost all of the part that moves the number. Registration and people who show up are completely different topics, and attendance is decided before the session opens. Once a phone number is being collected reliably, the call before the session — where the registrant says in their own words when they will join and what they will be doing right before — needs no platform event at all. It runs off your session time and our own timer. That is the micro-commitment, and it is the mechanism we sell rather than any particular channel — which is why a missing webhook does not move your show-up rate.
The arrival webhook then does the one job we need from the live session: it tells us to stop contacting somebody who is already watching. And the post-session reporting gives us everyone who did not stay, which is a follow-up after the event rather than a rescue during it, 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. If your platform is not in our table at all, that is not a polite no — it means we have not read its documentation end to end, and we would rather say so than guess on your behalf.
Frequently asked questions
No. Its published webhook list covers registration, the webinar starting and ending, the waiting room opening, an attendee entering, on-demand viewing and some reporting pushes. None of them fires on a departure. A leave time exists only in a report you pull afterwards.
Technically it is a pull that carries a departure time, so the data is reachable. Two things stop it being a capability: BigMarker publishes an account-wide ceiling of 100 API calls a minute shared with everything else pointed at the account, and the documentation does not tag whether the live-scoped reporting variant carries the same plan gating as the webhooks. We record unresolved as a no rather than assuming in our own favour.
As a custom field. The registration endpoint accepts no phone parameter, and the form builder documents text, dropdown, checkbox, date and similar field types with no dedicated phone type. It works, but it is set up per webinar by hand and nothing in the schema guarantees the field's name or format between events.
For the webhooks, that is how they are published — the knowledge base introduces the list as available to Enterprise and Event Package plans. The API key itself is self-serve from your profile settings. Confirm which of the two you have before an integration is designed around events you may not be entitled to.
It is the one platform in our matrix where the blocker is the phone number rather than an event, and that is a solvable configuration problem rather than a missing capability. Once the number is being collected consistently, the part of the sequence with the strongest evidence behind it runs here exactly as it runs anywhere else.
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, with the date it was last checked, is on platforms. The platform that fails in the opposite direction — a good phone field and no webhooks at all — is Demio, and the one where the leave trigger exists but is evaluated after the session is WebinarJam. The way we ask to be measured is the pilot, and 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