If you’ve ever integrated video, you probably started by reaching for an SDK. That’s the part everyone talks about. But an SDK, on its own, can’t create a call, decide who’s allowed into it, or shut it down when it’s over. Something on your server has to do that — and that something is a video room API. The two are constantly confused: treated as interchangeable, or assumed to be one product with two names. They aren’t. One runs the session; the other joins it. Getting the split right is the difference between a demo and a system you can actually operate.

Every video app has two halves: the session and the media

Before defining either term, notice that every real-time video product is really two systems wearing one name. There’s the session — the room itself: it exists, it has rules, it has a lifespan, it has a guest list. And there’s the media — the camera, the microphone, the frames on screen, the audio in your ear. These live in different places. The session is authoritative and lives on servers; the media is experiential and lives in the browser or the app. A video room API governs the first. A video SDK delivers the second. Almost every point of confusion in this space traces back to collapsing the two into one.

Start with the half people understand least — the room.

What a video room API actually is

A video room API is a server-side interface your backend calls to create, manage, and control video sessions — the “rooms” participants join. It’s the control plane. Your application server makes the requests: create a room, configure it (how many participants, how long it lives, whether it records), issue the tokens that let specific people in, list who’s currently connected, remove someone, end the room.

The key word is server-side. A room API is a conversation between your backend and the provider’s backend. No camera touches it; no video frame flows through it. It deals in the facts of the session — who, when, how long, what’s allowed — not the pixels. That’s exactly why it’s where every rule you care about ends up living.

If the room API is your backend’s tool, the SDK is what runs in front of the user.

What a video SDK is — and why it doesn’t replace the room API

A video SDK is a client-side library. It runs inside the browser tab or the mobile app, and its job is the media experience: capture the camera and microphone, encode and send those streams, receive everyone else’s, and render them on screen. It handles the messy real-time parts — device permissions, codecs, network adaptation, reconnection.

Here’s the distinction people miss: the SDK joins a room; it doesn’t own one. When your app calls the SDK to “join,” it’s joining a session the room API already created. Strip the room API away and the SDK has nothing to connect to. They aren’t competing layers or two ways to do the same thing — they’re two ends of the same call. One is issued by your server; the other runs on your user’s device.

Which raises the question that actually matters when you’re deciding where your logic goes.

The line that matters: who enforces the rules

Anything that has to be trusted has to live on the server. That single sentence draws the line between the two.

Consider who’s allowed to join a call. You can’t enforce that in the SDK, because the SDK runs on the user’s machine, where the user controls everything — they can edit client code, replay requests, or lie about who they are. So permission has to be decided somewhere they can’t reach: your backend, via the room API, which mints a token that says “this person, this room, these rights, until this time.” The SDK then presents that token; it doesn’t grant it.

The same logic covers the rest of the business rules. When does recording start, and can the user stop it? Who can mute or remove another participant? When does the room expire? How many people fit inside? None of these can be trusted to the client — they belong to the room API. The SDK’s job is to deliver a great experience within whatever rules the server already set. Get this backward — try to enforce policy in the SDK — and you’ve built something that works in the demo and fails the moment someone pokes at it.

With the division of labor clear, here’s what the room API side of that line actually exposes.

What a video room API gives you

The exact surface varies by provider, but a room API almost always exposes the same core operations. They cluster into four jobs: managing rooms, managing participants, controlling recording, and being notified when things happen.

Category	Typical operations	What it's for
Room lifecycle	Create room, configure (size, expiry, recording policy), end/delete room	Bring a session into existence and set its rules
Access	Issue join tokens with scoped permissions	Decide who gets in and what they can do
Participants	List participants, mute, remove / kick	Observe and moderate the live session from the server
Recording	Start, stop, and manage recordings server-side	Trigger recording by policy, not by client trust
Events	Webhooks: participant joined/left, recording ready, room ended	React inside your own system to what happens in the room

The webhook row is easy to overlook and often the most useful. Because the room API sits on the server, it’s the natural place to be told what happened — a participant left, a recording finished, a room emptied out — so your application can react: update a database, send a notification, close a ticket. The SDK can’t do this reliably; a user closing their laptop lid doesn’t send you a clean event.

Seeing the pieces listed is one thing. Watching them work together in a single request is what makes the split click.

How the two work together: one join, walked through

Follow a single user joining a call.

Your frontend asks your backend to join room X. Your backend — not the browser — decides whether this user is allowed.
Your backend calls the video room API: create the room if it doesn’t exist, then issue a token scoped to this user, this room, with the right permissions and an expiry.
Your backend hands that token back to the frontend.
The frontend passes the token to the video SDK and calls join. The SDK connects to the media servers, starts sending and receiving streams, and renders the call.
As things happen — the user joins, later leaves, a recording finishes — the room API fires webhooks to your backend, which updates your system accordingly.

Notice that the SDK never makes a trust decision. It receives a token and renders media. Every “can they / should they / when does it” question was answered server-side, one step earlier, by the room API. That’s the whole relationship in one sequence: the server composes the session, the client experiences it.

Which is also why the two labels shouldn’t be shopped for as if they were rivals.

The Bottom Line

A video room API and a video SDK are not two options to choose between; they’re two halves of one build. The room API is the server-side control plane — it creates sessions, enforces who can do what, triggers recording, and tells your backend what happened. The SDK is the client-side experience — it joins the session the API created and handles the live media. If you’re evaluating providers, don’t ask “SDK or API?” Ask how cleanly each one separates the two, how much control the room API actually hands your server, and whether the permission and recording model is one you can trust. That separation is the real product.

What’s Next?

To go a level deeper on how a client actually joins — the tokens, the tracks, the room object in code — read Integrate a Video SDK: Rooms, Tokens, and Tracks. If you’re still sorting out which kind of SDK you even need, Video Call vs Conferencing vs Chat SDK draws those lines.

Frequently Asked Questions

What is a video room API?

A video room API is a server-side interface for creating, managing, and controlling video sessions. Your backend uses it to spin up rooms, set their rules, issue join tokens, moderate participants, and control recording. It handles the session — not the camera, microphone, or on-screen video, which are the SDK’s job.

What’s the difference between a video room API and a video SDK?

A video room API runs on the server and controls the session; a video SDK runs on the client and delivers the media. The room API decides who can join and what they can do; the SDK joins the room and handles camera, mic, and rendering. You typically use both together — the API creates the room, the SDK joins it.

Do you need both a video room API and a video SDK?

In almost all cases, yes. The SDK can’t create a session or enforce permissions on its own, and the room API doesn’t render video. The API composes and guards the room; the SDK lets users experience it. Building with only one leaves a gap the other was meant to fill.

Does recording get triggered by the SDK or the room API?

Recording should be triggered server-side through the room API, not the client SDK. Anything running on the user’s device can be tampered with, so recording policy — when it starts, whether a user can stop it — belongs on the server, where it can be trusted and audited.

Can a platform like Samvyo provide both the video room API and the SDK?

Yes. Samvyo ships the same embeddable client SDKs a CPaaS provider gives you, alongside the server-side room API that creates and controls sessions — so session control and the media experience come from one platform. Because it’s based on an SFU architecture, offered both on-premise and as a managed cloud, teams that need to keep the media path, TURN, and recording under their own control can, while the platform stays resilient by design. It’s the same SDK surface the SDK vendors give you, plus the deployment control and white-label depth they typically don’t.

Subscribe to Samvyo blogs