Google Meet Lobby & Admission Troubleshooting
Google Meet Lobby & Admission Troubleshooting
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
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 and add its exact Google account email address to the calendar invite.
Can a MeetStream bot skip the Google Meet waiting room?
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:
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.
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:
- Confirm that the organizer or a co-host is already in the meeting.
- Ask that person to open the People panel and look for the join request.
- Check Host controls → Meeting access to make sure external participants are allowed to ask to join.
- 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.
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.
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, invite its email address, and keep the Workspace policy in place.
How do I confirm that the waiting room—not MeetStream—is the problem?
Run this quick isolation test:
- Open meet.new while signed in. Because you created this meeting, you are its host.
- Send a MeetStream bot to the new meeting.
- Confirm that you can see and admit the bot.
- 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.
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:
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
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:
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
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
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.
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.
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.
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 beforewaiting_room_timeoutelapsed.
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.
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.
Signed-in bot questions
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 before setting google_meet.login_required to true.
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.
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.
How many Google logins should I configure?
Plan around MeetStream’s documented rule of thumb:
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.
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.
Recommended setup for reliable admission
For production workflows where a host may not be available to approve a guest:
- Complete the Google Signed-In Bots setup.
- Add the selected bot account’s email to the Google Calendar invite.
- Create the bot with
google_meet.login_required: true. - Monitor the complete lifecycle from
bot.joiningthrough the terminal bot event and post-callbot.done; handlebot.denied,bot.notallowed, andbot.failedas admission or lifecycle failures. - Set
automatic_leave.waiting_room_timeoutto match how early the bot is scheduled to arrive.
For API setup details, see Create your First Bot and Webhooks and Events.
