Sandbox test data

This is the single page to keep open while you build against the sandbox — the equivalent of Stripe's test cards or Plaid's sandbox credentials. Everything here is a fixed, seeded value you can hard-code in a test: the demo children, the connectable reference providers, the 22 reference platforms, the exact POST /setup/quick shape, the connect scopes, and the rules that govern resets and retries.

Every value on this page was captured live from the sandbox while writing it. For a guided, step-by-step tour of the same sandbox (health, the signed Trust List, self-registering a DID), read Test in the sandbox; this page is the flat lookup table.

Base URL

export PHOSRA_SANDBOX="https://phosra-api-sandbox-production.up.railway.app"

The cheat sheet

Everything fixed in the sandbox, in one scan. Each row links to its section below.

Demo child profiles

The sandbox is seeded with one demo family — Mia, Leo, and Ava — each with an active policy already in place. These are the profiles the connect ceremony shares, and their subject_ref values are stable across every sandbox reset, so you can hard-code them in tests.

You retrieve them by completing the reference-provider OAuth flow, exactly as a real Connect integration would. The /oauth/profiles leg returns them as a bare ChildProfile[]:

# 1. Approve the sandbox consent screen → get an authorization code
CODE=$(curl -s -D - -o /dev/null \
  "$PHOSRA_SANDBOX/oauth/authorize?redirect_uri=https%3A%2F%2Fexample.com%2Fcb&state=xyz&decision=approve" \
  | grep -i '^location' | sed -E 's/.*code=([^&]+).*/\1/' | tr -d '\r')
 
# 2. Exchange the code for an access token
TOKEN=$(curl -s -X POST "$PHOSRA_SANDBOX/oauth/token" \
  -H "Content-Type: application/json" \
  -d "{\"grant_type\":\"authorization_code\",\"code\":\"$CODE\"}" \
  | python3 -c "import sys,json;print(json.load(sys.stdin)['access_token'])")
 
# 3. List the connected child profiles
curl -s "$PHOSRA_SANDBOX/oauth/profiles" -H "Authorization: Bearer $TOKEN"

Live response (200 OK):

[
  { "id": "mia", "displayName": "Mia", "subject_ref": "a11ce0fa-0000-4000-8000-0000000000a1", "kind": "child" },
  { "id": "leo", "displayName": "Leo", "subject_ref": "a11ce0fa-0000-4000-8000-0000000000a2", "kind": "child" },
  { "id": "ava", "displayName": "Ava", "subject_ref": "a11ce0fa-0000-4000-8000-0000000000a3", "kind": "child" }
]

Reference providers

Providers live on the signed Trust List. Two are wired for the full connect ceremony and give you the two branches you need to test:

curl -s "$PHOSRA_SANDBOX/api/v1/providers/did:ocss:loopline/connect"

Live response (200 OK):

{
  "authorize_url": "https://phosra-api-sandbox-production.up.railway.app/oauth/authorize",
  "token_url": "https://phosra-api-sandbox-production.up.railway.app/oauth/token",
  "profiles_url": "https://phosra-api-sandbox-production.up.railway.app/oauth/profiles",
  "scopes": ["child_profiles.read"],
  "name": "Loopline"
}

The Trust List holds many more verified reference entities you can discover and verify signatures against — did:ocss:aura, did:ocss:brightcanary, did:ocss:murmur, did:ocss:beacon, did:ocss:household-acme, and more — plus a growing set of provisional entries added by self-registration. Because self-registration is open, treat the total entry count as a live number: verify each entry's signature and tier rather than asserting on the total. See Test in the sandbox for the signed-document shape and how to self-register your own DID.

Reference platforms

GET /api/v1/platforms returns the 22 enforcement targets the sandbox can fan a policy out to, grouped by category. Use any platform_id when connecting a platform or reading discovery results.

curl -s "$PHOSRA_SANDBOX/api/v1/platforms"

POST /setup/quick

The fastest path to a working policy. Hand it a child's name, birth date, and a strictness level; it creates a family, a child, an active policy, and a full set of age-appropriate rules — derived from the birth date, in one call, no follow-ups.

bash
curl -s -X POST "$PHOSRA_SANDBOX/api/v1/setup/quick" \
  -H "Content-Type: application/json" \
  -d '{
    "child_name": "Emma",
    "birth_date": "2016-03-15",
    "strictness": "recommended"
  }'

Request fields

Response shape (201 Created)

Trimmed to the top-level shape — the live rules array carries all 20 entries:

{
  "family": { "id": "c479c437-…", "name": "Emma's Family" },
  "child":  { "id": "bb3821b0-…", "name": "Emma", "birth_date": "2016-03-15T00:00:00Z" },
  "policy": { "id": "5ccaad2f-…", "name": "Emma's Protection Policy", "status": "active" },
  "rules":  [ /* 20 age-appropriate rules */ ],
  "age_group": "preteen",
  "max_ratings": { "csm": "10+", "esrb": "E10+", "mpaa": "PG", "pegi": "7", "tvpg": "TV-PG" },
  "rule_summary": {
    "screen_time_minutes": 120,
    "bedtime_hour": 21,
    "web_filter_level": "moderate",
    "content_rating": "PG",
    "total_rules_enabled": 20
  }
}

Connect and token scopes

The reference-provider OAuth flow uses two scope strings:

The token response is a standard bearer grant:

{ "access_token": "sbxtok_…", "token_type": "Bearer", "expires_in": 3600, "scope": "profiles" }

Reset and idempotency

The sandbox has no destructive "reset" button — instead it gives you two levers so your tests stay clean and repeatable:

Deterministic per-caller data (X-Sandbox-Session). Pass an X-Sandbox-Session: <any-string> header and the sandbox keys all your data to a stable sandbox user for that session. Reuse the same value across a test run to accumulate against one caller; use a fresh value to start from a clean slate. Omit it and you share the default session.

curl -s -X POST "$PHOSRA_SANDBOX/api/v1/setup/quick" \
  -H "Content-Type: application/json" \
  -H "X-Sandbox-Session: my-test-run-42" \
  -d '{"child_name":"Nora","birth_date":"2015-05-01","strictness":"strict"}'

Idempotent retries (family_id). POST /setup/quick deduplicates on (family_id, child_name, birth_date). A repeat call that passes the family_id from a previous response — with the same child name and birth date — returns the same child and policy rather than minting a duplicate. This makes the endpoint safe to retry after a network failure, and it repairs a half-created child from an interrupted first attempt.

# First call — creates family + child; capture the family id
FID=$(curl -s -X POST "$PHOSRA_SANDBOX/api/v1/setup/quick" \
  -H "Content-Type: application/json" \
  -d '{"child_name":"Nora","birth_date":"2015-05-01","strictness":"strict"}' \
  | python3 -c "import sys,json;print(json.load(sys.stdin)['family']['id'])")
 
# Retry with family_id — returns the SAME child id, not a duplicate
curl -s -X POST "$PHOSRA_SANDBOX/api/v1/setup/quick" \
  -H "Content-Type: application/json" \
  -d "{\"family_id\":\"$FID\",\"child_name\":\"Nora\",\"birth_date\":\"2015-05-01\",\"strictness\":\"strict\"}"

Moving beyond sandbox evaluation

Nothing you do in the sandbox touches a real family. Control-plane API keys can be evaluated separately, but there is no public production OCSS census to substitute for the sandbox today.

1. 1
   Separate product API from OCSS routing

   Use only documented control-plane endpoints with the documented credential type. Keep OCSS routing evaluation in the sandbox; hosted routing remains roadmap.

2. 2
   Define a bounded pilot

   Record the workflow, data boundary, success criteria, and rollback path before applying for the design-partner beta.

3. 3
   Keep synthetic DIDs isolated

   The reference providers (did:ocss:loopline, …) and demo children are sandbox fixtures. They are not accredited organizations and must not be treated as a production migration path.