Skip to main content
Go from nothing to a live, age-appropriate safety policy in under five minutes. Every request on this page runs against the public Phosra sandbox — open, seeded, and safe. No signup, no API key, nothing to install beyond the language you already use. Copy a block, paste it in your terminal, run it. Then swap one base URL and add a key to go to production.
Sandbox-first. The partner sandbox lives at https://phosra-api-sandbox-production.up.railway.app/api/v1. Nothing you create there ever touches a real family or production data. /setup/quick and the other routes below are keyless in the sandbox; in production the same routes authenticate the signed-in parent via a WorkOS session JWT, not a phosra_ developer key — see Go to production below. Every response quoted below is verbatim output from that live sandbox, not an illustration.

Before you start

You need exactly one thing: a terminal. There is nothing to sign up for to run this page.
Set the base URL once so every step below is copy-paste:

Step 1 — Create a protected child in one call

POST /setup/quick is the fastest path to a working policy. Hand it a child’s name, birth date, and a strictness level; it returns a family, a child, an active policy, and a full set of age-appropriate rules — derived from the birth date, with no follow-up calls.
Live sandbox response (trimmed — verbatim, 200 OK):
strictness is one of "strict", "recommended", or "relaxed". The age band and every rule default come from birth_date — a 2016-03-15 birthday resolves to a preteen policy with 20 rules enabled. See Strictness levels.

Step 2 — See what you can enforce against

A policy does nothing until it is pushed to a platform. List the platforms the sandbox supports and note each one’s enforcement_mode. The value is one of dns, device, or manual_attested: dns and device platforms apply rules programmatically (a live DNS-provider write, or on-device via the Phosra app), while manual_attested platforms return guided parent steps for the parent to attest. See Platforms & enforcement modes.
The sandbox returns 22 platforms, including android, apple, microsoft, controld, cleanbrowsing, fire_tablet, fire_tv, xbox, playstation, and nintendo. Each entry carries its capabilities (e.g. time_limit, web_filtering, content_rating) and its enforcement_mode.

Step 3 — Enforce, then read the result

Push the policy for a child. Enforcement is asynchronous: the call returns a job (202 Accepted) that you poll until it is completed.
Live sandbox responses (verbatim):
That’s the full loop: create → target → enforce → confirm, all against a live census, in four requests and about a minute of wall-clock. No account, no key, no SDK.

Optional — your own signed identity on the census

The steps above use Phosra’s product-plane convenience routes. The OCSS census itself — signed rule writes, consent attestations, enforcement receipts — authenticates every write with an RFC 9421 DID signature, never a bearer key. You can get a working identity on the live Trust List, and make your first authenticated call, without leaving the sandbox.
1

Register a sandbox identity

Generate an Ed25519 key and self-register its DID. The sandbox mints you a provisional Trust-List entry immediately — no review, no email.
(POST /advisors/register still works but is deprecated — it forwards to self-register. Use self-register in new code.)Live response (200 OK):
Your DID appears on the live Trust List the same instant — confirm it:
2

Make your first authenticated (signed) call

Census writes must carry an RFC 9421 signature. The @phosra/link SDK signs locally for you — here it mints a sandbox consent attestation as the identity you just registered.
Live response (201 Created) — a real, signed census write:
Send the same request without a signature and the census refuses it — proof the authentication is real, not decorative:
The full writer-plane ceremony — consent, directives, platform binding — is documented in the @phosra/link guide and the Onboarding walkthrough.

Go to production

The base URL changes, and so does the auth model. /setup/quick, /platforms, and /children/{id}/enforce are consumer routes — keyless in the sandbox, and gated by a signed-in parent’s WorkOS session JWT in production. A phosra_ developer key sent to these routes in production returns 401, not success.
Phosra developer account signup screen with Google and Microsoft SSO, email and password fields, and a Create account button

Self-serve signup at dashboard.phosra.com — email or SSO, no sales call, no waitlist.

1. Swap the base URL

https://phosra-api-sandbox-production.up.railway.app/api/v1https://prodapi.phosra.com/api/v1 — full matrix on Environments.

2. Sign the request as your user

Send Authorization: Bearer <workos_access_token> from your app’s already-signed-in parent session (the same WorkOS AuthKit session your web/iOS/Android client holds after login) — no developer key involved on these routes.
Two planes, one mental model. Consumer routes (/setup/quick, /families, /children, …) authenticate the signed-in parent — a WorkOS JWT in production, keyless in the sandbox. The phosra_ bearer key is for server-to-server integrations instead: Phosra management calls (orgs, keys, usage) and the /developer/*-prefixed twin of the data plane. There is no /developer/setup/quick — a developer-key integration builds the same graph from /developer/families, /developer/children, and /developer/policies. OCSS census writes (rule writes, consent, enforcement receipts) authenticate with a DID signature, never a bearer key — see Authentication for the full split.

Next steps

Create your account & get keys

The self-serve funnel from zero to a phosra_test_ key.

Authentication

Bearer keys vs. DID signatures — when each applies, and why.

Errors

Every error code and class the API can return, documented.

Platform integration

Fetch a signed enforcement profile and enforce it locally.

Example apps & starters

A runnable end-to-end starter plus every real, clonable example repo and package.

AI tools & agent ingestion

Machine-readable docs: llms.txt, per-page markdown, and the OpenAPI specs for agents.