Authentication is how Livqeno knows who is making a request and what they're allowed to do. This page explains the whole model in one place. Read it before you write your token endpoint.
Where this fits: project → API key → your backend makes tokens → your app joins. This page covers the two credentials in that flow, and why they're separate.
A Livqeno app has three separate kinds of login. Mixing them up is the most common mistake, so here they are side by side.
| Who logs in | To what | With what |
|---|---|---|
| Your users | Your app | Your own login system. Livqeno isn't involved. |
| Your backend | Livqeno | An API key. Permanent until you revoke it. |
| Your app (browser or phone) | A call or chat | A token. Short-lived. |
The flow
Here's what happens when alice, already logged into your app, joins a call
or opens a chat:
livqeno.tokens.create({ room, identity, permissions })livqeno.chat.createToken({ userId, conversations, scopes })Why you need an API key
Livqeno serves many projects. The API key tells Livqeno which project a request is for: whose rooms to create and whose limits apply. It's the one credential that can do anything in your project's environment, which is why it lives only on your server.
The key also:
- Is the only thing that can make tokens.
livqeno.tokens.create()andlivqeno.chat.createToken()both need it. Your app can't call them. - Locks every token to one project and one environment. A token can never reach another project. A development key can't touch production data. See Environments.
- Can be revoked on its own. Revoking one project's key doesn't affect others. Every call made with it shows up in the dashboard and audit log.
API keys
An API key looks like rvk_<env>_.... Treat it like a database password.
- Keep it in your backend's secret storage only. Never in frontend code, a mobile app, or git.
- Pass it to the server SDK yourself (
apiKey: process.env.LIVQENO_API_KEY). The SDKs never read environment variables on their own, so they can't pick up a key from the wrong place. - It belongs to one environment. A development key can't make a production token.
- Revoke it with
livqeno keys revoke <id>. Tokens it already made keep working until they expire.
More: API keys.
Tokens
A token is short-lived and only works for a small, fixed set of things.
Why not just give the app the key? Anything you ship to a browser or phone can be read by its user. A token is safe to hand out because, even if someone copies it, they get one user in one room or conversation for a short time, not your whole project.
| RTC token | Chat token | |
|---|---|---|
| Allows | join / publish / subscribe in one room | read / send (and more) in named conversations |
| Lifetime | minutes to hours, max 6h | you choose, always short |
| Identity | set once, by your backend | signed into the token, can't be changed |
| Used in | createRTCClient({ token, endpoint }) | createChatClient({ token }) |
Each token also carries the environment it was made in. A token made with a development key only ever reaches development data.
More: Tokens.
What the SDKs promise
These protect you from leaking the key by accident, for example in a log line or an error report sent to a monitoring tool:
- The API key is kept in a private field. It never shows up in
JSON.stringify()orrepr(). - It is never logged, at any log level.
- It is never put in an error. Errors only carry
{message, code, requestId}. See Error Codes.
Next
- Tokens: how to make tokens on your backend. Do this next.
- Permissions: what each permission allows.
- Browser security & CORS: limiting which websites can use your project.
- Environments: how a token's environment follows it.
- Roles & Permissions: who on your team can create keys, and for which environment.