Embedding live video in a support flow no longer means stitching a Twilio Video, Daily, or LiveKit product onto your CPaaS. An embeddable video/RTC surface is now part of the Devotel Orbit platform's RTC-PaaS pillar, so the video room joins the SMS, WhatsApp, email, and voice channels a contact already uses — on one account, one bill. This guide walks through what gets embedded, how the join token is minted, the prebuilt widget Orbit's web SDK ships, and the questions support teams ask before they go live.
The examples below reference the shipped product surface end to end: the video API routes under /video, the Video Rooms dashboard under Voice, and the prebuilt <orbit-video-room> embed component that the Orbit web SDK (@devotel-orbit/web) registers. Every capability named here maps to something live today.
Why embed video into a support contact record at all
Text, phone, and email each handle some support motions well and others badly. A blown password, a complex walkthrough, a broken-account screen-share — these are faster over live video than over a chat transcript. The category term most support buyers search — "video API for customer support" — and the vendor categories they compare (Twilio Video, Daily, LiveKit, Agora) all resolve to the same product need: an RTCPeerConnection-backed room that a customer enters without installing anything, wired into the same account your SMS and WhatsApp already use.
What changes when the video room ships on the same platform as the other channels is that the contact record doesn't fragment. A session that starts as an SMS or WhatsApp thread can escalate to a video room, the recording lands on the same contact profile, and the audit trail — who joined, when, what was said — stays in one account. On a fragmented stack, a video vendor's recording belongs to a different dashboard and a different invoice from the messaging side, so timeline-reassembly is a manual merge.
How the embedded video room is assembled
The embed is three parts: a server-side call that mints a short-lived join token, a client-side snippet that hands that token to the video widget, and the widget itself, which renders a moderated room in the browser. The dashboard's Video Rooms page exposes all three on its Embed dialog.
1. Mint the join token server-side
Your back end never sends the tenant API key to the browser. Instead it POSTs to the video API to mint a short-lived join token for the specific room id and the display name of the participant:
curl -X POST "https://api.orbit.devotel.io/api/v1/video/rooms-scheduled/<room-id>/join" \
-H "X-API-Key: YOUR_DEVOTEL_API_KEY" \
-H "Content-Type: application/json" \
-d '{"participant_name":"guest"}'
# → { "data": { "token": "...", "livekit_url": "wss://..." } }The token is a bounded, per-join credential; it is what the browser carries, not the tenant key. The same join-token pattern is what the dashboard's Video Rooms Embed dialog emits for the <orbit-video-room> element, so the SDK's client-side snippet and your back end agree on the format.
2. Hand the token to the prebuilt widget
Drop in the declarative custom element the SDK registers. The snippet takes the server-minted token and points at Orbit's media edge over wss://media.orbit.devotel.io:
<script type="module" src="https://cdn.jsdelivr.net/npm/@devotel-orbit/web@latest/dist/index.mjs"></script>
<div style="height:600px">
<orbit-video-room
token="<server-minted join token>"
display-name="Support agent"
enable-screen-share="true"
></orbit-video-room>
</div>The toggles are attributes that default to true: start-with-camera, start-with-microphone, enable-screen-share, enable-device-selection. For an imperative access, the same SDK exposes OrbitVideoRoom.init(...) from JavaScript; the dashboard's Embed dialog names the same widget the <OrbitCallRoom> angle also uses, but the actual exported class is OrbitVideoRoom and the declarative tag is <orbit-video-room>.
3. Moderate and record in-room
Once the snippet mounts, the room is moderated the same way the dashboard's Video Rooms / Live tab drives it: camera and microphone toggle, screen share, device selection, host spotlight, room lock, and kick. Every join runs through the preflight media and permissions check the video API exposes, so browser autoplay and mic-permission failures surface as client-side toasts rather than as a hung UI.
For guest-side links the flow hangs on the server too: the same POST /rooms-scheduled/:id/join route issues the access token, so the guest lands on a lobby URL that the video API stamps with a bounded calendar block. Recording, playback, and the post-room summary all land back under the same Voice → Video dashboard — no second vendor, no second bill.
Where video joins SMS, WhatsApp, and voice in the contact record
Orbit's argument for video isn't the codec. It is that the video room is a contact-channel participant the same way a phone call or a WhatsApp thread is. The account carries the Customer 360 — a unified contact profile — so a session that escalates from SMS to a video room lands in the one timeline, with the video session, the recording link, and the messaging thread readable back from the same contact page. For a support org that sells video help as a paid add-on to existing CPaaS usage, that consolidation is what makes the pricing posture a usage line rather than a second-product subscription.
Pricing posture: usage on one bill
Video minutes, recording, and the live-broadcast and co-browse surfaces meter into the same pay-as-you-go account the rest of the channels draw down, not onto a separate vendor's invoice. Current rates are published on the pricing overview page rather than quoted to sales. For support teams already running SMS or voice through Orbit, adding video is enabling the Video Rooms dashboard on Voice — not integrating a LiveKit or Twilio Video tenant — which collapses most of the integration cost.
Frequently asked questions
What is an embeddable video/RTC API?
An embeddable video/RTC API lets a support or product team add live, in-browser video to their application by minting a short-lived join token server-side and mounting a prebuilt widget or SDK element client-side. The video room runs over WebRTC; the provider handles the SFU/media edge and the room lifecycle.
Does the browser ever see the tenant API key?
No. The tenant key stays on the back end, which mints a short-lived join token per-room and hands only the token to the browser. The widget or SDK element takes that token and a wss:// media URL; it never holds the long-lived account credential.
Do guests need to install anything to join?
No. The room runs in the browser via WebRTC, and a guest joins by clicking a lobby URL that the video API stamps with a join token. Permissions and media preflight are checked client-side, so a mic-permission failure surfaces as a toast rather than a hung UI.
Is video a separate product from SMS and voice?
No. Real-time video, broadcast, and co-browse run on the same platform as voice, SMS, WhatsApp, and email, and they are billed on the same pay-as-you-go account. A contact's video session records into the same C360 profile the other channels use.
Can the video room be moderated?
Yes. Hosts can mute, spotlight, assign roles, lock the room, and remove a participant from the dashboard's Video Rooms / Live page. The prebuilt widget surfaces the same camera, microphone, screen-share, and device-selection toggles so moderation travels with the embed.
The takeaway
Embedding video for customer support is a three-step wire: the back end mints a join token, the front end mounts the <orbit-video-room> element or calls OrbitVideoRoom.init, and the room runs through the same moderated, in-browser surface the dashboard uses. None of that requires a separate video vendor, so a support team keeps the video, SMS, WhatsApp, and voice history consolidated in one contact record — and one pay-as-you-go bill.
Published 25 August 2026.