Skip to content
Roles and permissions

Guides

Roles and permissions

You decide what each person may do when you mint their token. The media server enforces it — not the page, which anyone can edit.

Who decides

Your app already knows who a user is and what they may do — whether they’re the teacher, the patient, the seller. InlineMeet doesn’t second-guess that: your server says it when minting a token, and that token is all the media server trusts.

  • Enforced by the media server: the role, and which sources — microphone, camera, screen — a person may publish. A modified browser can’t get around them.
  • Shown by the UI: the permissions your token route returns, which only decide which buttons appear. Keep them in step with what you granted.

Build a token

Change the options and watch the request, the response, and the controls that person would get.

Token builderInteractive
publish
Also try
  • Can mute and unmute freely.
  • Can turn their camera on.
  • No screen-share button.
  • No record button.
  • No moderator controls; sees who the moderators are.
curl -X POST https://api.inlinemeet.com/v1/rooms/algebra-101/tokens \
  -H "Authorization: Bearer $INLINEMEET_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "identity": "user-42:tab-1",
    "name": "Aisha Khan",
    "publish": {
      "microphone": true,
      "camera": true,
      "screenShare": false
    }
  }'
Response
{
  "token": "eyJhbGciOiJIUzI1NiJ9.eyJ2aWRlbyI6eyJyb29tSm9pbiI6dHJ1ZX19…",
  "url": "wss://livekit.inlinemeet.com",
  "identity": "user-42:tab-1",
  "role": "participant",
  "participantsCanUnmute": true
}

Roles

moderatorparticipant (default)
WhoTeachers, hosts, admins, agentsEveryone else
Microphone, camera, screenAlways — publish is ignoredWhatever publish grants
When microphones are lockedCan still speakMuted, until a moderator lets them speak
Moderation controlsYes: lock, mute, allow to speak, pinned noteNo
Badge in the callA shield, everywhere they appear—

Who counts as a moderator reaches every browser through room data only the server can write, so nobody can promote themselves by editing what their own browser says.

What people may publish

publish takes three switches: microphone, camera and screenShare. Leave it out, or set everything false, and the person is listen-only: they see and hear the call, and can chat, but the media server refuses anything they try to publish. Everyone can always watch, listen and use the chat.

A student: can talk, can be seen, can’t share their screen
{
  "identity": "student-981:7f3c",
  "name": "Aisha Khan",
  "publish": { "microphone": true, "camera": true, "screenShare": false }
}

The room’s microphone lock sits on top of this: while a room has participantsCanUnmute off, participants are muted even if their token grants a microphone — until a moderator lets one of them speak.

Token options

Everything POST /v1/rooms/:code/tokens accepts:

FieldDescription
identityrequiredstring, 1–128 charactersWho this connection is, in your terms. Unique per tab — a second connection with the same identity replaces the first.
namestring, up to 120Display name in the call.
role'moderator' | 'participant'Defaults to participant.
publish{ microphone?, camera?, screenShare? }What a participant may publish. Omit for listen-only. Ignored for moderators.
metadataobject | string, under 4 KBAnything you want other participants’ UIs to have — an avatar URL, a seat number. Display only: never use it to decide access.
ttlSecondsnumberHow long the token can be used to join. Default 21600 (6 hours), maximum 86400 (24 hours). Mint a fresh one per join.

Common setups

A classroom

The teacher is a moderator; students get a microphone and camera but no screen share. Lock the microphones when the lesson starts and let students speak as their hands go up.

A talk with an audience

Speakers are moderators; everyone else is listen-only (no publish). They follow along, raise hands and chat; a moderator can let one of them speak — handy for Q&A.

A one-to-one appointment

Both people publish everything. Make the professional — the tutor, the clinician — the moderator, and mint tokens with a short ttlSeconds, so a token that leaks is useless soon after the appointment.

Support with screen sharing

The customer gets microphone, camera and screen share, so they can show the problem; the agent is the moderator. Record the session from the agent’s side for quality review.