Introduction

If you need a realtime screening experience on a website, the hard part is usually not rendering video. It’s the plumbing: keeping an AI agent responsive, synchronizing speech with a talking face, handling browser security, and avoiding a backend just to get something embedded on a landing page or internal tool.

This post shows a practical pattern for embedding a realtime HR screening avatar with an <iframe> instead of building a custom server. By the end, you should understand when iframe-based embeds are the right tool, what the browser is actually doing under the hood, and how to configure a secure, customer-managed embed without exposing API keys in client code.

Why an iframe is the right abstraction for a screening avatar

A realtime avatar is not a static widget. It usually involves a streaming media channel, live speech synthesis or audio input, a conversation loop, and some session state that needs to survive page interactions. For an HR screening flow, the browser often only needs to display the avatar, capture microphone input if enabled, and relay interactions to the underlying realtime service.

The simplest mistake is to build this as if it were a normal frontend component. If you call a realtime API directly from the browser, you either expose credentials or end up with a fragile proxy layer. If you try to own the full media stack yourself, you inherit WebRTC signaling, token issuance, rate limiting, and session lifecycle management. That’s a lot of infrastructure for what is often a single embed on a recruiting page.

An iframe changes the boundary. The embed can own its own UI, session bootstrapping, and media handshake in an isolated origin, while your Svelte app simply allocates space for it and passes configuration. That means:

• No API key in the browser.

• Less coupling between your app and the avatar session lifecycle.

• Clear security boundaries for microphone access and origin isolation.

• A smaller integration surface to maintain in the parent app.

What the browser is actually doing

For a realtime avatar, the browser is typically handling a few things at once:

• Loading the embed UI from a separate origin.

• Negotiating a realtime session with the service.

• Receiving audio/video streams and rendering them with low latency.

• Forwarding user events, such as start, stop, mute, or text input.

If the avatar is part of a voice screening flow, the experience is usually event-driven: the user enters the page, the iframe initializes a session, the agent greets the candidate, and the conversation proceeds over a low-latency media path. The implementation details differ by provider, but the important point is that this is session-based streaming, not a single REST request that returns a video file.

That distinction matters for architecture. You do not want to treat a realtime avatar like a normal image or video tag. The session has state, the connection can fail, and the embed may need to enforce duration limits or per-IP restrictions. Those controls are easier to keep on the embed side than in your Svelte app.

Embedding the avatar in Svelte

In Svelte, the parent component can stay almost trivial. You render a container, point an iframe at the embed URL, and size it like any other responsive element. Keep the parent app responsible for layout and routing; let the iframe own the interaction.

<script lang="ts">

</style>

<script lang="ts">

</style>

<script lang="ts">

</style>

A few details matter here:

• allow="microphone; autoplay; fullscreen" is often required for a voice interaction flow. Without microphone permission, you cannot do a live screening conversation.

• aspect-ratio keeps layout stable before the iframe loads.

• referrerpolicy can help preserve a tighter browser privacy posture, though the exact configuration depends on your app.

You should also decide whether the iframe is decorative, interactive, or both. If it is part of a screening workflow, keep the surrounding page focused: candidate details, job context, and next steps should live in the parent page, not in the embed chrome.

Security and operational constraints you should not skip

The reason customer-managed iframe embeds are useful is not just convenience. They allow you to move sensitive operational concerns out of the browser and into the embed configuration.

The main things to pin down are:

1. Origin allowlisting. Only approved parent origins should be allowed to load the embed.

2. Session limits. Duration caps are important for both cost control and abuse prevention.

3. Per-IP limiting. This reduces the risk of automated abuse or accidental reload loops.

4. Instruction scoping. Per-embed voice and custom instructions should be configured server-side or in the embed configuration, not in frontend code.

For an HR screening use case, this is especially relevant because the content of the conversation may be domain-specific. You may want one avatar that screens engineering candidates and another that handles sales candidates, each with different prompts, tone, and expected conversation flow. Those differences belong in the embed/session configuration, not hardcoded into the page.

Also, keep in mind that iframe isolation is a feature, not a bug. If you need to deeply integrate with the parent page, the cleanest approach is to exchange limited events between the iframe and the parent rather than collapsing everything into one DOM tree. That keeps the media stack isolated and reduces the surface area for regressions.

How to create and manage the underlying session

If you do want to programmatically provision an avatar or a realtime session, use the API from a trusted backend or a developer workflow, not from the browser. The REST API is authenticated with API keys, so it belongs server-side. A small curl request illustrates the shape of the interaction:

curl https://api.protoface.com/<your-resource-path> \
}'

curl https://api.protoface.com/<your-resource-path> \
}'

curl https://api.protoface.com/<your-resource-path> \
}'

The exact endpoint and fields depend on the object you are creating, so treat the snippet as illustrative. The important part is the boundary: keys stay off the client, and the browser only receives whatever embed URL or session token your backend is allowed to hand out.

If you prefer Python for automation, the SDK is a better fit than raw HTTP for scripting avatar setup, batch session creation, or internal tooling. Again, the specific calls depend on the resource shape, but the pattern is straightforward:

from protoface import Client

print(session)

from protoface import Client

print(session)

from protoface import Client

print(session)

If you are building a staff-facing workflow, this is the level where you would generate an embed configuration for a given role, candidate segment, or department. Your application can remain a normal Svelte app; the avatar orchestration can live in a small internal service or even a one-off admin tool.

Where Protoface fits in this pattern

This is exactly the kind of integration Protoface is designed to make simple: a browser embed that can host a realtime avatar without asking your frontend to own the media/session plumbing. The customer-managed iframe model is the part that matters here. It keeps the API key out of the browser, supports parent-origin allowlisting, and gives you per-embed controls for voice, instructions, and rate limits.

If you are already using a voice agent stack, there are other integration surfaces as well, but for a pure Svelte frontend the iframe is usually the cleanest path. You can keep the parent app thin and still deliver a convincing realtime screening interaction with low operational overhead. The implementation details and configuration options are documented at docs.protoface.com.

Trade-offs and gotchas

The iframe approach is not free of trade-offs, so it helps to be explicit:

• Less visual control. You control the container, but not every internal UI detail.

• Cross-origin constraints. Direct DOM integration is intentionally limited.

• Lifecycle coordination. If the parent app navigates or re-renders aggressively, you may need to preserve iframe state carefully.

• Permission prompts. Browser microphone permissions can still fail or be denied, so design a fallback path.

For HR screening specifically, test the experience in the browsers your recruiters and candidates actually use. Autoplay policies, permission prompts, and responsive sizing tend to be the first things that break in production. Also verify that your embed behaves correctly when the candidate reloads the page, opens it in a new tab, or resumes after a short network interruption.

If you later need deeper orchestration, you can still layer it on top. The iframe can remain the presentation and media boundary while your backend manages candidate state, scoring, CRM updates, or handoff logic. That separation tends to age well.

Conclusion

If your goal is to put a realtime HR screening avatar into a Svelte app quickly and safely, the iframe pattern is the pragmatic choice. It avoids exposing secrets, keeps the realtime media stack isolated, and lets you focus on the product logic around the interview rather than the transport beneath it.

Use the parent app for layout and workflow, keep the avatar configuration server-side, and reserve the browser for rendering the embed. If you need to go deeper, start with the docs, then build out from there with a small backend or internal provisioning tool. The practical next step is to review the embed and session options in the documentation and wire up a minimal Svelte page that hosts the iframe cleanly.