Skip to main content

​
Build child-safety enforcement in minutes

Phosra is the accredited developer platform for the Open Child Safety Specification (OCSS). Sign up, mint a phosra_ test key, and make your first authenticated call before your coffee gets cold — no sales call, no gated waitlist.

Get your API keys — 5 min

Sign up → your dev org auto-provisions → copy a phosra_test_ key. Self-serve, no email to anyone.

Quickstart — first call in 5 min

Zero to an enforced policy against the live sandbox — no key, copy-paste in curl / JS / Python / Go.

Not sure which surface you need? Choose your integration path

One screen mapping your goal → the right path across all five surfaces (@phosra/link, @phosra/gatekeeper, direct REST, the MCP server, and the OCSS protocol SDK) — each with its effort and a “start here” link.

New here? Read the architecture overview first — 5 min

How the pieces fit: the Phosra control plane vs the enforcement data plane vs the open OCSS protocol — one diagram, one mental model, before you write any code.

Prefer to start from a sample? Example apps & starters

A runnable end-to-end starter (no key) plus every real, clonable example repo and published package — the catalog.

​
Start where you are

I'm a Platform

An app, OS, router, or school network that enforces age-appropriate rules. Fetch a signed profile and enforce locally.

I'm a Provider

A parental-control or safety vendor that issues rules and consent on a family’s behalf.

I just want the protocol

Signed receipts, sealed envelopes, the Trust List — the vendor-neutral OCSS surface, no Phosra account.

​
Your first API call

The control plane is live right now. Neither call needs a key: the first proves the host is up, and the second proves the org endpoint is real — 401, not 404, is the correct answer without your session bearer.
Ready for a real key? Create your account & get keys →

​
How Phosra relates to OCSS

Phosra is an accredited provider on the Open Child Safety Specification (OCSS) — the open standard for age-appropriate access control. Phosra implements OCSS; it does not own it. The relationship is the same as Yubico shipping a FIDO2-conformant authentication key: Yubico implements FIDO2; the FIDO Alliance owns the standard. Phosra implements OCSS; the OCSS stewardship body owns the standard. The consequence for every API call, receipt, and SDK import in this documentation: the protocol signing and verification primitives are not Phosra code — they are the open OCSS library, @openchildsafety/ocss, re-exported without modification.
Reading these docs programmatically? Fetch /llms.txt for the index, /llms-full.txt for the full corpus, or append .md to any page URL (e.g. /integration/overview.md) for raw markdown — the rendered HTML pages are a JS app and do not return content to non-browser fetchers. See AI tools & agent ingestion for the full list of machine-readable endpoints.

​
Two halves

Every surface in this documentation belongs to one of two clearly-separated halves.

​
The Phosra control plane

Management operations over the Phosra platform: create developer orgs, provision and revoke phosra_-prefixed API keys, register and consult advisor agents, declare OCSS payload keys for federation, mint and revoke MCP tokens, and pull hourly usage rollups. All management operations use standard HTTP Bearer authentication. This is the Phosra-specific surface. Platform overview →

​
The OCSS protocol

The open protocol surface: signed write receipts, sealed envelopes, the Trust List, the succession record, and the 123-category rule vocabulary — all sourced from @openchildsafety/ocss, the vendor-neutral OCSS reference library. Phosra adds zero cryptographic logic here. Install public @openchildsafety/ocss directly. If you later integrate a different OCSS-conformant provider, this surface is identical across implementations. OCSS overview →

​
What is live today

Live now — no account required:
  • The OCSS Trust List, served at /.well-known/ocss/trust-list — validly signed against the production root key root-prod-bootstrap-2026-07, public X 824vsCATBxyUiA-znpGx01N48NNs_3gPE3M7f7vIEaI. Pin the public X, not the key id. Production carries real accreditation entries added through OCSS governance, and the count grows — assert on the root signature and each entry’s tier, never on the total. No test or sandbox keys are present in production. An older root id, root-prod-2026-06, belonged to a census that has since been retired — verifying against it fails closed on every current document, and a validly signed empty list under that id means you are talking to the dead host.
  • The Ed25519-signed succession record, served at /.well-known/ocss/succession — the steward-of-record and anti-capture covenant in machine-checkable form.
Live now — auth-gated:
  • The self-serve developer funnel: sign up → your developer org is auto-provisioned → mint your first phosra_ key from the developer dashboard or one API call. No pre-existing key, no handshake, no email to anyone. See Create your account & get keys.
  • The Phosra control-plane management API at https://prodapi.phosra.com/api/v1. Org and key management authenticates with your WorkOS session bearer (from signup/login); the /developer/* data-plane routes take the phosra_ API key you mint. Covers orgs, API keys, usage, advisor agents, and MCP tokens.
Live on npm:
  • The golden SDKs are published and public: @phosra/link, @phosra/gatekeeper, and @openchildsafety/ocss. Install them unpinned — npm install @phosra/link @phosra/gatekeeper — so you get the current generation. Pinning an older minor will not export the APIs these docs teach.
  • @phosra/gatekeeper@0.8.68 adds GET /api/phosra/status, which names the exact outstanding precondition behind an opaque 503 PHOSRA_NOT_READY instead of leaving you to guess. If your deployment declares ^0.6.0, npm will not resolve it — a caret on a 0.x version pins the minor. See the readiness contract.
  • Also published: @phosra/sdk@0.1.0, @phosra/mcp@0.4.0, @phosra/cli@0.2.0, @openchildsafety/bundle@0.1.0, @phosra/connect@0.2.0.
Live, but operator-gated:
  • The production signed environment manifest, trust material, and client-directory lookup are live and public on https://prodapi.phosra.com. Environment-bound credential issuance is still a restricted operator workflow, not public self-service — see what you cannot self-serve yet below before you start building, and Getting a Link credential for the exact fields to send and where.
Preview — committed shape, not yet deployed:
  • The unified @phosra/sdk-dev wrapper (which will re-export the individual packages above) is not yet published — install them individually today.
Each page in this documentation labels its live-vs-preview status explicitly. No endpoint is implied live unless marked as such.

​
What you cannot self-serve yet

Read this before you start building, so you know where the road currently ends. The answer depends on which census you are talking to. That is the single most important thing on this page, and older versions of it did not say so. Signing up, provisioning a developer org, and minting a phosra_ API key are instant and self-serve everywhere. Past that point the gates differ per environment: Two clarifications, one of them in the developer’s favour:
  • A self-serve credential lane exists, and the real gate is accreditation, not an operator. Where it is deployed, POST /developers/orgs/{orgId}/link/credentials refuses with “the Link authority will not issue for tier provisional: a credential requires an accredited Trust List entry”. So the thing to pursue is accreditation, not a request for someone to hand you a credential. Link client registration is likewise not inherently operator-only — a self-serve lane exists that derives the subject DID from your org’s verified claim, so no super-admin is involved.
  • The census’s own POST /api/v1/accreditation/applications is not a self-serve submit lane. Verified 2026-07-27: on prodapi.phosra.com it answers 401 {"message":"invalid or missing X-Onboard-Key"}, and X-Onboard-Key is an operator secret. On the partner sandbox the path does not exist (404). An earlier version of this table said the endpoint was live and self-serve to submit; it is not. Apply through Production Accreditation instead.
The self-serve credential lane and the client-registration lane — plus the one-call POST /developers/orgs/{orgId}/apps funnel that runs the whole ceremony (keypair → DID → claim → Trust List entry → Link client → credential) — are live and verified on the Phosra-internal staging sandbox census only (phosra-api-sandbox-staging.up.railway.app). They are absent from the partner sandbox, which answers all three with plain-text 404 page not found.On the production census they are not reachable either. Its /developers/* prefix answers 401 for real and bogus paths alike (the auth middleware runs before route matching), so registration cannot be probed directly — but its deployed build is provably older than the funnel: its POST /advisors/self-register still returns the pre-funnel gate message “gated to sandbox censuses (SANDBOX_MODE=true)”, whereas the build that added these lanes returns “gated to censuses that opted in (SANDBOX_MODE=true, or PHOSRA_SELF_SERVE_FUNNEL …)”.Do not build against them yet. They are documented here so you know the shape of what is coming, not as a capability you can call today. Re-verified by execution 2026-07-27: on the staging sandbox census POST …/orgs/{id}/apps answers 403 not a member of this organization while a deliberately bogus sibling path answers 404 page not found — a real route-existence discriminator. On phosra-api-sandbox-production.up.railway.app and sandbox.phosra.com, both answer 404. On prodapi.phosra.com, both answer 401, which is why the route’s absence there had to be established from the deployed build rather than by probing.The funnel’s request and response shapes are now documented in full, from that live staging run — see Create an app — the one call. Building the shape now is safe; calling it in production is not yet possible.
What this means practically on the hosts you may use: you can install the SDKs, read the protocol surface, verify the Trust List and succession record, submit a production accreditation application, and build against the shapes documented here. On a sandbox census a provisional DID can already write Open-band rules; Gated and Restricted categories need a higher tier. A production rule write still needs accreditation. What you cannot do yet is mint your own PHOSRA_CREDENTIAL — that request goes to developers@phosra.com with the fields listed under Getting a Link credential. Treat this section as the honest boundary of self-service. We are actively removing these gates. This section will shrink as each one lands; if it is still here, the gate is still there.

​
There is no hosted decision endpoint — by design

Enforcement decisions are made locally. @phosra/gatekeeper fetches the signed enforcement profile from the census once (or on a polling interval) via the §9.3(b) read (GET /api/v1/enforcement-profiles/{endpoint_id}), verifies the router’s Ed25519 signature to root in-process, and then isAllowed({ category, signal }) evaluates every subsequent enforcement call against the cached, signed profile — zero network calls, zero latency, fail-closed when the profile is absent. isAllowed() IS the decision call. There is no POST /v1/check endpoint and none is planned: a hosted decision call would add per-decision latency, put a network dependency on the enforcement hot path, and break the fail-closed guarantee when the census is unreachable.

​
Base URL

All Phosra control-plane management requests use this base URL — in production, the control plane, the data plane, and the OCSS census are the same host. To build without a key, point at the open partner sandbox instead: https://phosra-api-sandbox-production.up.railway.app/api/v1. That base URL is for the REST/product API. @phosra/link and @phosra/gatekeeper take no base URL at all — they read the census, the trust root, and the environment out of your PHOSRA_CREDENTIAL. For the full table of every environment × base URL, which census serves which Link lane, phosra_test_ vs phosra_live_ semantics, how test data is isolated, and how to point each SDK at an environment, see Environments & base URLs.

​
The standard lives at openchildsafety.org

The OCSS specification, 123-category rule registry, and conformance suite are published at openchildsafety.org — not here. (openchildsafety.com now 308-redirects there. A browser follows it; a curl -X POST without -L does not, so use the .org name in scripts.) Phosra does not host, own, or gatekeep the standard. That separation is the asset: a standard you cannot capture is one you can build on.