API keys

An API key lets your backend talk to Livqeno. It's the only thing that can make tokens, so it's the most powerful credential in your app. Keep it on a server you control.

Where this fits: project → API key → your backend makes tokens → your app joins. This page goes deeper than API credentials: how keys are stored, how to rotate them, and what a leak actually exposes.

Format

• The public id is used to look the key up.
• The secret is checked against a hash. Livqeno never stores it in readable form.
• The prod part is just a label for you. The real environment is stored on our side. Editing the label changes nothing.

How keys are protected

Livqeno never stores your secret as-is. It stores a hash: a one-way fingerprint that can check a key but can't be turned back into it. The hash also mixes in an extra server-side secret (a pepper) that isn't stored in the database.

The threat this covers: if Livqeno's database were ever stolen, the thief still couldn't recover working keys from it. This is also why Livqeno can't show you a key again after you create it.

Create a key

On your computer (or from the dashboard):

livqeno keys create --name backend --environment production

• You see the secret only once. If you lose it, create a new key.
• --environment accepts dev / development, stg / staging, prod / production, in any case.
• An unknown value is rejected, not guessed. A typo like prd fails instead of quietly giving you a development key.

Send it

Your backend sends the key as a bearer token in the Authorization header. The server SDK does this for you; with plain HTTP it looks like this:

curl "$LIVQENO_API_URL/v1/rooms" -H "Authorization: Bearer $LIVQENO_API_KEY"

The server SDKs keep the key in a private field, so it can't leak by accident into logs or error reports:

• Object.keys, JSON.stringify, and console.log can't see it.
• It is never logged and never put in an error.

Rotate a key

Rotating means replacing a key with a new one. Do it when someone who had the key leaves your team, when it may have been exposed, or on a regular schedule. This order keeps your app running the whole time:

1. Create a new key.
2. Deploy your backend with it and check traffic uses the new key.
3. Revoke the old key.

livqeno keys create --name backend-2026-09 --environment production
# deploy, confirm traffic is on the new key
livqeno keys revoke <oldKeyId>

Tokens made by the old key keep working until they expire. This is on purpose: revoking a key shouldn't drop every call in progress.

If a key leaks

A key "leaks" when it ends up somewhere it shouldn't: a public repo, a browser bundle, a screenshot, a support ticket. Here's what someone holding it could do:

All of this is limited to the key's own project and environment.

Related

• Access tokens: what the key is for. Read next.
• Security: all credentials in one place.
• Environments