HALO uses separate credentials for resource spending, public project configuration, end-user authorization, and project administration. Choose by API surface instead of passing one universal token everywhere.
#Credential matrix
| Credential | Example | API surfaces |
|---|---|---|
| Client API key | sk-… | Model Gateway, Memory |
| Publishable key | apikey: … | Public Project Authentication |
| Project user access | apikey + Bearer eyJ… | Current user and logout; bearer-only OAuth consent |
| OAuth App access | Bearer eyJ… | OAuth userinfo and service scopes |
| Dashboard owner JWT | Bearer … | Project configuration and management |
#HALO client key
Keys beginning with sk- authorize billable gateway and Memory calls. They must remain in a trusted runtime.
#Project publishable key
Send it in apikey orx-halo-project-key. Navigation to a provider authorize endpoint may carry ?apikey= because a browser redirect cannot add a custom header. The key is public application identity, equivalent to a Supabase publishable key; it is not a client secret.
#Project user bearer token
The RS256 access token represents one Authentication user and one session. Current-user and logout calls must include both this bearer token and the matching Project publishable key. Verify it with the project JWKS and required claims. Do not use it as a model-spending key.
#Dashboard owner JWT
Owner routes live below /api/user. The backend verifies project ownership before allowing Authentication configuration, user administration, session revocation, API key management, or registry mutation.