Moderation

#In the call

Moderators get the controls in the People panel. In this demo the room starts locked — Amara raises her hand after a few seconds; press Allow to speak and she’ll unmute.

Participants see a lock on their microphone while it’s locked; clicking it tells them to raise their hand. Being muted, locked out or let back in each shows them a short notice, so a microphone never silently stops working.

Right-click anyone in the People panel — or use the ⋯ beside their name on a phone — for everything else. A moderator can lower their hand, let them share their screen, run polls, manage Q&A or draw on the locked whiteboard, and remove them from the call. Anyone else can mute a participant or lower their hand from the same menu: that person’s own browser does it and tells them who did, so it’s a friendly nudge, not a lock — and nobody but a moderator can do it to a moderator.

#Lock microphones

Set participantsCanUnmute to false and every regular participant is muted and loses the right to unmute, at once; people who join later arrive locked. Setting it back to true gives the microphone back to those whose token granted one — a listen-only participant stays listen-only. Moderators are never locked.

curl -X PATCH https://api.inlinemeet.com/v1/rooms/algebra-101 \
  -H "Authorization: Bearer $INLINEMEET_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"participantsCanUnmute": false}'

The lock is a property of the room, so it also holds for anyone who joins while it’s on. inlinemeet(…) is the small helper from API keys.

#Mute people

With an identity, mutes that one person; without, mutes every regular participant (moderators are left alone). Unless the room is locked, they can unmute again — muting is a nudge, the lock is the rule.

curl -X POST https://api.inlinemeet.com/v1/rooms/algebra-101/mute \
  -H "Authorization: Bearer $INLINEMEET_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"identity": "student-981:7f3c"}'
# {"muted": ["student-981:7f3c"]} — the identities whose microphone was live

#Let one person speak

While the room is locked, {"allowed": true} lets one participant unmute — the answer to a raised hand. {"allowed": false} takes it back and mutes them. It lasts for their current connection: someone who rejoins is back under the room’s rule.

curl -X POST https://api.inlinemeet.com/v1/rooms/algebra-101/participants/student-981%3A7f3c/microphone \
  -H "Authorization: Bearer $INLINEMEET_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"allowed": true}'

#Let one person present

Give one participant more than their token granted: screenShare, polls (ask them, like a moderator), qna (answer, file and dismiss questions) and whiteboard (draw while it’s locked). Send true to give, false to take back; anything left out stays as it is. Like letting someone speak, it lasts for their current connection and carries into breakout rooms. Taking screen sharing back stops a share in progress; polls, Q&A and the whiteboard can only be given where the room’s plan has them.

curl -X POST https://api.inlinemeet.com/v1/rooms/algebra-101/participants/student-981%3A7f3c/permissions \
  -H "Authorization: Bearer $INLINEMEET_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"screenShare": true, "polls": true}'
# {"identity": "student-981:7f3c", "permissions": {"screenShare": true, "polls": true, "qna": false, "whiteboard": false}}

#Remove someone

Disconnects one participant, wherever they are — the main room or a breakout. The call UI tells them they were removed and doesn’t offer to rejoin. The token they hold can no longer move them between rooms, or let them back in on a waiting-room ticket; whether they may come back at all is your decision, since you mint the tokens. The media server can’t revoke a token that’s already been issued, so keep lifetimes short where removal matters. Moderators can’t be removed.

#Waiting room

With waitingRoom: true, a participant’s token request answers 202 with a ticket instead of a token. They wait outside the call — seeing and hearing nothing — while their browser polls with the ticket. Moderators are told as each person arrives, and let them in or turn them away from the call UI, or with admit and deny. Once let in, the next poll returns their token. Someone let in isn’t held again if they rejoin under the same identity, and turning the waiting room off lets in everyone waiting. Moderators, and tokens requested with bypass: true, never wait.

curl -X PATCH https://api.inlinemeet.com/v1/rooms/algebra-101 \
  -H "Authorization: Bearer $INLINEMEET_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "waitingRoom": true, "password": "maths42" }'

#Password

Set password (4–64 characters) and participants must give it to join: relay what they typed as password in the token request. Without it the request answers 401 password_required; with a wrong one, 403 wrong_password, and wrong guesses are capped per room. It is stored only as a hash — InlineMeet can’t show it back — and null removes it. The call UI asks for it on the pre-join screen, and moderators can set, change or remove it from the call’s Settings tab. Changing it doesn’t affect anyone already in the call.

#Record automatically

With autoRecord: true, recording starts when a moderator joins — once per session of the call, so a moderator who stops it, or whose connection drops and comes back, isn’t recorded again until the room next starts afresh. Switched on while a moderator is already in the call, it starts at once. The recording is an ordinary one (with autoStarted: true), stopped and delivered like any other. Rooms that can’t be recorded refuse the setting.

recordingActivity decides what the recording shows besides the call — chat messages, Q&A, polls, reactions and raised hands, each on its own — drawn over the picture only while it matters. Moderators can change it from the call’s Settings tab too. Recording shows how it looks.

#Lock the whiteboard

With whiteboardLocked: true, only moderators can change the whiteboard. Everyone else can still look, follow a presenter and use the laser pointer. Every browser ignores edits from anyone else while it is locked, and saves from anyone else are refused.

In the call, a moderator can also steer how everyone sees the whiteboard, from its ⋯ menu: Hide participants’ cursors, so only the moderators’ pointers show, and Everyone follows my view — presenting, with participants kept on the moderator’s view until they’re let go: they can’t change board or close the whiteboard, and when they zoom in to look closer, the moderator moving their view brings them back to it. They can still draw and point. Following always shows all of what the moderator sees, on any size of screen.

#Breakout rooms

Split the call into smaller rooms and bring everyone back. Moderation carries across: a locked microphone stays locked in a breakout, mute everyone mutes people in every room, and the participant list shows who is where. In the call UI a moderator opens rooms from the Breakout rooms button, visits any of them, and messages them all at once.

{ "rooms": [{ "name": "Group A" }, { "name": "Group B" }], "auto": true, "durationSec": 900 }

Moves, messages and closing are in the API reference. Breakout rooms are part of paid plans.

#End a call

Ends the call for everyone: they are disconnected — breakout rooms included — and told the call has ended, a recording in progress is stopped and kept, and people in the waiting room are told too. The room stays, so the next token you mint starts a new call in it. In the call UI, a moderator who clicks Leave is asked whether to just leave or end the call for everyone — with end: true in createFetchBackend and a route that forwards here.

Closes the room for good: the call ends as above, then the room is archived. Finished recordings are kept. Creating the room again with POST /v1/rooms reopens it.

#Who may moderate

From the API, your server decides — call these endpoints whenever your own rules say so. From the call UI, the buttons appear for moderators, and your routes forward them; those routes must check the caller is a moderator before forwarding, because only that check enforces it. The catch-all route in the call UI guide does exactly that.