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
permissionsyour 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.
- 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
}
}'{
"token": "eyJhbGciOiJIUzI1NiJ9.eyJ2aWRlbyI6eyJyb29tSm9pbiI6dHJ1ZX19…",
"url": "wss://livekit.inlinemeet.com",
"identity": "user-42:tab-1",
"role": "participant",
"participantsCanUnmute": true
}Roles
| moderator | participant (default) | |
|---|---|---|
| Who | Teachers, hosts, admins, agents | Everyone else |
| Microphone, camera, screen | Always — publish is ignored | Whatever publish grants |
| When microphones are locked | Can still speak | Muted, until a moderator lets them speak |
| Moderation controls | Yes: lock, mute, allow to speak, pinned note | No |
| Badge in the call | A 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.
{
"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:
| Field | Description |
|---|---|
identityrequiredstring, 1–128 characters | Who this connection is, in your terms. Unique per tab — a second connection with the same identity replaces the first. |
namestring, up to 120 | Display 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 KB | Anything you want other participants’ UIs to have — an avatar URL, a seat number. Display only: never use it to decide access. |
ttlSecondsnumber | How 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.