Introduction

If you are adding a realtime avatar to a WordPress site for a fintech product, the hard part is not “render a face.” The hard part is deciding where the avatar logic should live, how much trust to give the browser, and how to keep latency low enough that the interaction still feels synchronous with the agent behind it.

With a setup like Protoface, you can attach a talking, lip-synced face to a voice agent, expose a managed avatar in an iframe, or drive everything yourself through an API. By the end of this post, you should be able to choose the right integration path for a WordPress deployment, understand the security boundaries, and implement a minimal working version without turning your frontend into a liability.

What changes when the avatar has to live inside WordPress

WordPress itself is not the issue. The issue is that WordPress sites tend to sit at the intersection of marketing, product, and compliance. That means you usually care about:

• Browser trust boundaries: whether an API key or session token ever reaches the client.

• Embedding constraints: whether you can ship through a page builder, Gutenberg block, or custom theme template.

• Realtime behavior: whether the avatar stays aligned with the voice agent and the user’s conversation state.

• Operational overhead: whether your team wants to own backend orchestration, scaling, and moderation logic.

For fintech specifically, the browser should be treated as an untrusted environment. If the avatar needs to converse with users about accounts, onboarding, or support, the safest default is to avoid exposing credentials in client-side code. That constraint drives the architecture more than any visual requirement.

REST API: maximum control, maximum responsibility

The REST API at api.protoface.com is the right fit when the avatar is part of an application backend and you want programmatic lifecycle control: create avatars, open sessions, track usage, and manage access from your server. This is the model you want when the avatar is tied to a user record, a support case, or a workflow that already lives in your app backend.

In practice, the flow is simple:

1. Your server authenticates with an API key.

2. Your server creates or selects an avatar/session.

3. Your frontend receives only the session information it needs.

4. The client connects to the realtime session through the approved transport.

That last step is important: the browser should receive a scoped, ephemeral artifact, not a long-lived secret.

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 \
}'

The exact fields and endpoints are in the docs, but the shape above is the relevant pattern: create a session on the server, set the conversation policy server-side, and hand the client only what it needs to join.

When REST is the right choice:

• You need custom auth or tenant isolation.

• You want to store session metadata in your own database.

• You need a backend policy layer for compliance, logging, or escalation.

• You are already running a voice-agent stack and want the avatar as one more managed service.

Gotcha: don’t create browser-only workflows around the REST API if that means shipping the API key into JavaScript. For fintech, that is usually the wrong trade.

Python SDK: best for backend orchestration

If your WordPress site is only the presentation layer and your application logic runs elsewhere, the Python SDK is a clean way to orchestrate avatars from a service worker, webhook handler, or internal admin tool. It is especially handy when the avatar session should be created in response to an event: a lead qualifies, a support call starts, or a user enters a high-touch flow.

from protoface import Client

print(session.id)

from protoface import Client

print(session.id)

from protoface import Client

print(session.id)

Again, the specific method names may vary slightly by SDK version, so treat this as illustrative and check the current docs. The important part is architectural: the SDK lets you keep your secrets and policy decisions in Python, not in a WordPress theme or plugin.

This pattern works well if your WordPress site is just a marketing frontend and the actual agent lifecycle is handled by a backend service in your stack.

iframe embeds: the safest way to ship a managed avatar on WordPress

If your requirement is “put an interactive avatar on a WordPress page with the fewest moving parts,” the customer-managed iframe is usually the cleanest answer. It works especially well when you want to avoid writing backend code and you do not want an API key anywhere in the browser.

The trade-off is straightforward: you give up some low-level control, but you gain a narrow security boundary and much simpler deployment. For a fintech site, that often matters more than customization depth.

A typical embed looks like this:

<iframe
></iframe>

<iframe
></iframe>

<iframe
></iframe>

The managed embed approach is useful because the sensitive parts stay on the provider side. The parent page can be restricted by origin allowlist, and the embed can enforce per-embed voice selection, custom instructions, rate limits by IP, and duration caps. That combination is exactly what you want when a WordPress page is public-facing and you want to keep the conversational surface narrow.

For implementation, the practical steps are:

1. Create the embed in the dashboard.

2. Allowlist your WordPress origin.

3. Set the voice and default instructions for that embed.

4. Place the iframe in a custom HTML block or theme template.

There is no backend to provision and no API key to protect in the browser. That makes it a strong default for demos, sales pages, support entry points, and other relatively self-contained experiences.

Gotcha: iframe embeds are not a substitute for app-native auth if the avatar needs to know who the user is. They are secure, but they are still a bounded surface. If you need deep personalization, session handoff, or access to your own user claims, use the REST API and pass only scoped context into the session.

LiveKit agents: when the avatar is part of a voice agent stack

If your agent already lives in LiveKit, adding a face should not require redesigning the whole pipeline. The relevant integration is the LiveKit Agents plugin, which drops a Protoface avatar into the agent so the speech stream and the video face stay synchronized. In other words, you keep your existing agent logic and attach the visual layer to it.

This matters because realtime avatars are only convincing when lip movement, audio timing, and turn-taking are aligned. If the avatar lags behind the agent or starts speaking before the audio is ready, users immediately notice. A plugin that sits in the agent pipeline avoids a lot of glue code.

from livekit.plugins.protoface import Protoface

)

from livekit.plugins.protoface import Protoface

)

from livekit.plugins.protoface import Protoface

)

That example is intentionally minimal. The exact constructor options and lifecycle hooks are in the plugin documentation, but the idea is consistent: the agent owns conversation flow, and the plugin handles the avatar output path. If you are already in the LiveKit ecosystem, this is the least disruptive way to add a synchronized face.

For people building realtime support or sales agents, this is usually the architecture that scales best: agent logic in LiveKit, avatar rendering in the plugin, and the web experience consuming the finished session.

How to choose for a WordPress fintech deployment

The decision usually comes down to who owns the backend and how much trust you want to give the browser.

• Use the iframe if you want the fastest path to a secure, browser-only embed on WordPress.

• Use the REST API if your WordPress site talks to a real application backend and you need custom session logic.

• Use the Python SDK if the orchestration happens in Python and WordPress is just the frontend.

• Use the LiveKit plugin if the avatar is a visual layer on top of an existing voice agent.

For fintech, I would usually start with the iframe unless there is a clear requirement for user-specific session context or backend orchestration. The main reason is not convenience; it is boundary management. Avoiding exposed keys and constraining the embed surface are real security benefits.

Practical implementation notes

A few things are worth keeping in mind regardless of approach:

• Voice latency is cumulative. The avatar can only feel realtime if your speech synthesis, transport, and rendering pipeline are all tight.

• Turn boundaries matter. If the agent interrupts itself or starts the next utterance too early, the face will look wrong even if the video stream is technically working.

• Policy belongs server-side. Put instructions, rate limits, and tenant-specific rules where they are enforceable.

• WordPress should stay thin. Use it as the surface layer, not the place where secrets and realtime coordination live.

If you need concrete setup details, the docs are the right place to validate the current API shapes and embed options: docs.protoface.com. If you are looking for code you can copy into an existing agent stack, the GitHub examples are useful starting points, especially the Python SDK repository and the quickstart collection.

Conclusion

For WordPress integrations, the main question is not “can I display a realtime avatar?” It is “where should the trust boundary sit?” If you want the least operational burden, use the iframe. If you need deep server-side control, use the REST API or Python SDK. If the avatar is part of a voice agent, the LiveKit plugin keeps the visual layer synchronized without forcing you to rebuild your agent.

Pick the narrowest integration surface that satisfies your requirements, then keep secrets and policy out of the browser. From there, you can wire the avatar into WordPress cleanly and still keep the architecture defensible for a fintech product. For implementation details, start with the docs and the quickstart examples on GitHub.