Sandbox lifecycle walkthrough

This walkthrough exercises a representative family and platform-link lifecycle entirely in the public sandbox.

Every child, provider, platform, credential, status, and receipt in this walkthrough is synthetic test data. Brand-like names such as Notflix, Pixagram, and Custo are reference fixtures. They are not customers, accredited providers, or evidence that Netflix, Xbox, or another real platform uses Phosra.

What this walkthrough demonstrates

  1. Create a synthetic family and child.
  2. Read the sandbox platform catalog.
  3. Create a test compliance link.
  4. Inspect the sandbox policy result.
  5. Create an unrelated second test link.
  6. Remove the first link.
  7. Confirm that the second sandbox record is unchanged.
  8. Re-create the first test link.

The result demonstrates API state isolation in the sandbox. It does not demonstrate downstream enforcement by a real platform, customer adoption, a production federation, or a production receipt rail.

Before you start

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

Use only synthetic data. Do not send real child profiles, family identifiers, provider credentials, or customer data to the public sandbox.

1. Create a test family

bash
curl -s -X POST "$PHOSRA_BASE/api/v1/setup/quick" \
  -H "Content-Type: application/json" \
  -d '{"family_name":"Sandbox family","child_name":"Ruby","birth_date":"2018-01-01"}'

Store the returned test identifiers for the remaining calls. A sandbox success means the evaluation environment accepted the request; it is not a production onboarding event.

2. Inspect the synthetic catalog

bash
curl -s "$PHOSRA_BASE/api/v1/platforms"

Catalog identifiers and logos are test fixtures. A recognizable identifier does not imply a commercial relationship or working adapter.

Use the compliance endpoint documented in Connect a platform with a sandbox family and synthetic platform. Treat verified or enforced fields as fixture-state labels unless the response documentation explicitly identifies the exact signature and verification context.

Create a second sandbox record with a different test platform identifier. The purpose is to establish two independent records for an isolation check, not to represent two deployed integrations.

bash
curl -i -X DELETE "$PHOSRA_BASE/api/v1/compliance/$FIRST_TEST_LINK_ID"

Read the family compliance list again. The first sandbox record should be absent or marked disconnected while the second record remains unchanged.

Repeat the sandbox create call and confirm that it returns a new test link identifier. This checks create/remove/re-create behavior within the evaluation environment.

What the screenshots mean

Any screenshots associated with this walkthrough show synthetic reference applications and sandbox fixture states. Green badges such as “verified” or “enforced” are sample UI treatments, not proof of an independently verified customer deployment. A production design must use copy that names the evidence actually checked.

Production boundary

Hosted decision routing between verified participants, broader production receipt-rail availability, additional adapters, and certification pathways remain roadmap. Teams with a concrete workflow can bring these sandbox results to the design-partner beta as pilot evidence.