Authentication
Every route takes a bearer token except the few that issue one. There are two ways to get a token, for two kinds of caller.
Service tokens
POST /tokens is the client-credentials grant: a client id, its secret, and the space-separated scopes the token should carry. A scope the client has not been granted is refused; a wrong id or secret answers identity.credential_invalid.
Customer API keys
A customer's API key is never sent with a request. It is exchanged at POST /tokens/api-key for a token scoped to that customer's accounts and valid for at most 60 seconds, and the token is what travels.
Scopes
A scope names an area and whether the token may read or write it: accounts:read, payments:write. A token without the scope a route needs is answered 403 with the code forbidden. Some staff actions also need a recent sign-in, and answer step_up_required until there is one.
Verifying tokens
Tokens are EdDSA-signed JWTs. The public keys are published at /.well-known/jwks.json, which needs no authentication.