[AVAILABLE].
packages/api/src/middleware/caller-auth.ts, StaticKeyAuthenticator, verified against a live server in this session.Send a bearer key
Every route requiresAuthorization: Bearer <key> except GET /health.
Where keys come from
Keys are minted byscripts/generate-api-key.ts, one per calling system. The raw key is
shown once and never written to disk; only a SHA-256 hash of it is configured server-side
via PARMANA_API_KEYS, and comparisons run in constant time
(packages/api/src/auth/StaticKeyAuthenticator.ts). There is no self-service key-management
endpoint: issuing and rotating keys is an operator action, not an API call. See Deploy
patterns for the full setup and rotation
procedure.
What this layer does and does not prove
Caller authentication answers exactly one question: should this HTTP request be entertained at all. It is the first thing that runs, ahead of Policy evaluation and gateway attestation, and it is independent of both:- A well-authenticated caller submitting a Policy-rejected transaction is still rejected, see Policies and the decision.
- A well-authenticated caller does not thereby prove anything about who authorized the underlying business action, that is what Execution Authorization and the gateway establish, on a completely separate signature.
Local development
PARMANA_AUTH_DISABLED=true skips this middleware entirely and logs a loud warning at
startup every time it does. It exists for local development and running the tutorials.
Never set it in a real deployment. It removes the only authentication this API has, and
every route becomes reachable by anyone who can reach the port.
Errors
| Status | Condition | Body |
|---|---|---|
| 401 | Missing or invalid Authorization header | {"error":"authentication required"} |