This page lists what Livqeno can't do yet, or hasn't fully tested. Read it before you plan your app, not after you've built it. For example, if your product needs recorded classes, you'll find out here that Livqeno doesn't do that today, and can plan around it.
Each row says what's missing and, where there is one, the workaround.
Everything here comes from Livqeno's own testing, not guesses.
Not built
| Feature | Status |
|---|---|
| Recording of calls | An RTC room (a call) can't be recorded: no combined video, no per-track archive, no API to start or stop one. The one recording Livqeno makes is the HLS replay of a broadcast-mode live stream, ready after the stream ends (live_stream.recording_ready webhook). |
| Free plan allowances never reset | On the Free plan every account gets three separate allowances: 10,000 RTC participant-minutes, 100,000 chat messages, and 100 live-streaming host-hours, each enforced on its own. They are one-off, not monthly. To go past them, move to a paid plan under Billing, where the same amounts are included every month and the rest is billed (Usage). |
| Metering of other things | TURN bandwidth, storage, and API requests aren't counted. Live streaming's limits on concurrency, viewers, and duration (Usage) are capacity limits, not usage. The limits are technical limits, not plan limits. |
| Admin portal | There's no admin area. No admin roles, and no way to change or reset a developer's allowance. |
| Chat token revocation in the SDKs and CLI | Your backend can revoke a chat token with DELETE /v1/chat/tokens/{tokenId} (the tokenId comes back when you make the token). New connections with it then fail with TOKEN_REVOKED, but a connection that is already open stays open. There's no server-SDK method or CLI command for it yet, so call the REST endpoint directly. |
| RTC token revocation is best-effort | DELETE /v1/rooms/{roomId}/rtc-tokens/{tokenId} blocks new connections and ends sessions running on that token, but not a session that has refreshed onto a newer token, and a Redis outage delays it. To remove one person regardless, use POST /v1/rooms/{roomId}/participants/{identity}/remove. |
| A dropped participant leaves late | When someone's connection drops without leaving (a closed tab, a dead network), the server holds their session for up to 20 s so they can resume it. The rest of the room sees them leave only after that. A normal leave is immediate. |
| Changing your email | Your email is your account id, so it can't change. |
Restream and ingest limits
Restream (RTMP out) and OBS & encoder ingest (WHIP and RTMP in) are built, with these limits:
| Limit | Detail |
|---|---|
| Restream destinations | Up to 5 RTMP/RTMPS destinations per stream. |
| Restream layout | A fixed grid at 1280×720. No custom layouts or templates. |
| Ingest codecs | H.264 video only, with no B-frames. Audio is AAC (RTMP, transcoded to Opus) or Opus (WHIP). No HEVC, AV1 or SRT. |
| Ingest quality | Up to 1080p at 30 fps and 8 Mbps. Livqeno passes the video through without re-encoding, so viewers get the one quality you send. |
| One ingest per stream | One encoder at a time, on one key. |
| Ingest ports | Plain RTMP is on port 1935 and RTMPS on port 1936, not the usual 443. Some networks block these. |
Chat limits
| Limit | Detail |
|---|---|
| Unread counts stop at 999 | The inbox and inbox.updated show 999 for anything from 999 up. |
| Live inbox updates stop at 1,000 members | Conversations with more than 1,000 active members don't send inbox.updated. Keep those rooms joined instead. Live-stream audience chats never send it. |
| Event catch-up keeps 7 days | GET …/events?afterEventSeq= answers 410 EVENTS_EXPIRED for anything older. Re-read history instead. |
| Live events can arrive slightly out of order | eventSeq never repeats, but two events that happen at the same moment can be delivered in either order. The SDKs wait briefly for a gap to fill, then fetch it. |
| Search matches whole words | Full-text search with no stemming: "deplo" doesn't match "deploy", and "running" doesn't match "run". |
| Edit history is for moderators | GET /v1/chat/messages/{id}/revisions needs MODERATOR/ADMIN or an API key. Authors can't read their own edit history. |
| Link previews read HTML only | One fetch of the first link: 3 s, 1 MB, no redirects followed, og:/twitter: tags and <title> only. |
| Per-conversation send cap | 50 messages per second per conversation across all senders (CHAT_MAX_MESSAGES_PER_SECOND_PER_CONVERSATION), answered with RATE_LIMITED and scope: "conversation". |
Built, but not fully tested
These exist and seem to work. They just haven't been tested as thoroughly as the rest.
| Area | What isn't proven |
|---|---|
| Browsers | Only Chromium is tested with real media. Firefox, Safari, and Edge are not. Untested browsers still report as "supported", because support is detected from features. That says what a browser can do, not that it works well with Livqeno. |
turns: (TURN over TLS), end to end | The test certificate is self-signed, so the full client path can't be checked. The server side is tested on its own. |
| Symmetric NAT | The relay is tested by forcing iceTransportPolicy: relay, not on a real network that only allows relays. |
| Capacity | Tested up to 100 participants on loopback with fake media. That is not a real-world capacity number. |
| Flutter at runtime | livqeno_live has unit tests for reading credentials. The methods that call into livqeno_rtc / livqeno_chat don't. Run flutter test before shipping. |
Not finished
| Area | Details |
|---|---|
| Congestion control | Network feedback (TWCC) is collected, but nothing uses it to lower quality. A viewer on a bad connection sees glitches instead of a lower-quality video. |
| Adaptive quality on React Native | LivqenoVideoView pauses hidden video, but can't report its size yet, so a small tile on a phone still gets whichever quality the server picks rather than one sized to the tile. Call track.setLayer('low') for thumbnails. |
| Pre-call test on Flutter | runConnectionTest() is on web and React Native only. |
| Simulcast with AV1 / H.265 | Layer switching only works with VP8, VP9, and H.264. Single-layer tracks in AV1 / H.265 are fine. |
| Join and leave history | rooms.participants.list() shows who is in the room right now, from the media server. It isn't a saved history. null means the server couldn't be reached, not that the room is empty. |
| Live-stream analytics | You get the current viewer count and the peak. No history over time. |
Platform caveats that can affect you
These come from how the platform works today. They can go against what other pages suggest, so read them before relying on these features.
Chat attachments may be turned off
Attachments need file storage. When it isn't set up (no STORAGE_BUCKET),
attachment calls return RAVEN_NOT_CONFIGURED. So
Attachments may describe a feature that isn't turned on
for you. Try one upload in development before you build a UI around it.
Some participant identities are reserved
Livqeno's own participants (recorders, relays, AI transcribers and agents)
join rooms under identities starting with egress-, relay-, capture-,
transcriber- or agent-. Those get no webhooks and aren't counted as
your users, so an RTC token for one of your own users with such an
identity is refused with 422 RAVEN_RESERVED_IDENTITY. If your user ids
can start with one of these (an agent- prefix for support staff, say),
prefix them yourself, for example user-agent-42. See
Tokens.
Webhook URL protection only checks the hostname
When you register a webhook URL, Livqeno blocks non-HTTP schemes and
literal loopback or private addresses. Production also requires
https://. But it does not look up DNS, so a hostname that points to a
private address gets through. So does a redirect to one.
What this means for you: register only public https:// URLs that you
control, and don't rely on Livqeno to catch a URL that points inside a
private network.
How to read this page
Nothing here is a promise about when it will change. It describes what is true today, so you can decide if Livqeno fits your app. And if you hit one of these, you'll recognize it instead of debugging your own code for a day.
Next steps
- Production checklist: what to do about the ones that affect you.
- Build for production · Troubleshooting