Introduction

If you want to put a realtime AI receptionist on a website, the first design choice is usually not the model or the voice. It is the delivery mechanism: do you embed the agent directly in your app, or do you isolate it behind an iframe?

That decision affects security, deployment, latency, UI ownership, and how much backend work you need. In practice, teams usually want one of two things:

• full control over the UI and integration surface, or

• a self-contained embed that can ship quickly without exposing secrets or building much backend code.

This post compares Webflow-style page embeds and customer-managed iframe embeds for realtime AI receptionists, and shows when each approach is the right tool. By the end, you should be able to choose an architecture, understand the trade-offs, and know where Protoface fits if you want the avatar to be a first-class part of a voice agent or a lightweight website widget.

What “realtime avatar” actually means

A realtime AI receptionist is usually a voice agent plus a synchronized visual face. The speech side may run through a realtime model, an agent framework, or a telephony/WebRTC stack. The avatar side needs to stay aligned with the audio stream so lip movement, expression, and perceived latency feel coherent.

That synchronization is the critical technical constraint. If the audio arrives late, the face lags. If the face updates on a different clock than the voice stream, you get mismatched mouth shapes. So the embedding method has to work with a streaming transport, not against it.

From a browser perspective, the avatar is typically rendered via WebRTC or another low-latency media path. From an application perspective, you still need to think about session creation, auth, rate limits, browser permissions, and what data the frontend is allowed to know.

Option 1: Webflow or direct page embed

A direct page embed is the most flexible route when you own the page and want the avatar to live inside the layout. In Webflow, that often means using an embed block or custom code element to place the widget where you want it.

This is a good fit when:

• the receptionist is part of your product experience, not just a support widget,

• you need tighter control over sizing, styling, and surrounding UI,

• you want to coordinate the avatar with other app state, and

• you are comfortable running some backend logic to mint session credentials or proxy requests.

The upside is control. You can integrate the avatar with your own auth, page state, analytics, and routing. You can also decide exactly when to create or tear down sessions. For product teams building a custom sales flow or a guided onboarding assistant, that matters.

The downside is that direct embeds usually push you toward more integration work. If your avatar session requires an API key or session token, you should not expose that in the browser. That means a backend endpoint, token exchange, or some other trust boundary you own. If you are embedding in Webflow, you also have to be careful about cross-origin constraints, responsive layout, and lifecycle management when the page changes or the user navigates away.

Security and operational trade-offs

The main reason teams over-engineer the frontend is that they try to make the browser do too much. For realtime agents, the browser should generally consume a short-lived session or an already-embedded, constrained surface. It should not hold long-lived secrets.

With a direct embed, you typically have to solve:

• secret handling — keep API keys server-side,

• session minting — create per-user or per-visit sessions safely,

• origin control — prevent the widget from being reused elsewhere, and

• rate limiting — avoid abuse and surprise spend.

That is manageable, but it is work. If your team already has a backend and you need deep integration, that work is often worth it. If you just want a receptionist embedded on a marketing site, it may be unnecessary friction.

Option 2: customer-managed iframe embed

An iframe embed is the cleaner choice when you want to drop an interactive avatar into a website with minimal integration work. The important property is isolation: the iframe runs its own app surface, and the parent page only embeds it.

For a realtime receptionist, that buys you a few things:

• No backend required for the customer — the embed can be used without building server code.

• No API key in the browser — credentials stay out of client-side JavaScript.

• Better isolation — the widget is separated from the host page’s DOM and scripts.

• More controlled distribution — origin allowlists and embed-specific limits can constrain where it runs and how it is used.

That makes iframe embeds especially attractive for agencies, marketing sites, and product teams that want a fast path to production. It also reduces the chance that a frontend refactor breaks the agent.

The trade-off is that the iframe is less native. You do not get direct DOM access, so deep UI composition is limited. If you need the avatar to react to rich app state or share complex context with the host page, you need a deliberate messaging bridge or a backend-driven session model. In other words: iframe embeds optimize for safety and simplicity, not maximal composability.

When Webflow embeds beat iframe embeds

Use a direct Webflow embed when the receptionist is part of a broader product interaction and you need the parent page to drive behavior. Examples:

• a sales assistant that changes greetings based on logged-in user data,

• a support flow that pulls context from the current account page,

• a guided demo where the avatar accompanies a highly customized UI.

In these cases, the extra backend work is often justified because the avatar is not just an embedded widget; it is a component in your application architecture.

Here is the core pattern if you are creating sessions from your backend with the REST API. The exact payload fields depend on the session type and are documented, but the shape is the same: authenticate server-side, create a session, then send the browser only what it needs.

curl -X POST https://api.protoface.com/v1/sessions \
}'

curl -X POST https://api.protoface.com/v1/sessions \
}'

curl -X POST https://api.protoface.com/v1/sessions \
}'

If you are writing the backend in Python, the SDK is the natural place to do this orchestration. Keep the browser dumb, keep your secret key private, and return only a short-lived session artifact or embed URL.

from protoface_sdk import Client

print(session)

from protoface_sdk import Client

print(session)

from protoface_sdk import Client

print(session)

If your app already has this backend layer, a direct embed can be the better long-term architecture. If you do not, it can become accidental infrastructure.

When iframe embeds beat Webflow embeds

Use a customer-managed iframe when the main goal is to ship a receptionist quickly and safely on a site you do not want to turn into a custom app. This is usually the right answer for:

• marketing websites that need a conversational front door,

• lead capture or qualification widgets,

• product demos that should not require custom server work, and

• multi-tenant customers who need separate controls per embed.

The iframe model also simplifies governance. Parent-origin allowlists let you decide which sites can host the embed. Per-embed voice and custom instructions let you tailor behavior without handing out global privileges. Per-IP and duration rate limits help keep abuse and cost in check. Those controls matter when the avatar is customer-facing and realtime usage can scale quickly.

From a developer’s perspective, the big win is that you can hand a customer a snippet and avoid a support loop about API keys, CORS, or backend deployment. That is a real operational advantage, not just a convenience feature.

How Protoface fits in

Protoface sits in the part of the stack that makes the avatar realtime and developer-friendly without forcing you into a single integration style. For a voice-agent product, the cleanest pattern is often to keep the agent backend where it belongs and choose the surface that matches the deployment model:

• if you already have a backend and want tight integration, use the REST API or Python SDK to create sessions server-side,

• if you are adding a face to a LiveKit-based voice agent, the quickstart examples and the plugin path are usually the most direct route,

• if you want a website widget without exposing secrets, use the iframe embed.

For the LiveKit side specifically, the livekit-plugins-protoface plugin drops a synchronized avatar into an existing agent so the agent gains a talking face without you having to build media plumbing from scratch. That is useful when the voice pipeline already exists and the missing piece is the visual layer.

For docs and reference material, start at docs.protoface.com. If you want the plugin repository and examples, the GitHub org is the right place to look: github.com/protoface-ai.

Practical decision framework

Choose Webflow/direct page embed if:

• the avatar is a native part of your product UI,

• you need custom state or event coupling with the host page,

• you already have backend infrastructure, and

• you want maximum layout and interaction control.

Choose iframe embed if:

• you want a fast, low-risk deployment on a website,

• you do not want to expose API keys or build backend glue,

• you need clear isolation and customer-level control, and

• the avatar behaves like a self-contained receptionist rather than a deeply integrated app component.

A useful rule of thumb: if the host page should “own” the agent, use a direct embed. If the agent should “own itself,” use an iframe.

Conclusion

For realtime AI receptionists, the right embed pattern is mostly about trust boundaries and integration depth. Webflow-style direct embeds give you control and composability, but they usually require backend work to keep secrets safe and sessions well managed. Iframe embeds trade some flexibility for a much simpler operational model: no exposed API key, tighter isolation, and faster rollout.

If you are building a voice agent with a face, start by deciding whether the avatar is a UI component or a self-contained service. That answer should determine the embedding approach. Then check the docs, pick the relevant surface, and wire up the smallest secure path that meets your requirements at docs.protoface.com.