Introduction

If you want an interactive AI receptionist on a marketing site, the hard part is rarely “can I render video?” It’s the operational pieces: keeping the browser surface simple, avoiding backend work when you don’t need it, not leaking credentials, and making sure the avatar behaves like a real session rather than a static widget.

This post shows how to embed a realtime receptionist into a Webflow page using an <iframe>, with the right mental model for how the session works, what should live in the parent page versus the embedded app, and the trade-offs you need to account for in production. By the end, you should be able to ship a secure iframe embed, reason about voice and instruction configuration, and know when to move from a no-backend embed to a more custom integration.

What an iframe-based avatar embed actually buys you

For a Webflow site, an iframe is usually the cleanest boundary. The parent page stays in Webflow; the avatar experience runs in its own origin and owns the realtime session, media permissions, and any internal UI state. That gives you a few practical benefits:

• No API key in the browser. The embed can be customer-managed so the browser never sees a secret.

• Less coupling to your site. Webflow handles layout; the embedded app handles WebRTC/media, loading states, and session lifecycle.

• Better security boundaries. You can use an allowlist of parent origins, plus per-embed rate limiting and session duration limits.

• Faster iteration. You can change instructions, voice, and appearance without redeploying your Webflow site.

The main constraint is that cross-origin iframes are intentionally isolated. Your Webflow page should treat the avatar like an embedded application, not a DOM component. If you need deep UI integration or rich event plumbing between the page and the agent, you can still do that, but you’ll usually use postMessage or a more custom integration path later.

How the session model works

An interactive receptionist is typically a realtime session, not a one-off render. The browser connects to a session endpoint, negotiates media, and then streams audio in both directions. The avatar’s video is usually synthesized from the agent’s speaking turns, so the face must stay synchronized with the audio output to avoid the uncanny “talking head out of phase” effect.

In practice, a session has a few moving parts:

• Identity: which avatar or embed configuration to use.

• Behavior: voice choice and instructions that shape the receptionist’s responses.

• Transport: WebRTC or an equivalent realtime media path for low-latency audio/video.

• Controls: rate limits, time limits, and origin checks to keep usage bounded.

When you design the interaction, keep the receptionist role narrow. For example: greet users, answer FAQs, qualify leads, book callbacks, or route to support. If you try to make the agent do everything, the session becomes harder to constrain and much harder to evaluate.

Embedding in Webflow: the practical shape

In Webflow, you usually create a section or component with an iframe sized the way you want the avatar to appear. The embedded app is then responsible for the actual UX: connecting to the session, showing the face, handling mic permissions, and exposing any basic controls like mute or restart.

A minimal embed looks like this:

<iframe
></iframe>

<iframe
></iframe>

<iframe
></iframe>

The exact URL shape depends on your embed setup, but the important parts are the same:

• allow must include the media permissions the experience needs.

• The iframe should be large enough for the avatar and controls to remain usable on mobile and desktop.

• The embedded app should be resilient to reloads, slow connections, and blocked autoplay until the user interacts.

Do not try to “fake” realtime by preloading a video clip into the iframe. The value here is the live interaction loop: user speaks, agent responds, avatar lip-sync follows the agent output.

Security and operational boundaries you should not skip

If the iframe is customer-managed, the parent page should never hold a long-lived API key. That is the biggest practical advantage of this pattern. The browser can’t be trusted with secrets, and Webflow is not the place to generate or protect them.

The controls you want in production are straightforward:

• Parent-origin allowlist: only approved site origins can load the embed.

• Per-embed configuration: assign a specific voice and instructions to that receptionist instance.

• Duration limits: cap how long a session can run.

• Per-IP rate limits: prevent abuse and surprise usage spikes.

Those guardrails matter even for “simple” receptionist use cases. Public landing pages get crawled, spammed, and clicked on by more than your intended audience. A realtime avatar session is more expensive than a static form, so rate limiting is not optional.

What the browser has to do, and what it should not do

The browser should handle presentation and media permissions. It should not generate credentials, mint session tokens, or contain hidden business logic you would otherwise keep server-side.

If you are building the embedded app yourself, the flow is usually:

1. Load the iframe.

2. Initialize the session from an embed-scoped configuration.

3. Prompt for microphone access when interaction begins.

4. Attach the audio track to the realtime session.

5. Render the avatar video and synchronize it to the agent’s speech output.

That flow keeps the parent page simple. In Webflow, the only thing your page really needs to know is the iframe URL and the size/layout rules around it.

Where Protoface fits

This is exactly the kind of surface Protoface is meant for: a developer-facing realtime avatar layer that can sit in front of a voice agent without making your site own the media stack. For iframe embeds specifically, the key point is that the embed can be customer-managed, so you avoid exposing an API key in the browser while still getting an interactive session with origin allowlisting and usage controls. The detailed configuration shape is documented in the docs.

If you want to see the broader developer surfaces, there are also SDK and plugin paths for cases where the avatar belongs inside a voice agent or a backend workflow rather than a website embed. But for Webflow, the iframe boundary is usually the right abstraction.

When you need more than the iframe

The iframe approach is the right default for a marketing site, lead capture page, or support landing page. It is less ideal if you need the avatar to directly coordinate with page state, custom analytics events, or a highly interactive product UI.

That is the point where you start deciding whether to keep the iframe and communicate with it through a narrow message contract, or move to a deeper integration. A good rule of thumb:

• Use iframe embeds when the avatar is mostly self-contained.

• Use a backend-driven integration when you need programmatic session creation, custom authorization, or tighter agent orchestration.

For example, if you want to generate sessions from your backend before sending a user into the receptionist experience, a small Python script using the SDK is often enough:

from protoface import Client

print(session.embed_url)

from protoface import Client

print(session.embed_url)

from protoface import Client

print(session.embed_url)

The exact fields and method names may differ, so treat this as illustrative and verify the current API in the docs. The architectural point is what matters: create sessions server-side, hand the browser only the embed/session URL, and keep credentials out of client code.

Testing and deployment checklist

Before you publish the Webflow page, test the embed the way users will actually encounter it:

• Open the page in a private window and confirm the iframe loads without auth assumptions from your local browser.

• Check microphone permissions on desktop and mobile.

• Verify autoplay behavior and the fallback when the browser blocks it.

• Confirm the parent origin is allowlisted correctly.

• Load-test the session limit and rate-limit behavior so spikes fail safely.

• Make sure the embed still works when Webflow pages are cached or served through a CDN.

Also check the failure UX. A production receptionist should degrade gracefully: connection pending, permission denied, rate limit hit, or session expired should all produce a clear message rather than a blank rectangle.

Conclusion

For Webflow, an iframe is the most practical way to ship an interactive AI receptionist without pulling realtime media complexity into your site code. Keep the parent page simple, keep secrets server-side, and treat the avatar as a self-contained session with explicit controls for origin, duration, and rate limiting.

If you are building the embed from scratch or deciding how much of the stack to own, start with the docs, prototype the experience with a narrow receptionist script, and verify the browser permissions and session behavior before polishing the UI. The relevant implementation details and current configuration options are in docs.protoface.com.