Use Video calls when contributors join through a browser instead of a hardware encoder or desktop publishing app. This module gives you a managed room with enforced participant policy, then provides the join details the browser client needs at the moment a speaker or guest enters.
In production, it solves two problems: room control and join preparation. Room control defines how the session should behave: video or audio-only, participant limit, webinar restrictions, chat, screen sharing, and optional room-level recording. Join preparation resolves the active room name and issues the participant token used by the browser client.
Keep private room lifecycle actions on the server side. Use them to create, start, and stop the room. For browser access, use the public helpers in this order:
findLKRoomNameById resolves your Callaba room id to the active underlying room name and returns room-level flags such as webinar mode, chat, screen sharing, and recording settings.createToken mints the participant token for that room.This separation keeps operators in control of room state while exposing only the minimum required data to clients.
Start with the preset that matches the actual event format. These are practical defaults for common production scenarios.
Use for internal meetings, producer calls, or small panels where everyone can speak and share a screen.
{
"name": "Team standup room",
"user_id": "USER_ID",
"mediaType": "MEDIA_TYPE_VIDEO_AUDIO",
"max_participants": 20,
"allow_webinar_mode": false,
"allow_chat": true,
"allow_share_screen": true,
"record": false,
"record_mode": "ROOM_COMPOSITE_GRID",
"active": true
}
Use when hosts need full participation but the audience should have a more limited experience.
{
"name": "Guest webinar room",
"user_id": "USER_ID",
"mediaType": "MEDIA_TYPE_VIDEO_AUDIO",
"max_participants": 200,
"allow_webinar_mode": true,
"allow_chat": true,
"allow_share_screen": false,
"record": false,
"record_mode": "ROOM_COMPOSITE_GRID",
"active": true
}
Use for voice-only coordination calls, briefings, or low-bandwidth contributor sessions.
{
"name": "Audio briefing room",
"user_id": "USER_ID",
"mediaType": "MEDIA_TYPE_AUDIO_ONLY",
"max_participants": 50,
"allow_webinar_mode": false,
"allow_chat": true,
"allow_share_screen": false,
"record": false,
"record_mode": "ROOM_COMPOSITE_GRID",
"active": true
}
Use when the room is expected to produce a composite recording and speaker layout matters.
{
"name": "Recorded speaker room",
"user_id": "USER_ID",
"mediaType": "MEDIA_TYPE_VIDEO_AUDIO",
"max_participants": 50,
"allow_webinar_mode": true,
"allow_chat": true,
"allow_share_screen": true,
"record": true,
"record_mode": "ROOM_COMPOSITE_SPEAKER",
"active": true
}
Provision the room ahead of time and store the room id in your booking, rundown, or event system. When talent is ready, resolve the room with findLKRoomNameById and issue a token with createToken. This gives operators one stable room to monitor while keeping join access tied to the actual call time.
Enable webinar mode when presenters need full media privileges but guests or viewers should be restricted. Decide early whether chat stays on and whether screen sharing is allowed. Those two settings usually determine whether the room feels like a meeting or a managed event.
If the room will feed a composite output or recording workflow, set recording intent when the room is created and keep participant policy focused on how people should join. Delivery and archive steps can then be handled downstream without changing the browser join flow.
record_mode based on the final viewing experience you need, not just the number of speakers.Create a new managed video call room in Callaba Engine.
This method provisions the room object that the browser join flow depends on. The payload focuses on room policy rather than transport details: media mode, participant capacity, webinar restrictions, chat, screen sharing, recording behavior, and whether the room should be active right after creation.
Examples by preset are especially useful here because most real rooms fall into a few recognizable patterns: standard team rooms, webinar-style rooms, audio-only rooms, and recorded rooms for speaker-focused output.
Workflow-oriented use cases: create a stable browser room for speakers, pre-provision a webinar room before the event starts, or define a recorded room whose layout should later be used for composite output.
Use this when a small or medium team should join with full audio and video, chat, and screen sharing enabled.
curl --request POST \--url http://localhost/api/conferences/create \--header 'x-access-token: <your_api_token>' \--header 'Content-Type: application/json' \--data '{"name": "Team standup room","user_id": "USER_ID","mediaType": "MEDIA_TYPE_VIDEO_AUDIO","max_participants": 20,"allow_webinar_mode": false,"allow_chat": true,"allow_share_screen": true,"record": false,"record_mode": "ROOM_COMPOSITE_GRID","active": true}'
Use this when the room should support guest or view-only behavior and keep speaker privileges more controlled.
curl --request POST \--url http://localhost/api/conferences/create \--header 'x-access-token: <your_api_token>' \--header 'Content-Type: application/json' \--data '{"name": "Guest webinar room","user_id": "USER_ID","mediaType": "MEDIA_TYPE_VIDEO_AUDIO","max_participants": 200,"allow_webinar_mode": true,"allow_chat": true,"allow_share_screen": false,"record": false,"record_mode": "ROOM_COMPOSITE_GRID","active": true}'
Use this when the meeting should behave more like an audio briefing or lightweight discussion space.
curl --request POST \--url http://localhost/api/conferences/create \--header 'x-access-token: <your_api_token>' \--header 'Content-Type: application/json' \--data '{"name": "Audio briefing room","user_id": "USER_ID","mediaType": "MEDIA_TYPE_AUDIO_ONLY","max_participants": 50,"allow_webinar_mode": false,"allow_chat": true,"allow_share_screen": false,"record": false,"record_mode": "ROOM_COMPOSITE_GRID","active": true}'
Use this when the room should later feed a composite output workflow and recording is part of the room policy.
curl --request POST \--url http://localhost/api/conferences/create \--header 'x-access-token: <your_api_token>' \--header 'Content-Type: application/json' \--data '{"name": "Recorded speaker room","user_id": "USER_ID","mediaType": "MEDIA_TYPE_VIDEO_AUDIO","max_participants": 50,"allow_webinar_mode": true,"allow_chat": true,"allow_share_screen": true,"record": true,"record_mode": "ROOM_COMPOSITE_SPEAKER","active": true}'
Dashboard label: Room Name.
Human-readable room name. The dashboard validates this field and shows the same character guidance used elsewhere in the product: A-Z, a-z, 0-9, and -.
Owner id of the room. The dashboard store does not ask for this explicitly because the backend injects the authenticated user id before create and update calls.
Dashboard label: Media type.
Supported room modes are MEDIA_TYPE_VIDEO_AUDIO, MEDIA_TYPE_VIDEO_ONLY, and MEDIA_TYPE_AUDIO_ONLY.
Dashboard label: Max participants.
Maximum number of participants allowed to join the meeting simultaneously.
Controls whether the room should support webinar-style guest behavior in addition to the speaker path.
Controls whether chat should remain available in the browser room experience.
Controls whether speakers should be allowed to share their screen inside the room.
Controls whether the room should be treated as record-enabled.
Composite recording mode for the room. Real product values include ROOM_COMPOSITE_GRID, ROOM_COMPOSITE_AND_CHAT, and ROOM_COMPOSITE_SPEAKER.
Dashboard label: Enabled.
Controls whether the room should be active right after provisioning.
curl --request POST \--url http://localhost/api/conferences/create \--header 'x-access-token: <your_api_token>' \--header 'Content-Type: application/json' \--data '{"name": "Main stage room","user_id": "USER_ID","mediaType": "MEDIA_TYPE_VIDEO_AUDIO","max_participants": 50,"allow_webinar_mode": true,"allow_chat": true,"allow_share_screen": true,"record": false,"record_mode": "ROOM_COMPOSITE_GRID","active": true}'
Mongo-style identifier of the room object.
Convenience alias for _id.
Stored room name and owning user id.
Media mode and participant limit stored on the room object.
Room-level participant experience flags returned with the room object.
Recording intent and composite mode stored for the room.
Room runtime and timestamp fields returned by the backend.
The model exposes success: true as a virtual field in successful responses.
{"_id": "69f013c1aa11bb22cc33dd44","id": "69f013c1aa11bb22cc33dd44","name": "Main stage room","user_id": "69360341db559495f643de6a","mediaType": "MEDIA_TYPE_VIDEO_AUDIO","allow_webinar_mode": true,"allow_chat": true,"allow_share_screen": true,"record": false,"record_mode": "ROOM_COMPOSITE_GRID","max_participants": 50,"sid": "RM_x7h6k4example","active": true,"created": "2026-03-24T16:00:00.000Z","modified": "2026-03-24T16:00:00.000Z","success": true}
Return the total number of video call rooms visible to the authenticated user.
Use this with paginated listings when the dashboard or your own control panel needs the current room count before fetching room objects.
curl --request POST \--url http://localhost/api/conferences/getCount \--header 'x-access-token: <your_api_token>' \--header 'Content-Type: application/json' \--data '{"filter": {"active": true}}'
Total number of video call rooms currently visible to the authenticated user.
{"count": 1}
Return the list of video call rooms for the current user.
This is the normal control-plane listing method for management views. It returns the room objects themselves, not a wrapped envelope, so the response can be rendered directly as a room list.
Optional page size for the list query.
Optional offset for paginated listing.
Optional sort descriptor. The dashboard store defaults to { created: 1 }.
Optional filter object forwarded to the backend query.
curl --request POST \--url http://localhost/api/conferences/getAll \--header 'x-access-token: <your_api_token>' \--header 'Content-Type: application/json' \--data '{"limit": 10,"skip": 0,"sort": {"created": 1}}'
The backend returns a bare array of room objects, not a wrapped object.
[{"_id": "69f013c1aa11bb22cc33dd44","id": "69f013c1aa11bb22cc33dd44","name": "Main stage room","user_id": "69360341db559495f643de6a","mediaType": "MEDIA_TYPE_VIDEO_AUDIO","allow_webinar_mode": true,"allow_chat": true,"allow_share_screen": true,"record": false,"record_mode": "ROOM_COMPOSITE_GRID","max_participants": 50,"sid": "RM_x7h6k4example","active": true,"created": "2026-03-24T16:00:00.000Z","modified": "2026-03-24T16:00:00.000Z","success": true}]
Load one video call room by its id.
Use this when an operator opens the room editor, when you need to inspect the current room policy, or before deciding whether to start, stop, or update the room.
Identifier of the room you want to load.
curl --request POST \--url http://localhost/api/conferences/getById \--header 'x-access-token: <your_api_token>' \--header 'Content-Type: application/json' \--data '{"id": "VIDEO_CALL_ID"}'
The backend returns the stored room object for the requested id.
{"_id": "69f013c1aa11bb22cc33dd44","id": "69f013c1aa11bb22cc33dd44","name": "Main stage room","user_id": "69360341db559495f643de6a","mediaType": "MEDIA_TYPE_VIDEO_AUDIO","allow_webinar_mode": true,"allow_chat": true,"allow_share_screen": true,"record": false,"record_mode": "ROOM_COMPOSITE_GRID","max_participants": 50,"sid": "RM_x7h6k4example","active": true,"created": "2026-03-24T16:00:00.000Z","modified": "2026-03-24T16:00:00.000Z","success": true}
Update an existing video call room.
The update contract mirrors create. In practice this is how you change room policy over time: webinar behavior, chat availability, screen sharing, recording mode, participant limit, or the active-state intent.
Identifier of the room being updated.
The update contract mirrors create and reuses the same room-policy fields.
curl --request POST \--url http://localhost/api/conferences/update \--header 'x-access-token: <your_api_token>' \--header 'Content-Type: application/json' \--data '{"id": "VIDEO_CALL_ID","name": "Main stage room","user_id": "USER_ID","mediaType": "MEDIA_TYPE_VIDEO_AUDIO","max_participants": 50,"allow_webinar_mode": true,"allow_chat": true,"allow_share_screen": true,"record": false,"record_mode": "ROOM_COMPOSITE_GRID","active": true}'
The backend returns the updated room object.
{"_id": "69f013c1aa11bb22cc33dd44","id": "69f013c1aa11bb22cc33dd44","name": "Main stage room updated","user_id": "69360341db559495f643de6a","mediaType": "MEDIA_TYPE_VIDEO_AUDIO","allow_webinar_mode": true,"allow_chat": true,"allow_share_screen": true,"record": false,"record_mode": "ROOM_COMPOSITE_GRID","max_participants": 50,"sid": "RM_x7h6k4example","active": false,"created": "2026-03-24T16:00:00.000Z","modified": "2026-03-24T16:10:00.000Z","success": true}
Start a video call room by id.
Starting the room marks it active and ensures the LiveKit room exists for the join flow. Use this when the room should begin accepting participants again after being paused or prepared ahead of an event.
Identifier of the room to start.
curl --request POST \--url http://localhost/api/conferences/start \--header 'x-access-token: <your_api_token>' \--header 'Content-Type: application/json' \--data '{"id": "VIDEO_CALL_ID"}'
The backend returns { success: true } when the room has been activated and the room-creation path completes successfully.
{"success": true}
Stop a video call room by id.
Stopping the room marks it inactive and tears down the active LiveKit room state behind it. This is the operational counterpart to start when the meeting should no longer accept new participants.
Identifier of the room to stop.
curl --request POST \--url http://localhost/api/conferences/stop \--header 'x-access-token: <your_api_token>' \--header 'Content-Type: application/json' \--data '{"id": "VIDEO_CALL_ID"}'
The backend returns { success: true } when the room has been stopped successfully.
{"success": true}
Remove a video call room by id.
This removes the stored room object and also attempts to clean up the runtime room and egress state tied to it. Use remove when the room should disappear from the control plane entirely, not just be stopped.
Identifier of the room to delete.
curl --request DELETE \--url http://localhost/api/conferences/remove \--header 'x-access-token: <your_api_token>' \--header 'Content-Type: application/json' \--data '{"id": "VIDEO_CALL_ID"}'
The backend returns { success: true } after the room object and linked runtime state have been removed.
{"success": true}
Resolve the active LiveKit room name for a Callaba video call room id.
This is the first public helper in the browser join flow. Besides the room name itself, it returns the room-level behavior flags that the join UI needs to know, such as webinar mode, chat, screen sharing, and whether recording is enabled.
Identifier of the Callaba room you want to resolve into the active LiveKit room name.
curl --request POST \--url http://localhost/api/conferences-public/findLKRoomNameById \--header 'x-access-token: <your_api_token>' \--header 'Content-Type: application/json' \--data '{"id": "VIDEO_CALL_ID"}'
LiveKit room name used by the browser join flow.
Room behavior flags needed by the join UI.
Recording-related room flags returned alongside the lookup result.
Indicates whether the active room could be resolved.
{"id": "69f013c1aa11bb22cc33dd44","LKRoomName": "34d4f497-f95b-4543-8d15-fde0b77d8abc","allow_webinar_mode": true,"allow_chat": true,"allow_share_screen": true,"record": false,"record_mode": "ROOM_COMPOSITE_GRID","success": true}
Create a participant token for the browser join flow.
This is the second public helper in the room-entry path. After the client knows the active LiveKit room name, it requests a participant token for a speaker, guest, or hidden egress-style participant and uses that token to join the room.
Callaba room id for the conference being joined.
Resolved LiveKit room name returned by findLKRoomNameById.
Stable participant identity used in the token grant.
Optional display name shown in the room UI.
Optional hidden-mode flag used for egress-style or non-visible participants.
Optional token used only when a hidden participant should be allowed into a room whose webinar-mode policy would otherwise block that path.
curl --request POST \--url http://localhost/api/conferences-public/createToken \--header 'x-access-token: <your_api_token>' \--header 'Content-Type: application/json' \--data '{"room_id": "VIDEO_CALL_ID","LKRoomName": "34d4f497-f95b-4543-8d15-fde0b77d8abc","participant_name": "Jane Speaker","participant_id": "participant-123","hidden": false}'
LiveKit participant token used by the browser client to join the room.
Echoes the LiveKit room name used for the token grant.
Indicates whether the token was created successfully.
{"participant_token": "<livekit_participant_token>","LKRoomName": "34d4f497-f95b-4543-8d15-fde0b77d8abc","success": true}