Migrating to Livqeno

How a move from Twilio Video, Agora, LiveKit or 100ms works, what maps cleanly, and what Livqeno does not do yet.

These guides are for teams that already run video, voice or chat on another provider and want to move to Livqeno. Each one maps the other provider's concepts onto Livqeno's, shows the same task written both ways, lists what the other provider has that Livqeno doesn't, and ends with a cut-over checklist.

Coming from	Guide
Twilio Programmable Video	Migrate from Twilio Video
Agora (RTC, RTM / Chat, Cloud Recording, Media Push, Media Gateway)	Migrate from Agora
LiveKit (Cloud or self-hosted)	Migrate from LiveKit
100ms	Migrate from 100ms

Upgrading from Raven or Livqeno, this platform's earlier names? That is a rename, not a provider move: see Migrate from Raven / Livqeno.

Livqeno in one minute

If you know any of the four providers, Livqeno's model will feel familiar. There are three differences that matter when you port code:

Rooms are created explicitly. Twilio, Agora and LiveKit create a room the first time someone joins it by name. In Livqeno your backend creates the room first, then makes a token for that room's id. Pass getOrCreate: true, so two users joining at the same moment both get the same room instead of one getting RAVEN_CONFLICT.
A token comes from the API, not from a local signing helper. Twilio's AccessToken, Agora's RtcTokenBuilder and LiveKit's AccessToken sign a JWT on your server with a secret you hold. Livqeno's server SDKs call POST /v1/rooms/{roomId}/rtc-tokens with your API key, and get back a grant: the token plus the signaling endpoint and per-user TURN iceServers. Hand the whole grant to the client SDK.
Calls, chat and live streams are separate products with separate tokens. A call needs an RTC token, a chat needs a chat token, and a live stream gets both from one call (addHost or createViewerToken). RTMP restream and encoder ingest belong to live streams, not to plain rooms.

Your app

Your backendserver SDK

Livqeno

join room X

checks your own session

swalvo.rooms.create({ name, getOrCreate })

swalvo.tokens.create({ room: room.id, ... })

grant: token, endpoint, iceServers

createRTCClient(grant).join()

The request flow, the same on every SDK.

What carries over and what doesn't

You use	On Livqeno	Notes
Group video calls, SFU	Yes	Rooms of up to 50 participants by default (Limits).
Simulcast / dual stream	Yes	Automatic on the web. `track.setLayer()` to pick a quality by hand (Tracks).
Screen share	Yes, video only	Tab or system audio isn't sent with the screen (Screen sharing).
Data messages	Yes	`room.sendData()`: reliable or lossy, with topics, targeting and the sender's identity (Data messages).
Persistent chat	Yes	A full chat product: history, threads, reactions, receipts, presence, moderation (Chat).
E2EE	Yes, Web and Flutter	Not React Native yet (E2EE).
Webhooks	Yes	HMAC-SHA256 signed, 5-minute replay window (Webhooks).
RTMP out	Yes, from live streams	Up to 5 destinations, fixed grid layout (Restream).
RTMP / WHIP in	Yes, into live streams	H.264 without B-frames (Ingest).
HLS for large audiences	Yes	Broadcast-mode live streams (Scaling the audience).
Call recording / compositions	No	Only the HLS replay of a broadcast-mode live stream.
SIP / phone dial-in	No	Nothing in the API dials or answers a phone call.
Speech-to-text, AI agents	No

How to migrate: the general shape

Every guide follows the same order. It keeps both providers live until Livqeno has proven itself on real traffic.

Map your concepts. Use the guide's mapping table to list every place your code touches the old provider: token endpoint, client join, mute, screen share, data messages, recording, RTMP, webhooks.

Add a Livqeno token endpoint next to the old one. Create a project and an API key (API credentials), install a server SDK, and add a second endpoint (or a branch in the existing one) that returns a Livqeno grant.

Put the client behind a flag. Wrap "join a call" in an interface with two implementations, and pick one per room or per user. Never mix providers inside one room: everyone in a call must be on the same one.

Point webhooks at both. Add a Livqeno webhook endpoint and map its events onto the handlers you already have. Deduplicate on Swalvo-Event-Id.

Decide about recording. If you record calls today, keep that traffic on the old provider until you have a plan (see each guide's gaps section).

Ramp up, then cut over. Move a small share of new rooms to Livqeno, watch connections and errors, then raise the share. Remove the old SDK once no room has used it for a full token lifetime.

Pricing

Livqeno's rates are published on Usage. These guides don't quote other providers' prices: they change often, so compare against their current pricing pages yourself.

Next steps

Known limitations: what Livqeno doesn't do yet.
Quickstart: the smallest working call.
Tokens: the token model in full.