What happens when a guest joins your show by link
The link carries a random single-purpose token. Your guest opens it in an ordinary browser, lands in a green room off air, and you bring them on when ready. No account is created and nothing is installed.
Getting another person onto a live show used to be the hardest part of producing one. The friction was never the video; it was the twenty minutes before air spent talking somebody through installing software they will use once. A link removes that, and it is worth understanding what the link actually is.
The link is a token, not an account
What you send is a long random value that identifies one invitation. It is not tied to an identity your guest has to create, and they are not enrolled in anything by using it. They click, their browser asks for camera and microphone permission the way any video call does, and they are in.
Because the token is the credential, it can carry limits. You can cap how many times it may be used and set a date after which it stops working, and you can revoke it outright at any point. Both limits are optional, which is worth knowing in the other direction: a link sent with neither set keeps working indefinitely.
They arrive off-air
A guest who joins does not appear on the programme. They land in a green room, where you can see and hear them and your audience cannot. That is where the useful part of the workflow happens: check their audio, ask them to close the window behind them, tell them how long they have, and take them to air when you are ready.
For anything with a schedule this is the difference between a professional show and a chaotic one. The previous segment can overrun by six minutes while the next guest is being briefed, and the audience sees none of it.
What the link cannot fix
Removing the install does not remove the physics. A guest on a congested connection will look like a guest on a congested connection, and a guest lit from behind by a window will be a silhouette. The browser is doing the best it can with what the room gives it.
The answer is the boring one: a five-minute check the day before. It catches the backlight, the ceiling fan, the laptop microphone and the roommate, none of which production can fix once the guest is live. Nobody tests, precisely because joining is so easy that it does not feel like it needs testing.
Hygiene worth adopting early
Mint a fresh link per episode or per session rather than reusing one, and set an expiry when you create it rather than planning to revoke it later. Revoking later requires remembering, and nobody does.
Every invitation created and every guest join is written to an access record. That is the thing that answers the question you get asked months afterwards about who was able to see a particular session, and it is considerably more useful than anybody expects until the first time they need it.
Building against the API rather than running a show? Green room and private intercom (developer docs) covers the same ground in implementation detail.
Put it to work on a real show
Guest links are the whole workflow for a show that books somebody new every week.
StreamYard made browser guest links mainstream. Worth reading if you want them on top of a real scene canvas rather than a template grid.
Where per-session expiry stops being hygiene and starts being how you manage nine speakers across four time zones.
Related guides
Use RTMPS on a stable wired line: simple and universally supported. Use SRT when the path is lossy or cellular, because it recovers lost packets. Use WHIP when a browser should publish with nothing installed.
Take audio from the sound desk, not the camera. That single change improves a worship stream more than any camera upgrade. Then add a locked wide shot, and a second camera on whoever is speaking, in that order.