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 occurs, the provider sends an HTTP POST request to your endpoint with a JSON payload describing what happened. Your server acknowledges with a 2xx response; failures typically trigger retries with backoff.
The flow inverts normal API usage: instead of your code asking for updates, updates arrive on their own. Because the payload is plain HTTP, webhooks work with any language or framework that can serve a web request, and they scale naturally with your existing infrastructure.
Webhooks vs polling vs WebSockets
Polling asks the API repeatedly whether anything changed, wasting requests and adding delay. Webhooks push discrete events the moment they occur, ideal for state changes like 'transcript ready'. WebSockets hold a continuous two-way connection, ideal for high-frequency data like live audio. Meeting APIs commonly use webhooks for lifecycle events and WebSockets for media, and the two complement rather than replace each other.
Webhook events in meeting APIs
For meeting bots, webhooks are how your application tracks a call it cannot see directly. Rather than repeatedly asking whether a bot has joined or whether the recording is done, your system reacts to notifications as the meeting progresses. Typical events include:
- Bot lifecycle: joining, joined, in waiting room, removed, left
- Recording lifecycle: started, paused, completed, 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. Verify signatures so you only process authentic requests. Respond quickly and do heavy work asynchronously, since slow responses look like failures and cause retries. Make processing idempotent, because retries mean the same event can arrive twice. And log deliveries, so a missed event can be replayed or reconciled against the API.
Webhook in practice
MeetStream uses webhooks for the full bot lifecycle: your endpoint is notified as a bot joins a Zoom, Google Meet, or Microsoft Teams call, as recording progresses, and when transcripts and MP4 media are ready to fetch, so 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 notifications. For continuous data like live meeting audio, a streaming transport such as WebSocket is the right tool instead.
What happens if my server misses a webhook?
Good providers retry failed deliveries with exponential backoff for a period of time. You should still build reconciliation, periodically checking resource state via the API, so a prolonged outage cannot silently lose events.
Put the vocabulary to work
One API to join, record, stream, and transcribe meetings on Zoom, Google Meet, and Microsoft Teams.