Core concepts

Livqeno uses a small set of words, and every page in these docs builds on them. Read this page once and the rest of the docs will make sense. Every word here is a real thing you'll see in the API or an SDK.

If you haven't built anything yet, you can also start with the Quickstart and come back here when a word is unclear.

How they fit together

Everything you create lives inside a project. Here is how the pieces connect, in the order you'll meet them while building an app:

Project                          you create one per app; everything belongs to it
 ├── Environment                 development · staging · production
 │    └── API key                your backend's secret for this environment
 │         └── Token             short-lived pass your backend makes for one user
 │
 ├── Room                        a video/audio call
 │    ├── Participant            one user (identity) in the call
 │    │    └── Track             their camera · microphone · screen share
 │    └── Connection             a saved record of one join, for debugging
 │
 ├── Conversation                a chat channel
 │    ├── Member                 a user allowed to read and write
 │    └── Message                saved, ordered, with reactions and threads
 │
 ├── Live stream                 a room + a conversation, with host/viewer roles
 │
 └── Webhook endpoint            a URL on your backend; Livqeno POSTs events to it

The same picture, as a story

Say you're building a telehealth app where alice (a doctor) video-calls bob (a patient) and they can chat during the visit:

1. You create a project for the app. It comes with three environments. You build in development.
2. You create an API key for development and put it on your backend.
3. When Bob opens his appointment, your backend creates a room (demo-room) and a conversation for the visit.
4. Your backend uses the API key to make a token for Bob, and one for Alice.
5. Each app joins with its token. Now each of them is a participant in the room. Their camera and mic are tracks.
6. Livqeno records each join as a connection, so you can debug a bad call later.
7. When something happens, like a message being sent, Livqeno fires an event. Your app sees it right away. Your backend can get it as a webhook.
8. Each minute of the call and each message counts toward your free usage.

Two layers: control and media

Livqeno has two layers. Knowing which one you're talking to explains why your app only ever needs a token.

Your app never picks a media server. It connects to the signaling address in its token grant, and Livqeno picks the media server for it.

All the concepts

More short definitions (SFU, TURN, ICE, grant, and others) are in the Glossary.

What Livqeno doesn't have

Check these before you design your app, because they change what you build:

• No call recording. An RTC room (a call) can't be recorded. The only recording is the replay of a broadcast-mode live stream, ready after it ends (live_stream.recording_ready). See Live stream.
• Free allowances are one-off. On the Free plan, usage counts against fixed allowances that never reset. Paid plans include the same amounts every month and bill the rest. See Usage.
• No user accounts for your users. Livqeno doesn't know who your users are. A user's identity is just a string your backend puts in the token. Your own login system stays the source of truth.
• No separate "channel" type. A channel is one of the three conversation types (CHANNEL).

Next steps

1. Quickstart: see these concepts in working code.
2. Project, then Token: the two concepts every app depends on.
3. Architecture: why calls and chat run separately.