Skip to main content
Keys live in the dashboard under Settings → API keys. Everything on this page is done there; there is no endpoint that mints a key, on purpose — a key that could create keys would turn a single leak into permanent access.

​
Creating a key

1

Click Create key

The dialog asks for three things: a name, a set of scopes, and a mode.
2

Name it

Up to 64 characters, and it must be unique within your account.The name is the only thing that will tell you what a key is for when you come back to a list of eight of them. prod-scheduler and ci-smoke-tests are useful; key1 and test are not. The uniqueness rule exists for exactly this reason — two keys called api are two keys you can no longer tell apart.
3

Choose scopes

At least one. Tick only what the integration actually does — a key that reads the catalog and nothing else cannot start a machine even if it ends up in a public repository. See Scopes for what each one unlocks.
4

Choose live or test

Live keys can spend money. Test keys read the same real catalog but are refused on every write. See live and test keys.
5

Copy the key

It is displayed once. Paste it straight into your secret manager or .env — not into a chat, a ticket, or a note “just until I’ve wired it up”.If you lose it, there is nothing to recover: we keep only a SHA-256 hash. Create a new key and revoke the old one.
An account can hold 10 active keys. Revoked keys do not count toward the limit and stay in the list as history — you can still see what a revoked key spent, which is exactly what you want when you are working out why last Tuesday cost more than expected.

​
What you can change afterwards

Scopes and mode are fixed for the life of the key. If an integration needs more access, mint a second key with the wider scopes, move over, then revoke the first. That way the widening is a deliberate act with an audit trail, not an edit that retroactively changes what every existing copy of a string can do.
Revoked keys cannot be edited at all — the server answers api_key_revoked_not_editable. Revocation is final; there is no un-revoke.

​
Revoking a key

Revocation takes effect immediately: the next request carrying that key gets 401 api_key_revoked. In-flight requests already past authentication finish normally, which is at most a few seconds. Revoking a key does not stop the rentals it started. A key is a credential, not an owner — the rentals belong to your account, keep running, and keep billing. If a leaked key started machines, revoke it and then stop them:
The dashboard shows the same thing per key in its usage panel, and marks API-started rentals with an API badge on the Instances page.

​
Keys scope to the account, not to themselves

This surprises people, so it is worth stating plainly:
A key with rentals:read sees every rental on the account — ones you started in the dashboard, ones another key started, all of them.
A key is a way for a program to act as your account, not a separate tenant with its own private set of machines. It follows that:
  • GET /rentals is a view of the whole account.
  • POST /rentals/{id}/stop can stop a rental this key never created.
  • The concurrency ceiling is shared: three keys do not get three times the limit.
If you need genuinely separate inventories — per-customer, per-team — you need separate accounts, not separate keys.

​
Choosing how many keys to have

One key per integration, not per developer and not per machine. The rule of thumb: if you would ever want to revoke access for one thing without breaking another, they need separate keys. Beyond that, more keys is more surface area to leak and more places to look when something goes wrong.

​
Next

Scopes

What each scope unlocks, endpoint by endpoint.

Spend limits

Cap what a key can spend in a day.

Monitoring and security

Watching usage, rotating, and what to do when a key leaks.

Authentication

How to send a key, and what the 401s mean.