Sandbox test values

Stripe gives you 4000 0000 0000 0002 to force a decline. This page is the same idea for Phosra: a flat table of concrete inputs that make the sandbox return a specific outcome — the happy path, a forced deny, and every error status a real integration has to handle (400, 404, 409, 429, and the tier-gated 403).

Every row was executed live against the sandbox while writing this page, and the response bytes below are pasted verbatim. Nothing here is hypothetical.

Base URL

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

No key, no signup. The sandbox is an evaluation environment seeded with the demo family (Mia, Leo, Ava) and synthetic reference providers. Every curl below runs against $SANDBOX exactly as written.

The trigger table

Scan this, copy the row you need. Each class matches the Errors reference; each links to the worked example below.

Provider connect — 200 vs the two 404s

GET /api/v1/providers/{did}/connect has three deterministic branches. This is the single most useful pair to test against, because it lets you exercise both the happy-path and not-found arms of your connect code without any auth.

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

Verbatim responses:

{
  "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"
}

{ "error": "Not Found", "message": "provider connect config not available", "code": 404, "class": "not_found" }

{ "error": "Not Found", "message": "provider not found", "code": 404, "class": "not_found" }

Allow vs force-deny — the OAuth consent branch

The reference-provider consent screen is a real, server-rendered page. It is the sandbox's allow/deny switch: the decision query parameter deterministically picks which redirect you get back, so you can drive both the granted and the user-declined paths of your connect handler.

bash
curl -s -D - -o /dev/null \
  "$SANDBOX/oauth/authorize?redirect_uri=https%3A%2F%2Fexample.com%2Fcb&state=xyz&decision=approve" \
  | grep -i '^location'
# location: https://example.com/cb?code=sbxauth_REDACTED_ONE_TIME_CODE&state=xyz

Both return 302. The state you send is echoed back on both branches, so you can verify your CSRF check on the deny path too. Custom mobile redirect schemes (e.g. propagate://cb) are allowed — this is the same surface the Propagate iOS parent flow drives.

Self-register — 409 and the two 400s

POST /api/v1/advisors/self-register is the fastest way to a deterministic 409: send a DID that is already on the Trust List. The seeded did:ocss:loopline is always present, so this reproduces with zero setup.

# 409 — did:ocss:loopline is already on the sandbox Trust List
curl -s -X POST "$SANDBOX/api/v1/advisors/self-register" \
  -H "Content-Type: application/json" \
  -d '{"did":"did:ocss:loopline","public_key_b64url":"1NDtvUgkYV6h6XzR3y-FgAdKmqQ-i7XiWen7joyJYgA"}'

{ "error": "Conflict", "message": "did_already_registered: this DID is already on the trust list; self-register cannot overwrite existing entries", "code": 409 }

The two validation 400s:

bash
curl -s -X POST "$SANDBOX/api/v1/advisors/self-register" \
  -H "Content-Type: application/json" -d '{}'
# {"error":"Bad Request","message":"did is required","code":400}

POST /setup/quick — two clean 400s

setup/quick cleanly validates both a missing name and a malformed date — both are caller errors, and both return 400, never a 500.

bash
curl -s -X POST "$SANDBOX/api/v1/setup/quick" \
  -H "Content-Type: application/json" \
  -d '{"birth_date":"2016-03-15"}'
# {"error":"Bad Request","message":"child_name is required","code":400}

401 — every signed endpoint without a signature

The write endpoints (/enforcement-endpoints, /harm-context, /policies/{id}/rules, /platforms/{did}/endpoints, the sandbox consent-attestation mint) require an RFC 9421 signature. Calling any of them with no Signature header is a deterministic 401 — useful for asserting your client attaches one before it ships.

curl -s -X POST "$SANDBOX/api/v1/enforcement-endpoints" \
  -H "Content-Type: application/json" -d '{}'

{ "error": "Unauthorized", "message": "exactly one Signature-Input and one Signature header are required", "code": 401, "class": "signature_invalid" }

429 — the rate limit is real

Every metered response — reads included — carries live rate-limit headers, and the limit does trip. The product surface under /api/v1/* shares one window; a GET /api/v1/platforms costs the same as a POST. Unmetered by design: /health, the /.well-known/ocss/* discovery reads (Trust List, succession record), the Annex B editions read (GET /api/v1/annex-b/editions/{n}), the sandbox /oauth/* consent surface, and the signed census safety paths (enforcement endpoints, confirmations, harm-context — deliberately never rate-gated, the fail-open invariant) — so hammer those freely.

A healthy response, mid-window:

x-ratelimit-limit: 100
x-ratelimit-remaining: 52
x-ratelimit-reset: 1783342740

Exhaust the window (> 100 /api/v1/* calls from one caller) and the next call is a 429:

HTTP/2 429
retry-after: 60
x-ratelimit-limit: 100
x-ratelimit-remaining: 0
x-ratelimit-reset: 1783342740
 
Too Many Requests

The correct handler reads Retry-After (or X-RateLimit-Reset), sleeps, and retries once — see the backoff recipe. A 429 is the only error on this page worth retrying automatically; the 4xxs are deterministic and a blind retry returns the same result.

403 — the tier gate (signed requests only)

A 403 is the one outcome you cannot reach with a bare curl, and we call that out rather than fake it: it means the request was cryptographically valid but not authorized. The canonical trigger is a provisional-tier DID (what self-register gives you) signing a rule write whose enforcement band its tier cannot reach:

• Input: a valid RFC 9421 signature from a provisional DID, writing a Restricted-band rule to POST /policies/{id}/rules.
• Outcome: 403, class: standing_failure, failed_step: band_exceeds_tier.

A forged or mismatched consent:attestation standing produces the sibling 403 scope_failure. Both are fully specified — with the exact failed_step values — in Errors › 403 standing and scope. To raise your tier from provisional to another fixture value is not a production governance decision. See the design-partner and production roadmap.

Reset & repeatability

The sandbox has no destructive reset button. Two levers keep your test runs clean:

Details and worked examples: Sandbox test data › Reset and idempotency.

Now build something