> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.meetstream.ai/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.meetstream.ai/_mcp/server.

# Google Meet Lobby & Admission Troubleshooting

Use this guide to troubleshoot Google Meet join behavior and choose between an anonymous or signed-in MeetStream bot.

<Callout intent="info">
Google Meet controls who can enter a meeting. MeetStream can request access and report what happens, but it cannot override the organizer's meeting access or Google Workspace policies.
</Callout>

## Joining and waiting rooms

<AccordionGroup>
  <Accordion title="Who can see a MeetStream bot waiting in the Google Meet lobby?">

    When Google Meet Host management is enabled, only the meeting host and designated co-hosts can see and admit participants waiting in the lobby.

    Depending on Google Meet Host management settings like in the above configuration, only the meeting host and designated co-hosts—and in some configurations trusted users within the host's Workspace—can admit waiting participants. Regular attendees often cannot see the admission request. From their perspective, it can look like the bot never arrived, while MeetStream continues to report `bot.in_waiting_room`.

    Make sure the organizer or a designated co-host is present to admit the bot. For meetings that must work without manual admission, use a [Google signed-in bot](/guides/app-integrations/google-signed-in-bots) and add its exact Google account email address to the calendar invite.

  </Accordion>

  <Accordion title="Can a MeetStream bot skip the Google Meet waiting room?">

    Yes, when you use a [Google signed-in bot](/guides/app-integrations/google-signed-in-bots) and add the bot account's email address to the Google Calendar event.

    Configure the bot to sign in when you create it:

    ```json
    {
      "meeting_link": "https://meet.google.com/abc-defg-hij",
      "bot_name": "Meeting Assistant",
      "google_meet": {
        "login_required": true,
        "google_login_domain": "acme.com",
        "sign_in_email": "bot.user@acme.com",
        "strict_email": true
      }
    }
    ```

    The domain and email must already be configured in your MeetStream Google Signed-In Bots integration. If you do not configure Google Meet sign-in, the bot joins as an anonymous participant and may need to be admitted.

  </Accordion>

  <Accordion title="MeetStream reports bot.in_waiting_room, but nobody sees a request to admit the bot. Why?">

    The bot has reached Google Meet and is waiting. The most common cause is that the person looking for the request is neither the meeting host nor a designated co-host.

    When Google Meet Host management is enabled, admission controls belong to the hosts. A regular attendee may be able to join the call but still be unable to see or approve an external participant's request.

    Check the following:

    1. Confirm that the organizer or a co-host is already in the meeting.
    2. Ask that person to open the **People** panel and look for the join request.
    3. Check **Host controls → Meeting access** to make sure external participants are allowed to ask to join.
    4. For repeat or unattended workflows, use a signed-in bot and add its email to the calendar invite.

    See Google's [host controls documentation](https://support.google.com/meet/answer/16229038?hl=en) for the current Google Meet controls.

  </Accordion>

  <Accordion title="Why can invited attendees join while the bot remains in the waiting room?">

    Google Meet may treat people on the calendar invite or in the organizer's Workspace as trusted participants. An anonymous MeetStream bot is an external participant, so Google can require a host or co-host to admit it even when other attendees enter directly.

    To give the bot the same invited-participant path, configure a signed-in bot and add its exact sign-in email to the event.

  </Accordion>

  <Accordion title="What if I am the host and still cannot see the bot's join request?">

    Open **Host controls → Meeting access** and verify that the setting allowing people with the meeting link to ask to join is enabled. If external or anonymous participants are not allowed to request access, Google can reject the bot before an admission prompt appears.

    If your organization intentionally blocks anonymous participants, use a [Google signed-in bot](/guides/app-integrations/google-signed-in-bots), invite its email address, and keep the Workspace policy in place.

  </Accordion>

  <Accordion title="How do I confirm that the waiting room—not MeetStream—is the problem?">

    Run this quick isolation test:

    1. Open [meet.new](https://meet.new) while signed in. Because you created this meeting, you are its host.
    2. Send a MeetStream bot to the new meeting.
    3. Confirm that you can see and admit the bot.
    4. Return to the affected meeting and check whether you have **Host controls** there.

    If the bot is visible in your test meeting but not the affected meeting, compare the affected event's organizer, co-hosts, invited attendees, and Meeting access settings.

  </Accordion>

  <Accordion title="How do I find the actual meeting organizer?">

    Open the event in Google Calendar and inspect its organizer. The organizer can be different from the person leading the call—for example, an assistant, shared calendar, service account, or scheduling application may have created the event.

    If you read events through the Google Calendar API, inspect the event's `organizer` field:

    ```json
    {
      "organizer": {
        "email": "scheduler@acme.com",
        "displayName": "Scheduling Service",
        "self": false
      }
    }
    ```

    If the organizer will not attend, assign an attending participant as a co-host in Google Calendar, create the event from an attending host's calendar, or use an invited signed-in bot.

  </Accordion>
</AccordionGroup>

## MeetStream status and webhook questions

<AccordionGroup>
  <Accordion title="Which webhook events can a MeetStream bot emit?">

    MeetStream reports the bot lifecycle through `bot_event`. A scheduled Google Meet bot that joins and records successfully normally progresses through:

    ```text
    bot.scheduled
    bot.joining
    bot.in_waiting_room
    bot.inmeeting
    bot.recording
    bot.leaving
    bot.stopped
    audio.processed / transcription.processed / video.processed
    bot.done
    ```

    `bot.scheduled` applies only when the bot has a scheduled join time. `bot.in_waiting_room` is emitted for every bot after it clicks Join and may be very brief when Google admits it immediately.

    ### Bot lifecycle events

    | Event | Meaning |
    | --- | --- |
    | `bot.scheduled` | Scheduled bot creation was accepted. The bot will join at its scheduled time. |
    | `bot.joining` | MeetStream dispatched the bot. For a scheduled bot, this fires when its scheduled execution begins. |
    | `bot.in_waiting_room` | The bot clicked Join and is waiting for Google Meet admission. |
    | `bot.inmeeting` | The bot successfully entered the meeting. |
    | `bot.recording` | The bot started capturing meeting media. |
    | `bot.leaving` | The bot is exiting the meeting. This is a transitional event before a terminal event. |
    | `bot.stopped` | The bot exited cleanly because the meeting ended, the API stopped it, the host ended the call, or another graceful leave condition occurred. |
    | `bot.kicked` | A host or participant forcibly removed the bot. The associated `bot_status` is `Stopped`. |
    | `bot.denied` | A host explicitly rejected the bot's join request. The associated `bot_status` is `Denied`. |
    | `bot.notallowed` | The bot was not admitted before `waiting_room_timeout` elapsed. The associated `bot_status` is `NotAllowed`. |
    | `bot.failed` | An unexpected error occurred during the bot lifecycle. The associated `bot_status` is `Error`. |
    | `bot.done` | The post-call pipeline finished. Check the artifact events for the result of each requested output. |

    The clean terminal events `bot.stopped` and `bot.kicked` use `status_code: 200`. Failure terminal events such as `bot.denied`, `bot.notallowed`, and `bot.failed` use `status_code: 500`.

    ### Post-call processing events

    | Event | Meaning |
    | --- | --- |
    | `audio.processed` | Audio processing completed. |
    | `transcription.processed` | Transcription processing completed. |
    | `video.processed` | Video processing completed. |
    | `bot.done` | All requested post-call processing has finished. |
    | `data_deletion` | Stored bot media was deleted manually or after its retention period. |

    Artifact events are asynchronous and their order can vary. `bot.done` means the pipeline is finished; inspect the artifact-specific events to determine the result of each output.

    <Callout intent="warning">
    `bot.recording_permission_allowed` and `bot.recording_permission_denied` are Zoom-only events. Google Meet bots move directly from `bot.inmeeting` to `bot.recording` when capture starts.
    </Callout>

    Branch on `bot_event`, not only `status_code`. See [Webhooks and Events](/guides/webhooks/webhooks-and-events) for complete payloads and status mappings.

  </Accordion>

  <Accordion title="How long will a bot wait to be admitted?">

    Set `automatic_leave.waiting_room_timeout` when you create the bot. The value is in seconds. For Google Meet, the documented range is `60`–`600`, and the default is `600`.

    ```json
    {
      "meeting_link": "https://meet.google.com/abc-defg-hij",
      "bot_name": "Meeting Assistant",
      "automatic_leave": {
        "waiting_room_timeout": 300
      }
    }
    ```

    If the bot is not admitted before the timeout, MeetStream reports `bot.notallowed`. Use a shorter value for ad-hoc calls and a longer value when a scheduled host may arrive late.

  </Accordion>

  <Accordion title="Why did the bot report bot.denied or bot.notallowed?">

    These events describe different outcomes:

    - `bot.denied`: someone explicitly rejected the bot's request.
    - `bot.notallowed`: the bot waited but was not admitted before `waiting_room_timeout` elapsed.

    Check that the organizer or a co-host was present, external participants were allowed to ask to join, and the host knew the bot's display name. A signed-in, invited bot is the most reliable option for recurring meetings with restrictive access settings.

  </Accordion>

  <Accordion title="What happens when the host selects “End call for everyone”?">

    Google Meet removes all participants, including the MeetStream bot. MeetStream then follows its normal leave and post-call processing flow. Monitor the lifecycle webhook events rather than assuming that every departure was initiated through the MeetStream remove-bot endpoint.

  </Accordion>
</AccordionGroup>

## Signed-in bot questions

<AccordionGroup>
  <Accordion title="When should I use a signed-in Google Meet bot?">

    Use a signed-in bot when:

    - The meeting or Workspace policy blocks anonymous participants.
    - The bot must reliably join meetings where its account is invited.
    - You want Google Meet to show the Google account's verified display name and profile image.
    - Meetings may begin without a host available to admit an anonymous bot.

    Signed-in bots require a one-time Google Workspace and MeetStream integration setup. Follow [Google Signed-In Bots](/guides/app-integrations/google-signed-in-bots) before setting `google_meet.login_required` to `true`.

  </Accordion>

  <Accordion title="Can I use anonymous bots for some meetings and signed-in bots for others?">

    Yes. MeetStream bots join Google Meet anonymously by default. Include a `google_meet` configuration with `login_required: true` only for meetings that should use a configured Google identity.

    If you specify `sign_in_email`, make sure that exact account exists in your MeetStream integration and is added to the meeting invite.

  </Accordion>

  <Accordion title="What controls the signed-in bot's name and profile image?">

    Google Meet uses the display name and profile image of the Google account selected for the bot. The request's `bot_name` does not replace that signed-in Google identity.

    Update the Google account if you need a different participant name or avatar. For an anonymous bot, Google Meet typically renders a generic participant identity based on the name supplied at join time.

  </Accordion>

  <Accordion title="How many Google logins should I configure?">

    Plan around MeetStream's documented rule of thumb:

    ```text
    required logins = peak concurrent Google Meet sessions / 20
    ```

    Round up and leave capacity for traffic spikes. For example, a peak of 100 simultaneous Google Meet bots calls for at least 5 configured logins. MeetStream distributes signed-in bots across the available logins.

  </Accordion>

  <Accordion title="Can MeetStream hide the bot tile for every participant?">

    No. Hiding or pinning a participant tile is controlled separately by each person's Google Meet interface. Neither MeetStream nor the meeting host can force every attendee's layout to hide the bot.

  </Accordion>
</AccordionGroup>

## Recommended setup for reliable admission

For production workflows where a host may not be available to approve a guest:

1. Complete the [Google Signed-In Bots setup](/guides/app-integrations/google-signed-in-bots).
2. Add the selected bot account's email to the Google Calendar invite.
3. Create the bot with `google_meet.login_required: true`.
4. Monitor the complete lifecycle from `bot.joining` through the terminal bot event and post-call `bot.done`; handle `bot.denied`, `bot.notallowed`, and `bot.failed` as admission or lifecycle failures.
5. Set `automatic_leave.waiting_room_timeout` to match how early the bot is scheduled to arrive.

For API setup details, see [Create your First Bot](/guides/get-started/create-your-first-bot) and [Webhooks and Events](/guides/webhooks/webhooks-and-events).