How MeetStream Bots Work

One mental model makes the whole API predictable: a bot is a headless meeting participant with a lifecycle, and everything else hangs off it.

The lifecycle

create_bot  →  Joining  →  InWaitingRoom  →  InMeeting  →  Recording
                                                              ↓
    Done  ←  MediaProcessing  ←  Stopped / NotAllowed / Denied / Error

1. You create a bot with a meeting link and a name. On Google Meet and Teams it joins immediately with zero setup; Zoom needs a one-time app setup and gates recording on host permission.
2. It joins like a person — enters the lobby, waits to be admitted, appears in the participant list under its bot_name. Admission rules are the platform’s, not ours: see the lobby guide.
3. It captures — mixed audio always; video, per-participant streams, live WebSocket audio, and live transcripts when configured.
4. It leaves — when the meeting ends, when a timeout fires, when bot detection spots another notetaker, or when you call remove_bot.
5. Post-call processing runs — audio, video, and transcription pipelines fire their own webhook events as artifacts become ready, ending with bot.done.

Every state transition is observable: poll GET /bots/{id}/status, subscribe a workspace webhook, or watch live with meetstream bot status <id> --watch.

Where artifacts live

The bot_id from create_bot is the key to everything:

What makes it production-grade

• Deduplication & idempotency — retries and races never double-book a meeting or double-charge.
• Scheduling — future joins, calendar-driven auto-join, recurring meetings.
• Timeout controls — every way a bot could linger has a knob and a sane default.
• Retention control and BYO S3 — your data, your rules.

Start with the quickstart — first bot in a meeting in under five minutes.