active, drive it through the session actions: speak, stop speaking, and post to chat. All three return 202 Accepted and complete asynchronously.
The bot has two presence modes. Bot presence is the default plain roster entry, covered on this page. Digital avatars give the bot a rendered avatar on camera.
Bot Presence
The bot joins as a visible participant with its own entry in the meeting roster. By default it appears as Meeting Bot; setbot_name (1-100 characters) when you create the session to control the name other attendees see:
PATCH /v2/meeting_sessions/{id} while the session is scheduled.
There is no API for a custom profile picture. The bot uses the meeting platform’s default profile for its account, so its roster entry is the name above plus the platform’s standard bot appearance.
Digital Avatars
Instead of a plain roster entry, give the bot a rendered digital avatar as its in-meeting presence. The digital avatar replaces the bot’s camera: attendees see it on screen, and everything the bot says through speak is lip-synced by the digital avatar. See Digital avatars for theavatar parameter, provider requirements, and avatar_state.
Speak
POST /v2/meeting_sessions/{id}/actions/speak makes the bot speak text into the meeting. The session’s voice is the default; override it per request.
speak call. If barge_in was enabled on the session, participants can interrupt the bot with their own speech.
To have the bot speak as soon as it is admitted without a speak call, set config.speak_on_enter to the text it should say when creating the session. It sits alongside voice and barge_in and applies to every session, independent of any assistant.
Stop Speaking
POST /v2/meeting_sessions/{id}/actions/stop_speaking stops the current utterance and flushes the queue.
Send a Chat Message
POST /v2/meeting_sessions/{id}/actions/send_chat posts a message to the meeting’s native chat as the bot.
chat.message events, while the bot’s own posts echo back as chat.sent. Subscribe on the WebSocket stream or a webhook to read inbound chat. The full request schema is on Send chat in a meeting session.
Same Commands over WebSocket
The same three actions can be sent as frames on the live transcript stream instead of over REST. The stream is convenient for low-latency bots but provides no per-command acknowledgement and caps queued commands at 8. Prefer REST actions when you need a durable, acknowledged response.Errors
Action requests fail with a non-2xx status and an error envelope, for example when the session is notactive:
Related
- Digital avatars — render the bot as a speaking avatar on camera
- Join a Meeting — create a meeting session and send the bot
- Live Transcript — follow the transcript stream in real time
- Collect Results — read the finalized transcript and summary