Production checklist

Everything to check before real users arrive. Things Livqeno can't do yet are marked.

Use this list when your app already works in development and you're about to let real users in. It walks through the whole flow — API key → your backend mints tokens → your app joins → webhooks report back — and asks one question at each step: "is this safe and solid for real traffic?"

Work from top to bottom. Each item says why it matters, so you can judge it for your own app. Items marked ⚠️ or Not available are gaps in Livqeno, not mistakes on your side. They're listed so you can plan around them.

API keys and secrets

Your API key is the master credential for one project environment. Anyone who has it can mint tokens for any user. So most production incidents start here.

You have a production API key, separate from your development key. A dev key can never touch production data, so mixing them up shows as "room not found" errors, not as a data leak.
LIVQENO_API_KEY is in secret storage. Not in your repo. Not in a committed .env file.
No API key is in any client bundle. Search your built output for rvk_. If you find one, treat it as leaked: rotate it.
Your webhook signing secret is stored separately from the API key.
You have written down how to rotate a key: create → deploy → check → revoke. You don't want to work this out for the first time during an incident.

Tokens

A token is the short-lived pass your backend gives to one user so their app can join one room or chat. These checks keep a token from granting more than you meant.

RTC token lifetime is chosen on purpose. 600 seconds is a good default. Don't use 21600 just because it's allowed. Revoking a token doesn't remove someone already in a call, so a short lifetime is your real protection if a token leaks.
You make a new token for each participant, each time they join. Never share one between users. The user's identity is inside the token, so two people sharing one would clash in the room.
The user's identity comes from your login session, never from the request body. Otherwise anyone could call your endpoint as alice and join as her.
Permissions are as small as possible. Viewers get { join, subscribe } and nothing more.
Chat clients handle onTokenExpiring. Without it, chat stops working when the token expires (after one hour, by default).
You send the whole token response to the client, unchanged, including endpoint, iceServers, and telemetryUrl. iceServers holds the TURN relay details. Dropping it is the classic "works on Wi-Fi, fails on mobile data" bug.

Browser origins

An origin is the address your web app is served from, like https://app.example.com. Livqeno only accepts browser connections from origins you list.

Every address your app runs on is added under Settings → Security → Allowed Origins. In development, localhost is allowed on any port, so this is easy to forget until launch day.
You tested on a strict network (corporate Wi-Fi, mobile data), not just your office. Those networks block direct connections, so calls must go through the TURN relay.

Environments

Production and development use different API keys.
Webhook endpoints are registered for the right environment. A staging endpoint never receives production events.

See Environments.

Webhooks

A webhook is an HTTP request Livqeno sends to your backend when something happens (a message is sent, a stream ends). If your app relies on them for things like saving data or sending notifications, these checks matter.

You check the signature: use the raw body, check the timestamp window, compare in constant time. Without this, anyone who finds your URL can send you fake events.
You ignore duplicates using Livqeno-Event-Id. Livqeno retries failed deliveries, so the same event can arrive twice.
You order events by createdAt, not by when they arrived. Retries mean events can arrive out of order.
You reply with a 2xx within 5 seconds, and do the real work afterwards. A slow reply counts as a failure and triggers a retry.
You watch for delivery failures. After 50 failures in a row, the endpoint turns off, and you'd miss events without noticing.

See Handle webhooks for a working example.

Monitoring

When a user says "the call didn't work", you need a way to find out why.

Someone on your team knows to run livqeno diagnostics and livqeno errors list during an incident.
You log the requestId from errors, so you can search for it. It's the one value that links your logs to Livqeno's records.
You get alerts when the rate of failed connections goes up. Livqeno has no built-in alerts yet. See Observability.

Limits

Livqeno has fixed limits on sizes and request rates. It's better to stop a user in your UI than to show them a server error.

Your message box checks the message length before the user presses send.
Your app checks attachment size before uploading.
The token rate limit (60 per window) is enough for how users join your app. For example, if a class of 100 students all join at 9:00, your backend mints 100 tokens at once with the same key.
On a 429, you wait retryAfterSeconds, not a fixed delay.
Your UI can actually show as many participants as a room allows.

All values: Limits & quotas.

Reliability

Networks drop. Phones switch from Wi-Fi to mobile data. Your app should recover without the user doing anything.

When reconnecting, you show a status banner and keep the participant grid on screen.
On failed, you make a fresh token and rejoin.

See Handle reconnection.

Capacity: measure, don't assume

You have tested your own app at your expected size. Livqeno's 100-participant test used loopback and fake media. It is not a capacity number. ⚠️

Gaps to accept (or plan around)

Livqeno doesn't have these. If your product needs one, decide now how you'll handle it.

No call recording. An RTC room can't be recorded. Only a broadcast-mode live stream leaves a replay (live_stream.recording_ready).
Free allowances never reset. On the Free plan they are one-off. Move to a paid plan under Billing before you run out. See Usage.
No automatic quality downgrade. A viewer on a bad connection sees glitches, not a lower-quality video. ⚠️
Only Chromium is tested with real media. ⚠️
Simulcast needs VP8, VP9, or H.264. AV1 and H.265 can't switch layers.

Before you pick a launch date

Read Known limitations from start to finish. It's short, and it can save you from a bad launch.

Next steps

Build for production: the same topics, with code.
Security: how credentials are protected.
Observability: where to look when something goes wrong after launch.