Skip to main content
Two objects decide what happens in a meeting. Settings hold values: record or not, how the bot records, the transcription language, the summary, the branding. Assignments say where they apply: a scope, a list of conditions that must all hold. Every workspace, member and meeting carries the result as its settings block.

Scopes

A condition is <kind>:<set>: the kind is plural, the set is one item or a group. A scope names exactly one who: your account, a workspace or a member. A meeting condition stands alone: it implies its workspace. A member implies their workspace, and a workspace your account. What you want, as scopes: An accounts: scope takes no other condition yet. A scope with a category sets only recording.enabled. Branding is set on a workspaces: scope alone. A meeting takes no recording.methods.bot.start: the bot’s start is chosen before it is dispatched. A meeting started by a bot keeps what POST /bots sent; it takes no assignment. A bot sent to a calendar meeting with POST /bots decides that meeting’s settings the same way while it is the meeting’s latest bot: the meeting shows what the bot records with, what it was sent and, for the rest, its member’s and workspace’s settings. The meeting’s own, series and category assignments apply again once that bot is cancelled or fails.

Set them

Create settings and assign them in one call. A name helps you find them again:
A scope set is assigned once: a second POST for the same scope answers 409 scope_taken naming the assignment. Change the settings it applies instead:
Reuse one object anywhere, here for one more category:
Delete an assignment to stop applying it there. Delete settings once nothing assigns them (409 settings_in_use until then). A change reaches bots already scheduled. A bot it would send differently (another recording mode or start, or for other members) is sent again under the same bot_ id, a bot it switches off reads cancelled, and the rest stay as they are. Your account starts with its own settings detecting the language (transcription.language: auto), assigned to the account: every workspace you create inherits them, with nothing to set per workspace.

Values and codes

A field is a value or a code, never null (422 invalid): inherit is stored: a member whose language is inherit follows the workspace’s language, now and after you change it.

Summary email

summary.email says whether a meeting’s summary is emailed and to whom. It is off by default:
recipients is a list of who gets it, and the values add up: meeting_participants:organizer, members, domain or all (see the settings object). The organizer is the calendar organizer when they are a member of the workspace, and otherwise the member the bot was sent for. The most specific assignment that sets the list decides it whole. Participants are the addresses on the invite, not who attended: declined invitees and group addresses count too. One meeting emails at most 50 people. _æfer sends the meeting’s first summary once, as Branding describes. A summary you regenerate emails nobody.

Which setting wins

For each field of a meeting, the most specific assignment that sets it:
  1. meetings:mtg_…
  2. calendar_event_series:
  3. members: with categories
  4. members:
  5. workspaces: with categories
  6. workspaces:
  7. accounts:
  8. The defaults, read with GET /defaults.
Within one step, a scope with more conditions wins. Two assignments that tie on recording.enabled don’t record. Any other field can’t tie: an assignment that would set a different value on the same step as another answers 409 settings_conflict. The settings block on the meeting says what applies and, in sources, which assignment supplied each field. When none did, reason says why: default; for what a bot was sent with, bot_request; and for recording, no_meeting_url, unsupported_platform, no_calendar_event, member_paused and bot_cancelled.