> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gpuoutlet.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Managing API keys
> Creating, naming, editing and revoking keys in the dashboard — and how each field affects what the key can do.
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
The dialog asks for three things: a name, a set of scopes, and a mode.
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.
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](/api/scopes) for what each one unlocks.
**Live** keys can spend money. **Test** keys read the same real catalog but are
refused on every write. See [live and test keys](/api/authentication#live-and-test-keys).
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
| Field | Editable | Why |
| ----------------- | -------- | -------------------------------------------------------------------------- |
| Name | Yes | It is a label for you |
| Daily spend limit | Yes | See [Spend limits](/api/spend-limits) |
| Scopes | **No** | Would silently widen what a leaked key can do |
| Mode (live/test) | **No** | Turning a test key live would make every prior "safe" copy of it dangerous |
| The secret | **No** | We do not have it |
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:
```bash theme={null}
# What is this key running right now?
curl -s -G https://api.gpuoutlet.ai/v1/rentals \
-H "Authorization: Bearer $ANOTHER_KEY" \
-d active=true
```
The dashboard shows the same thing per key in its [usage
panel](/api/key-security#watching-what-a-key-does), 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.
| Situation | Keys |
| ---------------------------------------------- | -------------------------- |
| Production scheduler + CI + a local script | 3 keys, different scopes |
| Twelve worker nodes running the same scheduler | 1 key, shared |
| Two customers whose usage must not mix | 2 **accounts**, not 2 keys |
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
What each scope unlocks, endpoint by endpoint.
Cap what a key can spend in a day.
Watching usage, rotating, and what to do when a key leaks.
How to send a key, and what the 401s mean.