Create your account & get keys

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:

Sign up — dashboard.phosra.com/signup (WorkOS AuthKit hosted sign-up; email or SSO)
Your developer org is auto-provisioned — first visit to the developer dashboard creates it idempotently
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)

Go to dashboard.phosra.com/signup and create an account. Existing accounts sign in at dashboard.phosra.com/login.
You land on the developer dashboard. On first load the dashboard provisions your developer organization automatically — no form to fill.
Open API Keys → Create Key. Pick a name, environment (test or live), and scopes.
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

Credential	Issued by	Authenticates
WorkOS session bearer	Signup / login (AuthKit)	Management: `/developers/orgs*`, keys, usage — the control plane
`phosra_live_` / `phosra_test_` key	Console Keys page or `POST /developers/orgs/{orgId}/keys`	Data 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.

Get Started

Concepts

Guides

Cookbook

Partner Integration

Phosra Link (secret-free)

OCSS Conformance

Platform

Path A — the console (browser)

Path B — the API (curl)

One-call bootstrap

Or the raw control-plane calls

Verify the key works

Where each credential is used

Conformance

Further reading

​Path A — the console (browser)

​Path B — the API (curl)

​One-call bootstrap

​Or the raw control-plane calls

​Verify the key works

​Where each credential is used

​Conformance

​Further reading

Path A — the console (browser)

Path B — the API (curl)

One-call bootstrap

Or the raw control-plane calls

Verify the key works

Where each credential is used

Conformance

Further reading