The starter below runs against the open sandbox with synthetic data. Repository and package links
identify developer artifacts only; no sample or reference application is evidence of customer
adoption, accreditation, certification, or a production federation.
How to read this page. We are explicit about what each sample is, because a dead link or a
404 on npm install costs a developer all their trust:
Runnable starter — a copy-paste snippet (not a repo) you can paste into a terminal right now.
It runs against https://phosra-api-sandbox-production.up.railway.app with no credential. Every
response shown is verbatim from that live sandbox.
Clonable repo — a public GitHub repository you can git clone. We link only repos that
actually exist (verified against the GitHub API while writing this page).
Published package — on the public npm registry. Versions are verified against npm view;
pin the one you use.
Private / on-request — the native iOS & Android enforcement SDKs are distributed privately.
We say so plainly and give you the contact, rather than show an install line that would 404.
Synthetic reference applications
Custo, Notflix, Bloxby, Snaptr, and Pixagram are test fixtures used to exercise UI and protocol
shapes. They are not real providers or platforms, public customer deployments, accredited
participants, or production traffic. Screenshots and traces from those fixtures are internal
evaluation evidence only.
The 60-second starter
This is the smallest complete integration: mint nothing, create a protected child, enforce the
policy, and read the result — the same four moves every Phosra integration makes. It is a
snippet, not a clonable repo. It needs no API key because it targets the open sandbox.
1
Prove the sandbox is up
2
Create a family + child + active policy in one call
3
Enforce the policy (async job)
4
Poll the job to completion
bash
# A complete, runnable integration — paste the whole block into a terminal.# No API key: this targets the open partner sandbox.HOST="https://phosra-api-sandbox-production.up.railway.app"BASE="$HOST/api/v1"# 1 — health check (no key)curl -s "$HOST/health" # → {"status":"ok"}# 2 — create a protected child; capture the child idCHILD_ID=$(curl -s -X POST "$BASE/setup/quick" \ -H "Content-Type: application/json" \ -d '{"child_name":"Aria","birth_date":"2015-08-20","strictness":"recommended"}' \ | jq -r '.child.id')echo "child: $CHILD_ID"# 3 — enforce → returns a job (status "running")JOB_ID=$(curl -s -X POST "$BASE/children/$CHILD_ID/enforce" | jq -r '.id')echo "job: $JOB_ID"# 4 — poll the job until it is "completed"curl -s "$BASE/enforcement/jobs/$JOB_ID" | jq '{status, completed_at}'
Verbatim sandbox output (captured while writing this page — setup/quick returns 200, the
enforce job flips to completed in well under a second):
jsonc
// POST /setup/quick — trimmed to the fields the starter reads{ "family": { "id": "ecf280b3-b684-4945-a694-18a4f566a450", "name": "Aria's Family" }, "child": { "id": "ef0ca46d-411e-4801-9a5d-a05dd599c093", "name": "Aria", "birth_date": "2015-08-20T00:00:00Z" }, "policy": { "id": "fe8203da-00d5-45b9-bfa9-76f3f3227bdd", "name": "Aria's Protection Policy", "status": "active" }, "rules": [ /* 20 age-appropriate rules, enabled */ ]}// POST /children/{id}/enforce — the async job, immediately after the call{ "id": "0eb048ce-497c-4193-ba32-5dc9a0894954", "status": "running", "trigger_type": "manual" }// GET /enforcement/jobs/{id} — after polling{ "id": "0eb048ce-497c-4193-ba32-5dc9a0894954", "status": "completed", "completed_at": "2026-07-06T11:22:04.645214Z" }
Add the sandbox webhook leg. The starter stops at "start simulation + read result." Register a
test webhook to exercise delivery and signature-verification code. The handler examples live in
Webhook events → Verifying signatures.
What the starter models in a reference app
The screens below are reference UI built over synthetic sandbox state. They demonstrate product
copy and state transitions, not real platform enforcement or customer use.
setup/quick, rendered for a human: a family with a child and a starter policy. The same call the starter's step 2 makes.
The link ceremony — the app-side equivalent of pushing a policy to a platform. It states, up front, exactly which rules the platform will apply and confirm before anything turns green.
A reference success state for a verified test signature. This screenshot is not evidence of production enforcement.
Want the full ten-phase lifecycle — link, unlink, per-service isolation, relink — with every request
and response run live? See the End-to-end walkthrough.
The catalog
Public evaluation code you can inspect or clone:
The public Phosra-Inc GitHub organization — the two example repositories in the catalog below are real and clonable. Captured from github.com.
No @ocss/* scope exists. The open standard's library ships under @openchildsafety/*, and
the Phosra client libraries under @phosra/*. If you see an @ocss/… install line anywhere, it
is wrong — it will 404 on npm.
Private / on-request
The native on-device enforcement SDKs are not on a public registry yet — we distribute them
privately rather than show an install line that would fail.
The iOS Link kit (phosra-link-kit-ios) —
the Connect sheet — is public and in the catalog above. The separate iOS enforcement SDK (the
one that drives FamilyControls / ManagedSettings on-device) is the private one.
Reference provider integrations
The sandbox ships a built-in synthetic reference provider that powers the OAuth consent page you meet
in the Connect a platform guide and the
sandbox walkthrough. It exposes test /oauth/authorize,
/oauth/token, and /oauth/profiles endpoints with fixed demo child profiles (Mia, Leo, Ava), so
you can drive a complete connect ceremony against the sandbox without standing up your own provider.
The brand names in walkthrough screenshots are stand-in labels. They do not identify real
integrations, customers, or independently accredited providers.
