API keys
Organization API keys, the two services that accept them, and how the required scope is decided.
Where keys come from
An organization API key is minted in the Console, listed there, and revoked there. Those three operations require an operator session — a key cannot mint, list or revoke a key, including itself. There is no other place a key is issued.
What a key can reach
core and sites. Those are the two services that install an API-key validator; the rest of
the estate refuses an organization key outright. If you send one elsewhere you get a refusal, and
the refusal is the correct answer rather than a misconfiguration on your side.
The scope a request needs
Scope is derived from the HTTP method, and both accepting services enforce it:
| Method | Scope required |
|---|---|
GET, HEAD | read |
POST, PUT, PATCH, DELETE | write |
A key without write cannot reach a POST, and a key with only write cannot reach a GET —
so a key minted for one job does not quietly become a key for the other. Mint a key with the
scopes the work actually needs, and expect a refusal if you guessed low.
A read-only integration that also polls a POST-shaped endpoint needs both scopes. The
derivation looks at the method, not at what the endpoint does.
Seeing the decision for a specific route
Every operation in the core and sites reference carries the scope it requires and the kind of authentication it accepts, taken from the same derivation the services run — not from a separate description of it that could disagree.
Behind that, one further check runs against the whole estate: a GET or HEAD that reaches a
write on the way to its answer would be assigned read and should not be, so a gate fails when
any read-method route reaches a non-cache write. The derivation is allowed to be generous; it is
not allowed to be wrong in the one direction that matters.