Introduction

API keys are the easiest part of a realtime avatar integration to get wrong. In a standard web app, the failure mode is obvious: someone inspects the browser, finds a secret, and starts calling your API. In a voice agent or interview-bot workflow, the blast radius is bigger because the system is streaming audio/video, creating realtime sessions, and often running continuously in production.

This post is about handling those keys the way you would handle payment credentials or signing keys: keep them server-side, scope what each component can do, enforce limits before usage gets expensive, and preserve enough auditability to answer “who created this session, when, and from where?” by the end of the month.

The examples below use Protoface as the concrete case, but the patterns are general. By the end, you should be able to:

• keep realtime avatar credentials out of the browser and client app;

• issue short-lived, server-generated credentials or session parameters safely;

• apply rate limits that match avatar/video workloads, not just request counts;

• log enough metadata to investigate abuse without storing sensitive payloads.

Start with the core rule: the browser never gets your API key

For realtime avatar systems, the temptation is to “just pass the key through” to whatever creates the session. That works in a local prototype and fails immediately in production. If a browser, mobile app, or untrusted frontend can read a long-lived key, it can usually:

• create unlimited sessions until you hit spend or quota;

• generate avatars or recordings under your account;

• exfiltrate other metadata if the key is over-privileged;

• keep working after you thought you revoked access, if the key was copied elsewhere.

The fix is simple in principle: the frontend asks your backend for a narrowly scoped action, and only your backend talks to the vendor API using the secret API key. This is true whether you are creating a session for a video interview bot, provisioning an avatar, or attaching a face to a live voice agent.

Use server-side signing for anything browser-facing

For browser-integrated flows, the safest pattern is server-side signing or server-side session creation. The frontend sends your backend the minimum input needed to request a session, and the backend validates the user, applies policy, and then creates the realtime resource using the secret key stored in your environment or secret manager.

A useful mental model is:

1. Frontend authenticates to your app.

2. Your backend authorizes the action, checks account state, and rate-limits it.

3. Your backend calls the avatar API with the secret API key.

4. Your backend returns only short-lived session data or an embed/tokenized configuration to the browser.

In other words, the browser should receive an opaque session handle or short-lived credential, not the capability to mint one itself.

When you do need to talk directly to a realtime surface from a trusted server process, use the vendor’s REST API with a server-held bearer token. A simplified example looks like this:

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

Exact fields vary by endpoint and product surface, so treat this as illustrative. The important part is architectural: the secret stays on the server, and the request body contains only data you are comfortable auditing later.

Design rate limits around sessions, not just HTTP requests

Realtime avatar systems create a different resource profile than ordinary REST APIs. One user action may trigger:

• session creation;

• stream setup and codec negotiation;

• audio transcription or TTS calls downstream;

• continuous video rendering and bandwidth usage;

• potentially long-lived connections that tie up capacity.

That means a naive per-request limit is not enough. You want layered controls:

• API key rate limits to prevent a leaked secret from generating unbounded traffic;

• user or tenant quotas to prevent a single customer from consuming all capacity;

• per-IP limits to reduce abuse from a small set of sources;

• duration limits on sessions so abandoned calls do not run forever;

• concurrency limits to cap simultaneous avatars or active interview rooms.

For interview bots, duration limits are especially useful. A candidate leaving the tab open should not keep a high-quality video session alive indefinitely. For customer support, concurrency limits matter more: a single authenticated operator may legitimately open several sessions, but not hundreds.

One practical rule: rate-limit the expensive operation closest to the cost center. If session creation is what allocates video infrastructure, limit session creation. If a specific quality tier drives cost, apply stricter quotas per tier. Billing by quality tier makes this even more important, because “just one more high-quality session” can be materially more expensive than a low-quality one.

Separate authentication, authorization, and session identity

A common implementation mistake is to treat “has API key” as equivalent to “allowed to create anything.” Those are distinct concerns.

• Authentication: does this request come from your backend or from a known customer?

• Authorization: is this user allowed to create an avatar session for this workspace or interview?

• Session identity: which end-user or job does this realtime session belong to?

Put the end-user identity into metadata or your own database record, not into a secret. That gives you a stable join key for later analysis without making sensitive data part of the credential itself. For example, when your backend creates a session, store a record like:

• your internal user ID;

• request timestamp;

• avatar ID and quality tier;

• client IP or tenant ID;

• realtime session ID returned by the API;

• policy decisions made by your app.

That record becomes the source of truth for debugging and for billing reconciliation.

Keep audit logs useful, not noisy

Audit logs are only useful if they help answer specific questions quickly:

• Which API key created this session?

• Which internal user or tenant initiated it?

• From what IP range or app version?

• Was the request allowed, rate-limited, or rejected?

• Which avatar, voice, and quality tier were used?

For security and privacy, log metadata, not raw conversational content, unless you have a clear retention policy and consent model. In many interview or support flows, the audio and transcript are sensitive. If you must log more, keep it explicitly separated from operational logs and access-controlled accordingly.

Good audit logging also makes API key rotation less painful. If every request includes a key identifier, you can rotate secrets incrementally, verify that old keys are unused, and revoke compromised credentials without guessing what they touched.

A minimal pattern is to attach a request ID and a key fingerprint to every server-side call, then emit a structured log line when the call succeeds or fails. Avoid logging the full secret. A truncated or hashed fingerprint is enough.

Practical server pattern: one thin “avatar session” endpoint

For most products, the cleanest design is a single backend endpoint that your frontend calls when it needs a new avatar session. That endpoint does five things:

1. validates the authenticated user;

2. checks entitlement and quota;

3. applies your own per-IP and per-tenant limits;

4. creates the session via the vendor API using the server-side key;

5. returns only the data the browser needs to connect.

If you are using Python, the shape usually looks like this:

from protoface import Client

return {"session_id": session.id}

from protoface import Client

return {"session_id": session.id}

from protoface import Client

return {"session_id": session.id}

The exact SDK call names may differ, but the structure should not: the secret is loaded on the server, session creation is centralized, and the frontend gets an opaque result. If your stack uses a LiveKit voice agent, the same principle applies when you add the avatar face to the agent pipeline: the integration should run in trusted backend or agent infrastructure, not in a browser bundle.

Where Protoface fits: choose the surface that matches your trust boundary

Protoface gives you a few different integration surfaces, and the right one depends on where you want the trust boundary to sit.

If your app already has a backend and you need direct control, use the REST API or Python SDK from server-side code. That keeps API keys in your infrastructure and makes it easy to enforce per-tenant quotas, key rotation, and audit logging. The quickstarts in the GitHub org are useful if you want to see the integration shape in practice: GitHub examples and the documentation cover the intended server-side flows.

If you do not want any backend at all, the customer-managed iframe embed is the safer browser path because the API key never enters client code. That is a materially better default than rolling your own browser token exchange, especially for public-facing apps. The embed model also makes it easier to enforce parent-origin allowlists and per-embed rate limits without exposing implementation details to the client.

For LiveKit-based voice agents, the plugin path is the natural fit when you want the agent to gain a synchronized talking face. The same key-handling rules still apply: the plugin should be installed and configured in your trusted agent runtime, not surfaced to end users, and session creation should remain behind your server-side policy layer.

Conclusion

The main lesson is straightforward: treat avatar session creation like any other privileged backend action. Keep API keys server-side, generate short-lived or opaque session artifacts for clients, limit usage at the right layers, and log enough metadata to reconstruct what happened without leaking sensitive payloads.

If you are building interview bots, support agents, or any other realtime avatar workflow, the next step is to put these controls into the first request path, not as a later hardening task. Start with a single server endpoint, add structured audit logs, and enforce per-tenant and per-IP limits before you launch.

For implementation details, check docs.protoface.com, then wire up the surface that matches your architecture. The right security boundary is usually the one you can explain in one sentence: “the browser can ask for a session, but only our server can create one.”