Authentication

One bearer key per project, shown once, revoked instantly.

Every request past the base URL carries a bearer token in the Authorization header, exactly the way an OpenAI client already sends one — there's no second header, no signature, no query parameter.

HTTP
Authorization: Bearer $LARSA_API_KEY

Key prefixes

Every key starts with sk-larsa-, followed by cryptographically random characters. The console never shows the whole thing again after creation — only sk-larsa-XXXXXXXX...XXXX, the first few characters and the last four, enough to tell two keys apart in a list without exposing a working credential on screen.

The fixed prefix is deliberate: a secret-scanning tool — GitHub's, your CI's, your own — can recognise sk-larsa- in a diff the moment it's committed. Give a leaked-key commit a chance to be caught by something other than an invoice.

Scoping a key to projects and models

Accounts are organisations, organisations hold projects, and a key belongs to exactly one project — never to the organisation directly. That's the first scope: a key made under *Website backend* can't be used to read usage from *Internal tools*, even inside the same account.

The second scope is the model list. Creating a key, you can name exactly which models it may call; leave the list empty and it inherits every model your plan allows. Either way, your plan is a ceiling a key cannot widen — naming a model your plan doesn't include doesn't grant it, it's simply refused.

FieldWhat it tells you
key_prefixThe only part of the key you'll ever see again.
allowed_modelsEmpty means every model your plan allows.
statusactive or revoked. There is no paused — a key either authenticates or it doesn't.
last_used_atThe fastest way to notice a key nothing should still be calling.

Rotation

There is no single call that swaps a key's value in place — that would mean two different secrets were, briefly, the same credential. Rotation is three ordinary steps on API keys: create the new key, deploy it wherever the old one was configured, then revoke the old one once nothing depends on it.

If a key leaks

  1. Revoke it first, ask questions after. On API keys, revoking deletes the credential at the gateway before the console record updates — the key stops authenticating immediately, not on the next sync.
  2. Create a replacement and deploy it before you forget which services were using the old one.
  3. Check what it was used for in Request logs, filtered to that key, for the window between the leak and the revoke.
  4. If it reached a public repository, purging the file isn't enough — rewrite the history that contains it, the same as for any other committed secret.

Why the secret is shown once

The value you copy at creation is never written down in a form that could be read back — what's stored is a peppered hash, the same shape a well-built login system stores a password in. Showing it again would mean keeping the plaintext somewhere, and a database that can produce your key is a database that can leak it. The dialog says this outright when you create one: this key is shown only this once and cannot be recovered.

Never put a key in code that runs in a browser. Anyone who opens your site's developer tools, reads its network requests, or downloads its JavaScript bundle can read a key embedded in it — a bearer token isn't checked against the page's origin, so nothing about "it's only used from our domain" protects it. Call the API from a server you control, and let the browser talk to that server instead.

Reading the key from the environment

Every sample in these docs reads LARSA_API_KEY from the environment rather than writing it inline — do the same in your own code, in every language:

curl https://api.console.larsa.larsima.com/v1/models \
  -H "Authorization: Bearer $LARSA_API_KEY"
Navigate Open esc Close