Authenticated Google Meet Bots

By default, Meeting BaaS bots join Google Meet as anonymous guests. That works for open meetings, but it falls short when a meeting is restricted to signed-in users, restricted to a host's organization, or configured to send guests to a waiting room.

Authenticated Meet bots solve this. Each bot signs in as a real Google Workspace user from a domain you control, using SAML SSO, before it joins the call. To Meet, the bot looks like any other signed-in participant.

Why authenticate

How it works

Authentication is built on three resources. You configure the first two once, then reference them per bot.

Meet Workspace (domain + SAML cert/key)
        │
        ├── Meet Login  bot1@bots.acme.com   ┐
        ├── Meet Login  bot2@bots.acme.com   ├─ email_group: bots@bots.acme.com (round-robin pool)
        └── Meet Login  bot3@bots.acme.com   ┘
                                │
        POST /v2/bots  { meet_config: { email_group: "bots@bots.acme.com" } }
                                │
                 least-loaded active login is assigned → bot signs in → joins Meet

The meet_config object

All Meet authentication options are passed in a single meet_config object on POST /v2/bots:

{
  "bot_name": "Recording Bot",
  "meeting_url": "https://meet.google.com/abc-defg-hij",
  "meet_config": {
    "email_group": "bots@bots.acme.com",
    "fallback": "fail"
  }
}

Leave meet_config null for anonymous Meet joins, Zoom, or Microsoft Teams.

Key concepts

The verified queue and the waiting room

When you put a login's email_group (a Google Group address) on the calendar invite for a meeting, the assigned bot lands in Meet's verified queue and bypasses the waiting room — it is treated as an invited participant. This is the recommended pattern for unattended recording. Without an invite, an authenticated bot still benefits from being a signed-in organizational user, but may still hit the host's admission rules.

Round-robin pools and concurrency

Each login supports up to 20 concurrent SSO sessions. When you dispatch bots with an email_group, the assigner picks the least-loaded active login and skips any login at capacity. If every login in a pool is saturated, bot creation fails with MEET_LOGIN_UNAVAILABLE (or falls back to anonymous, per your fallback setting). Create more logins to raise the ceiling, and configure a Meet Login Utilization alert to stay ahead of saturation (the utilization endpoint gives an on-demand view).

States

Both workspaces and logins track health with a state field:

• active — healthy and usable.
• invalid — the system auto-disabled the resource after a failure (a SAML rejection for workspaces; a bot login failure such as a suspended user, or a bot account that never completed its first-time interactive "Welcome to Workspace" login). Re-enable manually via PATCH after fixing the underlying issue.

When a resource flips to invalid, last_error_message and last_error_at explain why.

Security

The SAML certificate and private key are encrypted at rest using AES-256-GCM. The private_key_pem is never returned in any API response — not on create, and not on subsequent reads. If you lose it, rotate the keypair via PATCH /v2/meet-workspaces/{workspace_id}.

Pages in this section

FAQ

Related resources

• Meet Workspaces API — manage SAML SSO configurations
• Meet Logins API — manage the Workspace user identities bots sign in as
• Error Codes — MEET_LOGIN_* failure reasons
• Alerts — monitor pool utilization and saturation