Skip to main content
With direct output, each browser receives the avatar’s video and voice over WebRTC. Your API key and the session’s WebSocket stay on your server; the browser only talks to one route of yours, which relays the WebRTC handshake to the session.

1. Your route

One POST route, protected by your app’s own authentication. It takes two kinds of body: If the session replies with an error (or doesn’t reply within about 15 seconds), answer with an HTTP error, such as 503. One route serves any number of browsers. With several conversations at once, give each its own route, such as /avatar/{conversation_id}. This is exactly the contract of the SDK’s handleView, so the browser side can be the SDK’s player or your own code. See the Python example for a complete route.

2. The page

Networks

The avatar’s stream works for most networks with a public STUN server. For users behind strict corporate firewalls, add your own TURN server to iceServers (in LiveAvatarView, its iceServers option).

Sound

Browsers block sound until the user interacts with the page. Start watching from a click, such as your “Start call” button.