Skip to main content
GET
Auth Context
Returns the auth context resolved from the current Authorization header. Used by @axon402/cli at auth login to show the operator which org an API key belongs to, and which signing mode the org runs in.

Authentication

Accepted credentials:
  • A database-backed tenant API key (axon_sk_*)
  • A platform JWT (Supabase user access token) when AXON_PLATFORM_AUTH_ENABLED=true
No request body.
The static operator key (AXON_DECISION_API_KEY) authenticates successfully, but GET /v1/me still returns 404 NOT_FOUND because that key is not bound to an organization.

Response

Fields

Signing mode resolution

organization.signing_mode is derived from the organization’s vault wallet wallet_mode:
  • wallet_mode = 'full' on the vault → signing_mode = "full" (server holds the vault private key, can allocate from vault to pockets)
  • wallet_mode = 'browser' on the vault → signing_mode = "browser" (user’s browser holds the key, vault allocation is unavailable, all funding goes via external deposit)
Clients can use this field to decide whether to show “Allocate from Vault” as an option in a UI, or to short-circuit a POST /v1/wallets/:id/fund call that would otherwise fail with VAULT_ALLOCATION_UNAVAILABLE.

Multi-org platform sessions

If the caller is using a Supabase JWT (auth_mode: "platform") and the user has memberships in more than one organization, v1 returns the first organization in the membership map. Disambiguation via a ?organization_id= query parameter is tracked as a follow-up. For deterministic multi-org operator tooling, use API keys instead — each API key is bound to exactly one organization at mint time. Check surface if you need to decide whether a credential should be routed to the runtime surface or the operator/manage surface.

Errors

  • 401 UNAUTHENTICATED / INVALID_API_KEY: missing or invalid bearer token
  • 404 NOT_FOUND: no organization is associated with the auth context, or the resolved organization no longer exists

Example: axon-op auth login flow

See also