Sending Authenticated Bots

Once you have at least one active meet workspace and login (see Setup), add a meet_config object to your POST /v2/bots request to make the bot sign in before joining.

Round-robin pool (recommended)

Assign the bot to the least-loaded active login in a pool by passing email_group. This spreads load across all logins sharing that group and is the right default for unattended recording at scale.

curl -X POST https://api.meetingbaas.com/v2/bots \
  -H "x-meeting-baas-api-key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "bot_name": "Recording Bot",
    "meeting_url": "https://meet.google.com/abc-defg-hij",
    "meet_config": {
      "email_group": "bots@bots.acme.com",
      "fallback": "fail"
    }
  }'

To round-robin across all of your team's active logins without filtering by group, pass an empty string:

{ "meet_config": { "email_group": "" } }

Pin a specific login

Use credential_id to force the bot to use one particular login.

{
  "bot_name": "Recording Bot",
  "meeting_url": "https://meet.google.com/abc-defg-hij",
  "meet_config": {
    "credential_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
  }
}

Fallback behavior

fallback controls what happens when no login slot is available (the whole pool is saturated, or no matching active login exists):

{ "meet_config": { "email_group": "bots@bots.acme.com", "fallback": "anonymous" } }

Landing in the verified queue

Signing in is only half the story for restricted meetings. To bypass the waiting room, the bot's identity must be recognized as invited:

1. Put the login's email_group (the Google Group) on the meeting's calendar invite.
2. Dispatch the bot with that same email_group.

The assigned bot is then a member of an invited group and lands in Meet's verified queue instead of the waiting room. This is the recommended pattern for fully unattended recording.

Concurrency and capacity

Each login supports up to 20 concurrent SSO sessions. The dispatcher:

1. Filters to active logins matching your selector.
2. Picks the one with the lowest active_session_count.
3. Skips any login already at capacity.

If every candidate is saturated, the request fails with MEET_LOGIN_UNAVAILABLE (or falls back to anonymous). To raise the ceiling, add more logins to the pool — capacity scales linearly with the number of active logins.

Monitoring pool utilization

Configure a utilization alert first (recommended)

Don't wait until bots start failing. Set up a Meet Login Utilization threshold alert so you're notified automatically as your pool fills up — for example, alert when utilization reaches 70%, giving you time to add logins before you hit the ceiling. Pair it with a Meet Login Unavailable operational alert so you also hear about it the moment a bot actually fails to get an authenticated slot (MEET_LOGIN_UNAVAILABLE).

Both are configured from the Alerts section of your dashboard. See Alerts for setup.

Check utilization on demand

For an ad-hoc or programmatic view, call GET /v2/meet-logins/utilization to see live concurrency across your pool. It's cheap to poll and returns uncached, live counters.

curl https://api.meetingbaas.com/v2/meet-logins/utilization \
  -H "x-meeting-baas-api-key: $API_KEY"

{
  "success": true,
  "data": {
    "logins_total": 5,
    "logins_active": 5,
    "logins_invalid": 0,
    "concurrent_sessions": 42,
    "concurrent_capacity": 100,
    "utilization_pct": 42,
    "by_email_group": [
      { "email_group": "bots@bots.acme.com", "logins": 5, "concurrent": 42, "capacity": 100 }
    ]
  }
}

Troubleshooting

See Error Codes for the full list. These appear in the bot's bot.failed webhook and in the bot details error_code field.

Related resources

• Setup — one-time workspace and login configuration
• Create a bot — full bot creation reference
• Meet Logins utilization — pool metrics endpoint