Skip to main content
API keys are long-lived bearer tokens that authenticate requests to Lyceum Cloud. They’re prefixed lk_ and pass in the Authorization header on every request:
Every endpoint in the API Reference accepts the same header.

​
Keys belong to an organization

Every API key is scoped to a single organization. The key authenticates the request and pins it to that org, there’s no need to send an extra X-Org-Slug header. The credits, runs, VMs, and deployments associated with the request are all billed and accessed through the key’s org. If you belong to several orgs, create a separate key in each one for the scripts that act on its behalf.

​
API keys vs JWT tokens

The platform supports two token types: JWT users can act on any org they’re a member of by sending X-Org-Slug: <slug>; with an API key, the org is fixed by the key itself.

​
Lifecycle

API keys can be:
  • Created with a name and an optional expiration date. Names are unique among the org’s live keys.
  • Regenerated to issue a fresh secret while keeping the key’s name, org, and expiration. Rotate a key without touching the scripts that reference it by name. Regenerating a revoked key also reactivates it.
  • Revoked to disable it. Reversible: the key leaves the default Active keys view in the dashboard, keeps its name reserved, and comes back when you regenerate it.
  • Deleted to remove it for good. The key disappears from every list, cannot be regenerated, and its name is free to reuse in the org. The row is kept internally for the audit trail.
A revoked, deleted or regenerated secret stops working on the management API immediately. On the inference endpoints it can keep working for up to 5 minutes, because the inference proxy caches key lookups. If a key has leaked, revoke or delete it right away and treat the next few minutes as exposed. The full key value is returned exactly once, in the response to the create or regenerate request. After that, only the prefix (first 8 characters) is visible. If you lose a key, regenerate it, or delete it and create a new one with the same name. Owners and admins manage every key in the org. Members can create keys for the org and manage the ones they created themselves; they don’t see other members’ keys.

​
Spend limits

An owner or admin can put a spend limit on a key: a cap on what that key may spend on serverless inference. Once the key has reached it, new requests with that key are refused with 402 and the error code api_key_spend_limit_reached, until the limit is raised, reset or removed. Members see the limit on their own keys but cannot change it. A limit either renews monthly, counting from the 1st of each calendar month (UTC) and starting over on the next, or is a fixed budget that counts until it is used up and stays exhausted until an owner raises or resets it. A monthly limit set in the middle of a month covers the whole month. What to expect:
  • A limit is a cap, not a reservation. Requests are still paid from the org’s balance, and the org’s own balance check comes first: a key under its limit in an org without credits is refused for the org’s reason, with the usual 402 and no error code.
  • It is a soft limit. What a key has spent is read from the ledger, which is settled every few minutes, and a request that is already running is never cut. A key can therefore exceed its cap by a few minutes of usage before new requests are refused.
  • Changes take effect within 5 minutes, like every change to a key, because the inference proxy caches key lookups.
  • The spend shown next to the limit in the dashboard is the estimate from the usage page and can differ slightly from the ledger the limit is checked against.
  • The minimum limit is 1 in the org’s account currency, with up to four decimal places.
API keys grant the same access as members of the org they’re scoped to. Store them in a password manager or secret store, and never commit them to source control.

​
Dashboard

Open API Keys in the dashboard. The page lists your active keys across every org you belong to, with filters to narrow by org and by status. Create a new key with the Create key button; the dialog defaults to the active org but you can pick any org. Each key row has three actions: regenerate (circular arrows) rotates the secret in place, revoke (the ban icon) disables the key reversibly, and delete (the trash icon) removes it for good. The Status filter switches between Active keys, Revoked keys and All keys; revoked keys carry a Revoked chip, and from there you can regenerate them to reactivate or delete them to free the name. As with creation, the new value from a regenerate is shown only once. Keys with a spend limit show it under their name: spend against the cap with a bar, amber from 80 percent and red at the cap. Owners and admins get a fourth action, spend limit (the dollar icon), to set, change, remove or, for a fixed budget, reset it. The create dialog offers the same limit.

​
CLI

​
REST API

Owners and admins can call them for any key in the org; members only for keys they created, and members cannot set spend limits.
The response contains plaintext_key, store it immediately. Every key response carries spend_limit, either null or {"amount", "currency", "renews", "since"}, where since is when the current budget started. To set a limit, pass spend_limit on create or patch it later; renews defaults to true.
Changing only the amount keeps the current budget. Switching between monthly and fixed starts a new one.