Green rooms and guest waiting options
Room-based green-room workflows, app.invite.cam lobbies, and supporting guest waiting controls.
A green room is a place for guests to wait before they enter the live room.
That matters because a guest usually needs to feel they are in the right place. If they only see a blocked join, a browser error, or a confusing blank page, they may refresh, leave, or message the host at the worst time.
For VDO.Ninja, the main room-based green-room workflow is a transfer room. For a larger hosted lobby, app.invite.cam can sit in front of VDO.Ninja. Other controls, such as &requireapproval, &hold, and &roomcap, can stop interruptions, but they are not the same as having a lobby or separate waiting room.
&scene is not a green room. Scenes control what appears in OBS or a scene view. They do not stop a guest from entering the room.
The main options
A real VDO.Ninja lobby room before the live room
Guest joins a lobby room, then the director moves them to another room
A larger lobby with waiting lists, signed-in ownership, and grant/revoke access
Guest waits in an invite/lobby flow before being sent to VDO.Ninja
A VDO.Ninja queue workflow without a separate room
&queue and queue variants
Guest waits until the director activates them
Option 1: VDO.Ninja transfer rooms
Transfer rooms are the current VDO.Ninja way to make a room-based green room.
The simple idea:
Guests join a lobby room.
The live show or interview happens in another room.
The director checks the lobby.
The director transfers the guest into the live room when ready.
Example guest link:
Example lobby director link:
Example live-room director link:
The &rooms=LiveRoom part adds a quick transfer destination to the lobby director page. The director can pick LiveRoom, then transfer the waiting guest there.
Why this feels like a green room
The guest is in a real room first. They are not simply blocked from joining. The host can keep the live room separate from the waiting area, so the next guest does not walk into the current conversation.
This also gives the host a clear mental model:
LobbyRoomis where guests arrive.LiveRoomis where the active conversation happens.Transfer is the moment the guest moves from waiting to live.
Transfer-room details that matter
Only the main director can transfer guests. Room director ownership is first come, first served, so keep the director tab open for any room you need to control.
When a guest is transferred, the destination room's director becomes the owner of that guest.
Transferred guests do not see the destination room name during a normal transfer. That keeps private rooms private.
If a transferred guest refreshes or disconnects, they return to the original landing room. This is intentional privacy behavior. If the guest must stay in the destination room after refresh, the director can use Change URL instead of normal transfer, but then the guest can see the new room and password.
Transfers require matching passwords for both rooms.
If the destination room has &requireapproval, the transferred guest waits for approval in that destination room. If the destination room has &roomcap and is full, the transfer is rejected.
Option 2: app.invite.cam
app.invite.cam is a lobby and invite workflow that can sit in front of VDO.Ninja.
The simple idea:
The host signs in.
The host shares an
app.invite.camroom or lobby link.Guests wait in that lobby flow.
The host grants or revokes access.
Approved guests are sent to the intended VDO.Ninja room or invite flow.
This is not just a VDO.Ninja URL parameter. It is a separate lobby layer before the final VDO.Ninja room.
app.invite.cam is built for cases like:
public lobby links
larger events
many people requesting access
signed-in room ownership
owner-managed waiting lists
helper or access-management workflows
keeping the public invite separate from the final VDO.Ninja room link
This can be easier for guests to understand because they are in a visible lobby flow rather than staring at a plain approval gate.
Do not confuse app.invite.cam with plain invite.cam. Plain invite.cam is for hiding, encoding, shortening, or managing links. app.invite.cam is the larger lobby and access flow.
Supporting transfer-room controls
These are still part of the room-based workflow, but they are helpers rather than the green room by themselves.
&rooms
&rooms&rooms adds preset transfer destinations to the director control bar.
Pressing a room name arms the transfer buttons beneath the guests, so the director can move people faster.
&rooms only adds shortcuts. The destination room's own rules still apply.
&queuetransfer
&queuetransfer&queuetransfer, also called &qt, changes what happens after transfer.
Guest link:
With this on the guest link, a transferred guest lands in the destination room's queue flow instead of going live immediately. The destination director can activate them when ready.
This is useful when one person manages the public lobby, but another director controls the final room.
&broadcasttransfer
&broadcasttransfer&broadcasttransfer, also called &bct, changes the default transfer behavior so transferred guests enter in broadcast mode.
This mostly matters when using &rooms, because &rooms acts more like a quick-transfer button and does not show the full transfer menu each time.
Queue and hold options
These can be useful, but they are queue or activation workflows. They are not the same as a separate waiting room unless they are combined with a room-transfer setup.
&queue on both director and guest links
&queue on both director and guest links&queue on both sides creates a screening-room style workflow.
Director link:
Guest link:
Guests wait in a queue. The director pulls them in as needed and can transfer them to another room.
&queue only on the guest link
&queue only on the guest linkGuest link:
The guest is held until the director presses Activate Guest. This is a simple activation flow, not a separate room.
&hold, &holdwithvideo, and &screen
&hold, &holdwithvideo, and &screenThese are guest invite modes:
For these modes, transferring the guest to another room also counts as activation.
These can help stop the next guest from interrupting the current room, but they are not a room-based green room by themselves.
Approval and access controls
These are useful controls for stopping unwanted joins or managing room access. They are lower-level access tools, not green rooms.
&requireapproval and &approvepopup
&requireapproval and &approvepopup&requireapproval makes the active director approve or deny room joins.
Director link:
Guest link:
&approvepopup shows a popup for pending joins. It does not enable sounds or system notifications. Add &beep or ¬ify only when those alerts are wanted.
This can stop someone from entering too early, but it is still an approval gate. It is not a separate room where guests wait.
&roomcap
&roomcap&roomcap=NUMBER limits how many guests can be admitted to a claimed room.
This can prevent extra people from joining a room that is already full. It does not provide a guest lobby.
&roomkey
&roomkey&roomkey=KEY lets selected guests bypass approval or a custom room cap.
Treat a room key like a password.
Passwords and signed-in access
&password can protect a room or source link.
&auth, &requireauth, SSO, or another identity gateway can check who someone is before they reach the VDO.Ninja room flow.
These are access layers. They can sit before or around a green-room workflow, but they do not replace the room/lobby experience.
Related
How to transfer guests to other roomsapp.invite.cam&rooms&queuetransfer&queueHow to selectively allow accessLast updated
Was this helpful?