Architecture

This page explains what happens inside Livqeno when your app makes a call or sends a message. You don't need it to get started, but it helps you design your app and debug problems. If you haven't yet, read What is Livqeno? first.

The three parts of Livqeno

What happens when a user joins a call

1. Your app asks your backend for a token.
2. Your backend calls the control plane with its API key: POST /v1/rooms/{id}/rtc-tokens.
3. The control plane returns a token, plus the addresses of the media server and relays to use (the grant).
4. Your app opens a signaling connection (a WebSocket) to the RTC plane and presents the token.
5. The RTC plane checks the token and connects the user to a media server (an SFU). The SFU receives each person's camera and mic and forwards them to everyone else in the room.
6. If the user's network blocks a direct connection, media goes through a TURN relay. That's why you must forward the grant's iceServers unchanged: they hold the relay details for this user.

Words like SFU, TURN, and signaling are explained in the Glossary.

What happens when a user sends a message

1. Your backend makes a chat token for the user: POST /v1/chat/tokens.
2. Your app connects to the chat plane over a WebSocket with that token.
3. When the user sends a message, the chat plane saves it first, then confirms it to the sender and delivers it to the other members.
4. A user who was offline gets what they missed from the saved history.

RTC and chat are separate on purpose

RTC and chat run on different servers, with different tokens.

• Failures stay contained. If chat has a problem, calls keep working, and the other way around.
• You use only what you need. Your app can be calls-only, chat-only, or both.
• Tokens don't cross over. An RTC token doesn't work for chat, and a chat token doesn't work for calls.

The cost: an app that uses both opens two connections. That's expected and small.

How tokens keep your app safe

Only a short-lived token ever reaches a browser or phone. Never your API key.

• The token expires on its own.
• Your app can't change what it allows. The permissions are signed into it.
• If someone copies a token, they get one user in one room for a short time, not your whole project.

Environments keep test and live data apart

Every project has three environments: development, staging, and production. Each API key belongs to exactly one of them. A development key can never touch production rooms, messages, or webhooks.

A common setup:

Next steps

• Quickstart: see this whole flow work in 10 minutes.
• Authentication: the full token model.
• Environments: how development, staging, and production stay apart.