Skip to main content
Getting a phosra_ API key requires no pre-existing credential and no contact with the Phosra team. The entire funnel is live and self-serve:
  1. Sign up — dashboard.phosra.com/signup (WorkOS AuthKit hosted sign-up; email or SSO)
  2. Your developer org is auto-provisioned — first visit to the developer console creates it idempotently
  3. Mint your first key — from the Keys page, or in one API call (below)
Management plane, not census. This funnel — signup, orgs, phosra_ keys — is the Phosra control plane and sits outside OCSS §8.1 census scope. OCSS census verbs (rule writes, enforcement confirmations, harm-context, consent attestations) remain RFC-9421 DID-signed only: a phosra_ key or session token never authenticates a census write. For the census path, see Onboarding.

​
Path A — the console (browser)

  1. Go to dashboard.phosra.com/signup and create an account. Existing accounts sign in at dashboard.phosra.com/login.
  2. You land on the developer console. On first load the console provisions your developer organization automatically — no form to fill.
  3. Open API Keys → Create Key. Pick a name, environment (test or live), and scopes.
  4. The key is shown once — phosra_test_<64hex> or phosra_live_<64hex>. Copy it immediately; only its SHA-256 hash is stored server-side.

​
Path B — the API (curl)

Everything the console does is plain HTTP. Authentication for these management calls is your WorkOS session bearer (the access token from your signup/login session) — not a phosra_ key, which is exactly why no key is needed to get your first key.

​
One-call bootstrap

POST /api/ensure-dev-org (a dashboard BFF route) idempotently returns your org, creating it if needed — and with bootstrap_key: true also mints the org’s first phosra_ key when none exists yet: 
curl -X POST https://dashboard.phosra.com/api/ensure-dev-org \
  -H "Authorization: Bearer $WORKOS_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name": "Acme Corp", "bootstrap_key": true}'

{
  "id": "8f14e45f-…",
  "name": "Acme Corp",
  "slug": "acme-corp",
  "first_key": {
    "id": "c9f0f895-…",
    "name": "First key (bootstrap)",
    "environment": "test",
    "key": "phosra_test_4a1b2c…"
  }
}
first_key.key is returned only when the org has zero active keys — the flag never mints a second key. Save it immediately.

​
Or the raw control-plane calls

# 1. Create your developer org (WorkOS session bearer — no phosra_ key needed)
curl -X POST https://prodapi.phosra.com/api/v1/developers/orgs \
  -H "Authorization: Bearer $WORKOS_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name": "Acme Corp"}'

# 2. Mint your first key (key returned once)
curl -X POST https://prodapi.phosra.com/api/v1/developers/orgs/$ORG_ID/keys \
  -H "Authorization: Bearer $WORKOS_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name": "my-first-key", "environment": "test", "scopes": ["read:families", "write:policies"]}'

​
Verify the key works

curl https://prodapi.phosra.com/api/v1/developer/families \
  -H "Authorization: Bearer phosra_test_4a1b2c…"
A 200 with a JSON array (empty is fine for a fresh org) confirms the credential loop is closed: fresh signup → org → usable phosra_ key, with no pre-existing key anywhere in the chain.

​
Where each credential is used

CredentialIssued byAuthenticates
WorkOS session bearerSignup / login (AuthKit)Management: /developers/orgs*, keys, usage — the control plane
phosra_live_ / phosra_test_ keyConsole Keys page or POST /developers/orgs/{orgId}/keysData plane: /api/v1/developer/* routes
Ed25519 DID key (RFC-9421)Your own keypair + Trust List entry (Onboarding)OCSS census verbs — never a phosra_ key

​
Conformance

The credential loop above needs a session bearer, so the full signup → key path is not a no-credential curl. What a docs-only stranger — or the nightly docs-conformance CI — can run with no credentials is that the control-plane the funnel lands on is live and correctly auth-gated (the org-creation endpoint exists and rejects unauthenticated writes with 401, not 404): 
# 1. The control plane is live.
curl -fsS https://prodapi.phosra.com/health
# → 200 {"status":"ok"}

# 2. Org creation exists and is auth-gated (401, NOT 404 — the endpoint is real, just needs your session bearer).
curl -s -o /dev/null -w "%{http_code}\n" -X POST https://prodapi.phosra.com/api/v1/developers/orgs
# → 401
A 401 here (not 404) is the proof the self-serve funnel is real: the endpoint the console and the one-call bootstrap post to is deployed and gated — supply your WorkOS session bearer (from signup) and the same call returns your new org.

​
Further reading