Google Meet Lobby & Admission Troubleshooting

Understand who can see waiting bots and resolve Google Meet admission issues
View as Markdown

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

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.

Joining and waiting rooms

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 and add its exact Google account email address to the calendar invite.

Yes, when you use a Google signed-in bot and add the bot account’s email address to the Google Calendar event.

Configure the bot to sign in when you create it:

1{
2 "meeting_link": "https://meet.google.com/abc-defg-hij",
3 "bot_name": "Meeting Assistant",
4 "google_meet": {
5 "login_required": true,
6 "google_login_domain": "acme.com",
7 "sign_in_email": "bot.user@acme.com",
8 "strict_email": true
9 }
10}

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.

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 for the current Google Meet controls.

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.

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, invite its email address, and keep the Workspace policy in place.

Run this quick isolation test:

  1. Open 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.

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:

1{
2 "organizer": {
3 "email": "scheduler@acme.com",
4 "displayName": "Scheduling Service",
5 "self": false
6 }
7}

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.

MeetStream status and webhook questions

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

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

EventMeaning
bot.scheduledScheduled bot creation was accepted. The bot will join at its scheduled time.
bot.joiningMeetStream dispatched the bot. For a scheduled bot, this fires when its scheduled execution begins.
bot.in_waiting_roomThe bot clicked Join and is waiting for Google Meet admission.
bot.inmeetingThe bot successfully entered the meeting.
bot.recordingThe bot started capturing meeting media.
bot.leavingThe bot is exiting the meeting. This is a transitional event before a terminal event.
bot.stoppedThe bot exited cleanly because the meeting ended, the API stopped it, the host ended the call, or another graceful leave condition occurred.
bot.kickedA host or participant forcibly removed the bot. The associated bot_status is Stopped.
bot.deniedA host explicitly rejected the bot’s join request. The associated bot_status is Denied.
bot.notallowedThe bot was not admitted before waiting_room_timeout elapsed. The associated bot_status is NotAllowed.
bot.failedAn unexpected error occurred during the bot lifecycle. The associated bot_status is Error.
bot.doneThe 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

EventMeaning
audio.processedAudio processing completed.
transcription.processedTranscription processing completed.
video.processedVideo processing completed.
bot.doneAll requested post-call processing has finished.
data_deletionStored 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.

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.

Branch on bot_event, not only status_code. See Webhooks and Events for complete payloads and status mappings.

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

1{
2 "meeting_link": "https://meet.google.com/abc-defg-hij",
3 "bot_name": "Meeting Assistant",
4 "automatic_leave": {
5 "waiting_room_timeout": 300
6 }
7}

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.

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.

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.

Signed-in bot questions

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 before setting google_meet.login_required to true.

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.

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.

Plan around MeetStream’s documented rule of thumb:

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.

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.

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

  1. Complete the Google Signed-In Bots setup.
  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 and Webhooks and Events.