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 |
|---|---|---|
| Project secret API key | sk-… | Model Gateway, Memory, and Agent Access partner /projects routes; trusted backend only |
| Project publishable key | apikey: halo_pk_… | Project Authentication signup, login, and public configuration |
| Project user JWT | apikey + Bearer eyJ… | Project Authentication current user/logout; bearer-only Identity OAuth consent; project_auth end-user proof in an Agent Access Link request |
| Identity OAuth Client access | Bearer eyJ… | Project OAuth userinfo and approved identity scopes |
| HALO platform owner JWT | Bearer … | Project administration and the signed-in owner's Access Identity verification, consent, approvals, and revocation |
#Project secret API key
Keys beginning with sk- authorize billable gateway and Memory calls. Agent Access partner routes under/api/v1/agent-access/projects/:projectKey accept the matching Project key in Authorization: Bearer sk-… orx-api-key. Keep these keys in your backend; the user's browser opens the returned Link URL instead.
#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. A backend using HALO Project Authentication may pass this token as endUser.accessTokenwith endUser.type: "project_auth"when creating an Agent Access Link Session. It identifies the application's user; it does not authorize that user's external accounts or replace the HALO platform JWT used for Access Identity consent.
#HALO platform owner JWT
HALO platform sign-in issues this token separately from Project Authentication signup and login. Owner administration routes live below /api/user. The backend verifies project ownership before allowing Authentication configuration, user administration, session revocation, API key management, or registry mutation. Access Identity routes under/api/v1/agent-accessuse the signed-in HALO owner's token to verify their identity, record consent, approve executions, and revoke access.
See the Agent Access integrationfor the partner-to-user handoff andconsent-based same-email linkingfor optional external-user association. Application signup and Identity OAuth consent do not create Agent Tool grants.