If you came from the business version, that piece covered what you commit to when you adopt a provider — pricing, residency, lock-in. This is the companion “how,” for the engineer who has to build it. Every provider’s quickstart is excellent and nearly identical: to integrate a video SDK at demo level, you initialise the client, join a room, publish your camera, and two people are on video in an afternoon. None of that is the hard part. The hard part is everything the quickstart quietly assumes — that tokens are minted safely, that you only subscribe to the tracks you need, that the network cooperates, that recording and teardown are somebody’s job. This post is the map past the happy path.
The Quickstart vs the Production Path
The five-minute version hides five real subsystems. Here’s the gap in one view — the left column is the tutorial, the right column is what actually ships.
| The quickstart gives you | Production also needs |
|---|---|
| Init the SDK and join a room | Server-issued, scoped tokens with a TTL — not a hardcoded secret |
| One local camera + mic published | Simulcast layers and selective subscription to control cost |
| Video that works on your office Wi-Fi | STUN plus TURN relay for the ~10–20% that can't connect directly |
| A "record" button | A server-side egress/compositing service and storage with known residency |
| Join | Clean teardown, reconnection, and token refresh on long sessions |
Everything on the right is skippable in a demo and non-negotiable in production. We’ll take them in the order you hit them.
Rooms and Tokens: Auth Is the First Real Decision
The room model
A room (some SDKs call it a session or a channel via a video room API) is the media context participants join to send and receive tracks. Two questions decide how you model it: are rooms ephemeral (created on demand, gone when empty) or persistent (long-lived, addressable by a stable ID), and who is allowed to create one. For most products rooms are ephemeral and created server-side when a call or meeting starts, so the client never decides a room into existence on its own.
Tokens: the part you must not get wrong
Access is granted by a signed token — typically a JWT your backend mints with the provider’s API secret. The token carries an identity, a set of grants (which room, may-publish, may-subscribe, may-record), and a time-to-live. The single most common security mistake in video integrations is putting the API secret in the client to generate tokens there. Never do it: the secret lives only on your server, your server issues short-lived scoped tokens on request, and the client receives a token it cannot forge or widen. Grant least privilege — a viewer’s token shouldn’t carry publish rights — and keep the TTL short enough that a leaked token expires quickly, which is exactly why reconnection later has to handle refresh.
With auth done, the media itself is two verbs: publish and subscribe. That pair is where your bandwidth bill is decided.
Tracks: Publish and Subscribe Is Where the Cost Lives
Publishing
A participant publishes local tracks — camera, microphone, screen share — to the SFU (the Selective Forwarding Unit that forwards each track to other participants without re-encoding it). The important lever at publish time is simulcast: the client encodes the camera in two or three resolution layers at once, so the server can hand each viewer the layer their screen and bandwidth can actually use. Publishing a single high-resolution layer to a large room forces everyone to receive more than they can use; simulcast is what keeps a big room affordable.
Subscribing — the cost lever most people miss
The naive integration auto-subscribes every participant to every other participant’s tracks. In a 4-person call that’s invisible; in a 50-person room it’s a bandwidth and CPU disaster on every client. Production code subscribes selectively — only to the tracks actually on screen, at the layer actually visible — and unsubscribes the rest. Pair selective subscription with simulcast and adaptive stream (let the server drop to a lower layer when a client’s bandwidth sags) and you have the three controls that decide whether a large room is cheap or ruinous. This is the same on-demand principle the business version costs out; here it’s implemented as subscription state.
Layer in the meeting logic — active-speaker and dominant-speaker events, mute state, track-ended handling — and the media plane is complete. Except it only works if the packets can actually reach the other side.
NAT Traversal: STUN, TURN, and Why Your Demo Lied
Your demo worked because both machines were on friendly networks. In the wild, most participants sit behind NAT, and some behind NAT so restrictive that a direct peer path is impossible. WebRTC handles this with ICE: STUN lets a client discover its own public-facing address so two endpoints can try to connect directly, and TURN is a relay server that carries the media when a direct path can’t be established — symmetric NAT, corporate firewalls, locked-down mobile networks. As a rule of thumb, something like 10–20% of real-world connections end up needing TURN.
Two consequences for your integration. First, you cannot skip TURN and expect a reliable product; the connections that need it are exactly the enterprise networks your buyers sit behind. Second, TURN relays real media, so it costs real bandwidth — a line item a cloud SDK bundles into its per-minute rate and a self-hosted stack makes you provision. Either way, budget for it. Once media flows reliably, the service everyone forgets is recording.
Recording: The Service You Forgot to Budget
A record button implies a whole subsystem. Recording is usually server-side egress: a process subscribes to the room’s tracks and either stores them individually or composites them into a single mixed file — often via a headless browser or a dedicated egress pipeline, one per session. That is compute-heavy and storage-heavy, and it runs for the full duration of every recorded session, not as an afterthought. Where the file lands is also where the business version’s residency question becomes concrete: with a cloud SDK, recordings sit in the vendor’s cloud and region; with a self-hosted or managed deployment, they land in storage you control, with your encryption and retention. For regulated records the latter is usually mandatory. And whatever you record, every session eventually has to end cleanly — the part quickstarts almost never show.
Teardown, Reconnection, and the Lifecycle Quickstarts Skip
Clean teardown. Leaving a room isn’t just closing the tab. Unpublish tracks, release the camera and microphone, close the peer connection, and signal departure so the server frees resources and other participants get a clean “left” event rather than a frozen tile.
Reconnection. Networks drop. Production clients detect the disconnect, run an ICE restart to re-establish the media path, and re-subscribe to the tracks they had — without the user rejoining manually. On mobile especially, network changes (Wi-Fi to cellular) are routine, not exceptional.
Token refresh. Because tokens are short-lived by design, a long session will outlive its token. The client has to fetch a fresh token from your server and hand it to the SDK before the old one expires, or the reconnection above fails at the worst moment. These three are the difference between a demo and something people trust in production — and they set up the decisions that determine how stuck you are with your choice.
The Scaling Decisions That Lock You In
Three implementation choices, made early, decide both how well you scale and how hard you are to move later. Your subscription strategy (selective, simulcast-aware, adaptive) is what keeps large rooms viable — retrofitting it into a codebase that assumed auto-subscribe is a rewrite. Your region and residency posture — where the SFU runs and where recordings land — is cheap to set now and expensive to change once you have regulated customers. And the shape of your own code against the SDK’s room, token, and track abstractions is the lock-in the business version priced: wrap the SDK behind a thin interface of your own so “join,” “publish,” and “record” are your verbs, and a future migration becomes an adapter swap instead of a teardown. The SFU-versus-alternatives background, if you want it, is in our enterprise video architecture piece [link]. Put it together and the build-versus-buy question is concrete.
Build, Buy, or Deploy
Build on open source. A general-purpose SFU — mediasoup, LiveKit, or Janus are the usual open-source ones — with your own token service, TURN, recording egress, and reconnection logic around it. Maximum control over subscription and cost economics; you operate a distributed real-time system. Right when the media path is core to the product and you have the specialists.
Buy a cloud SDK. A client SDK in front of the vendor’s SFU, with tokens, TURN, and recording provided, billed per participant-minute. Fastest to production, least to operate, least control over media path and residency. Right when speed outweighs ownership.
Deploy a commercial platform. The whole stack — SFU, signaling, TURN, recording — as a unit you run on-premise or as a managed deployment on infrastructure you choose, flat-licensed. Samvyo is one such option: based on SFU architecture, deployed on-prem or managed, which gives you the owned media path and residency without assembling the components yourself. Where it doesn’t fit: an early product at low or spiky volume with no residency pressure — a cloud SDK is less to run and cheaper to start.
Three approaches, one axis — how much of the media path you operate yourself.
The Bottom Line
Integrating a video SDK past the demo comes down to a handful of subsystems the quickstart omits: mint scoped tokens server-side and never ship the secret, subscribe selectively with simulcast so large rooms stay affordable, run TURN for the connections that can’t go direct, treat recording as the compute-and-storage service it is, and handle teardown, reconnection, and token refresh. Get those right, wrap the SDK behind your own thin interface, and you have something that survives both production traffic and a future change of provider.
What’s Next?
Want the decision-maker’s version — what this commits you to, without the wiring? The companion business piece frames the same integration as four commitments: pricing, residency, lock-in, and white-label: link to business version.
Frequently Asked Questions
How do you integrate a video SDK the right way, beyond the quickstart?
Mint access tokens on your server (never expose the API secret in the client), model rooms server-side, subscribe selectively to tracks rather than auto-subscribing everyone, run STUN and TURN for NAT traversal, treat recording as a server-side egress service, and handle teardown, reconnection, and token refresh. The quickstart covers joining a room; production is those five subsystems.
Where should video SDK tokens be generated?
Always on your backend. The provider’s API secret signs a short-lived JWT that carries the participant’s identity and scoped grants (room, publish, subscribe, record). Generating tokens in the client means shipping the secret, which lets anyone forge access. The client should only ever receive a ready-made, least-privilege token with a short TTL.
Do I really need a TURN server?
Yes. STUN lets endpoints attempt a direct connection, but roughly 10–20% of real-world connections — symmetric NAT, corporate firewalls, restrictive mobile networks — can only connect through a TURN relay. Skipping TURN means those users, often your enterprise buyers, simply can’t connect. TURN relays media, so it also carries a real bandwidth cost to budget for.
Why does my video SDK integration work in testing but fail for some users?
Almost always NAT traversal. Testing usually happens on cooperative networks where a direct peer path exists; some production users sit behind restrictive NAT or firewalls that require a TURN relay. If TURN isn’t configured or provisioned, exactly those users fail while your tests pass.
How do you control cost when integrating a video SDK at scale?
Subscribe selectively — only to the tracks on screen — instead of auto-subscribing all participants, publish with simulcast so viewers receive a layer they can use, and enable adaptive stream so the server drops quality when bandwidth sags. Those three controls decide whether a large room is affordable. Flat-licensed SFU platforms such as Samvyo remove the per-minute variable entirely for high, steady volume.
What’s the hardest part of a production video SDK integration?
Not the media — the lifecycle around it: safe server-side token issuance, selective subscription at scale, reliable TURN, a real recording pipeline, and clean teardown with reconnection and token refresh. Wrapping the SDK behind your own thin interface also matters, because it’s what makes a future provider switch an adapter change rather than a rewrite.
