One vendor's documentation puts the gap in a single line: a prebuilt iframe gets you to a working call in minutes, a custom UI on its SDK takes hours to days. That is true, and it is the least important difference between the three embed video options.
Once you have made the build-or-buy decision and chosen a provider, there is a second choice inside "buy": how the video gets into your product. You can drop in the vendor's whole meeting UI in an iframe, assemble it from the vendor's UI components, or use the headless core SDK and draw every pixel yourself. Each one is cheap at a different moment. This post is about the moments after launch.
The Three Embed Video Options
Most providers now offer all three, under different names.
Option | What you get | Example |
|---|---|---|
Prebuilt iframe | The vendor's complete meeting UI, hosted on their domain, inside an <iframe> on your page | Daily Prebuilt; Jitsi/JaaS IFrame API |
UI kit | Ready-made components (video grid, controls, chat) that run in your page, on top of the core SDK | RealtimeKit UI Kit |
Headless SDK | Media, rooms and events as an API; no UI at all | Daily call object; RealtimeKit Core SDK |
The vendors describe the trade-off in their own words. Daily's documentation on call modes calls its iframe mode the best fit for fast integration with minimal UI work, and its call object mode headless: Daily handles WebRTC and media while you build every pixel. Cloudflare's RealtimeKit SDK guide estimates under two hours to ship with its UI Kit and typically five to six days with the Core SDK alone. These are the vendors' estimates, not measurements, but the order of magnitude is right.
Time to first call is a one-off cost. The rest of this post is the recurring ones.
What Each Option Costs Later
Cost that shows up later | Prebuilt iframe | UI kit | Headless SDK |
|---|---|---|---|
Making it look like your product | Themes and injected CSS only | Theme plus component props; replace components you outgrow | Unlimited; you build it |
Reacting to what happens in the call | Events the iframe API chooses to expose | Full SDK events | Full SDK events |
Where auth and roles live | Vendor's token properties | Your token service | Your token service |
Camera permission | Parent page must delegate it | Your page asks | Your page asks |
Native mobile app | A webview around someone else's page | Native kits where offered | Native SDKs where offered |
Upgrades | Arrive when the vendor deploys | When you bump a version | When you bump a version |
Leaving the vendor | Replace the whole UI | Replace the components | Replace the adapter |
Each row deserves a closer look, because each one is where a team that picked for speed tends to get stuck.
Styling: You Rent the iframe's UI
An iframe from another origin is a sealed box. Your stylesheet cannot reach into it, so every visual change goes through whatever the vendor exposes. Daily's Prebuilt customization guide is generous by iframe standards: feature toggles, colour themes, injected CSS, grid tile limits, custom tray buttons and sidebar apps. It is also clear about the edge: for a fully custom UI, use the call object. Even small things are on its terms; by default an embedded Prebuilt call has no leave button until you add one.
A UI kit moves the line. The components run in your page, take your theme, and can be swapped one at a time when one stops fitting. A headless SDK has no line at all, which is also its cost: every state the vendor's UI already handles (permission prompts, device switching, poor-network banners, screen-share layouts) is now yours to design and test.
Events and Auth: Who Owns the Call's State
With an iframe, your page learns about the call through the messages the iframe API chooses to send. If the API doesn't expose an event, such as a specific participant's network quality, you can't build a feature on it. With a UI kit or a headless SDK you get the full event stream, because the SDK runs in your page.
Auth moves the same way. In the iframe model, the vendor's UI makes the permission decisions, so your roles have to map onto its token properties. Daily's meeting tokens decide who is an owner or can record; 8x8's JaaS integration guide passes a signed JWT straight into the iframe constructor. That works until your product's roles don't fit the vendor's. With a UI kit or headless SDK, your own token service decides grants and your own UI enforces them, which is also where SSO and provisioning questions IT will ask get answered.
Permissions and Mobile: The iframe Has to Be Let In
A cross-origin iframe cannot use the camera unless the page that embeds it allows it. MDN's camera directive reference gives the default allowlist for the camera as self, and a blocked call to getUserMedia() rejects with NotAllowedError, the same error a user's refusal produces. In practice that means the iframe needs allow="camera; microphone", and per MDN's Permissions Policy guide the vendor's origin must also be allowed by your page's own Permissions-Policy header. Miss either and users see "camera blocked" with nothing in your logs to tell you why.
Mobile raises the stakes. Inside a native app, an iframe means a webview wrapping a page you don't control, with the platform's webview camera rules on top. On iPhones, that is WebKit, with its own camera behaviour on iOS Safari. Vendors that ship native SDKs and native UI kits avoid the webview entirely. If a native app is on your roadmap, check which of the three options the vendor offers on iOS and Android before choosing the web one.
Upgrades and Migration: Who Changes the Code
A hosted iframe changes when the vendor deploys. That is convenient: fixes and new features arrive without a release. It also means your users can see a new layout, a renamed button or a moved control before your support team does. With a UI kit or headless SDK, nothing changes until you upgrade the package, which is more work and more control.
Leaving is where the gap is widest. With a headless SDK behind a seam of your own, a provider change replaces an adapter. With a UI kit, the components go too, because they belong to the vendor. With an iframe, the whole meeting experience goes, and everything your users learned about it. That matches the evidence on what a provider switch rewrites: the object model, events and rendering all change.
Choosing: Which Layer Will You Need to Own?
The iframe is the right answer more often than engineers like to admit. If video is a supporting feature, used by a known audience on the web, with roles that fit the vendor's model, a prebuilt UI maintained by people who do nothing else is hard to beat. Accessibility, device quirks and poor-network handling come with it.
The signals that it won't stay right:
- Video is the product, or a core workflow. Branding and UX will matter, and themes run out.
- Your permissions model is your own. Clinician and patient, agent and customer, inspector and site: roles the vendor's token doesn't describe.
- You need call events in your own system. Analytics, billing by participant, CRM notes, compliance logs.
- A native app is coming. A webview is a poor long-term home for a camera.
If two or more apply, start with a UI kit and plan to replace components as you outgrow them. If you already know you need full control, go headless from day one; moving from an iframe to custom UI later means building the custom UI anyway, after users have learned the old one.
The Bottom Line
The three embed video options trade time now against control later. A prebuilt iframe is fastest and puts the vendor in charge of the UI, the roles and the release schedule. A UI kit shares that control. A headless SDK gives you all of it, along with every edge case. Choose by the layer you expect to own in eighteen months, not by the afternoon you save this week.
What's Next
Once auth lives in your own code, the next decision is how to issue tokens safely. Next: why you should keep the signing secret on your server.
Frequently Asked Questions
What are the embed video options for adding calls to a web app?
There are three: the vendor's prebuilt meeting UI in an iframe, the vendor's UI components running in your page, or a headless SDK where you build the UI yourself. Most video providers offer all three, under different names.
Is it bad to embed a video call in an iframe?
No. For a supporting feature on the web, with roles that fit the vendor's model, it is often the best choice. It becomes costly when you need your own branding, your own permission model, call events in your systems, or a native mobile app.
Why does my embedded video iframe say the camera is blocked?
The embedding page has to delegate camera and microphone access, usually with allow="camera; microphone" on the iframe and a matching Permissions-Policy header. Without both, getUserMedia() rejects with NotAllowedError, the same error as a user saying no.
What does "headless" mean for a video SDK?
The SDK handles media, rooms and events but ships no UI. You build every screen. It takes longer to launch and gives full control over design, permissions and behaviour.
Can I start with a prebuilt UI and switch to a custom one later?
Yes, but the custom UI is a rebuild, not a migration: nothing from the iframe carries over. A UI kit is the gentler path, because components can be replaced one at a time. Samvyo, for example, ships SDKs for JavaScript, React and React Native, so the choice of how much UI to own stays with you.
Which embed option is best for an on-premise deployment?
Any of them can work, but with an iframe the UI is served from wherever the vendor hosts it. If the requirement is that nothing loads from outside your network, check where the prebuilt UI is served from. With a platform such as Samvyo, which supports on-premise deployment, an SDK-based UI runs from your own application, so the question reduces to where the media servers sit.
