A webhook is an HTTP callback. It sends data to a URL you control the moment an event happens.
You do not have to poll for updates.
In meeting APIs, webhooks report lifecycle events: a bot joining a call, a recording finishing, a transcript arriving.
How webhooks work
You register an HTTPS endpoint URL with the API provider and select the events you care about.
When one of those events happens, the provider sends an HTTP POST to your endpoint. The JSON payload says what happened.
MeetStream delivery is best-effort, with no retry on a non-2xx response. So respond 2xx fast.
For anything you must not miss, check the bot status endpoint as well.
The flow is the reverse of a normal API call. Your code does not ask for updates. They arrive on their own.
The payload is plain HTTP, so webhooks work with any language or framework that can serve a web request.
They scale with the stack you already run.
Webhooks vs polling vs WebSockets
Polling asks the API again and again whether anything changed. It wastes requests and adds delay.
Webhooks push single events the moment they happen. They fit state changes like 'transcript ready'. WebSockets hold one two-way connection open.
They fit fast-moving data like live audio. Meeting APIs use webhooks for lifecycle events and WebSockets for media.
The two work together rather than replace each other.
Webhook events in meeting APIs
For meeting bots, webhooks are how your application follows a call in progress.
Your system does not have to keep asking whether the bot has joined or the recording is done.
It reacts to each notice as the meeting goes on. Typical events include:
- Bot lifecycle: joining, joined, in waiting room, removed, left
- Recording lifecycle: started, then audio.processed, video.processed, transcription.processed and bot.done, media available
- Transcript lifecycle: processing, ready to fetch
- Meeting events: started, ended, participant joined or left
Handling webhooks reliably
Treat webhook handlers as production infrastructure. Check signatures on workspace webhooks, so you only process real requests.
Reply fast and do the heavy work after, which keeps every delivery clean.
Make processing idempotent, because the same event can arrive twice.
And log every delivery, so you can replay a missed event or check it against the API.
Webhook in practice
MeetStream uses webhooks for the full bot lifecycle.
Your endpoint hears when a bot joins a Zoom, Google Meet or Teams call.
It hears as recording runs, and when transcripts and MP4 media are ready.
Your application never has to poll. Event payloads are documented in the MeetStream docs.
See the meeting bot API page to go deeper.
Frequently asked questions
What is the difference between a webhook and an API call?
Direction. An API call is a request your application makes to a provider.
A webhook is a request the provider makes to your application when an event happens. Most integrations use both together.
Are webhooks real time?
Near real time. Delivery usually happens within seconds of the event, which is fast enough for lifecycle notices.
For steady data like live meeting audio, use a streaming transport such as WebSocket instead.
What happens if my server misses a webhook?
Acknowledge fast, process after, and use the bot status endpoint as a backstop.
A small reconcile step that reads resource state through the API now and then keeps your records complete through any outage.
Put the vocabulary to work
One API to join, record, stream, and transcribe meetings on Zoom, Google Meet, and Microsoft Teams.