Choose your integration path

There are five ways to integrate with Phosra. They are not tiers of the same product — each one exists for a different job. Pick the row that matches what you are building; every path has a copy-paste quickstart that runs against the live sandbox with no account.

This page replaces reading Architecture, Partner Integration Overview, and SDK Overview end-to-end just to figure out where to begin.

Start with one question

What are you doing with child-safety rules?

The five paths at a glance

How the paths relate

Most of the paths are complementary, not alternatives. The target architecture may combine two:

• A Provider app (@phosra/link) writes rules → a future hosted router distributes them → a Platform (@phosra/gatekeeper) enforces them. The public sandbox models this flow with synthetic parties.
• Direct REST and the MCP server are two different front doors to the same control-plane API. Pick REST for code, MCP for agents.
• The OCSS protocol SDK sits underneath both @phosra/link and @phosra/gatekeeper — they re-export its signing and verification primitives. Use it directly only if you want the raw protocol with no Phosra-specific helpers.

flowchart LR
  P["Provider app<br/>@phosra/link"] -->|writes signed rules| C["Target hosted router<br/>(roadmap)"]
  C -->|distributes signed profile| G["Platform<br/>@phosra/gatekeeper"]
  R["Direct REST / MCP"] -.->|manage families & policies| C
  O["@openchildsafety/ocss<br/>(crypto primitives)"] -.->|sign / verify| P
  O -.->|sign / verify| G

Not sure yet? Try the fastest path first

The Direct REST path returns a sandbox 201 in one call with no account and no key. Run it to create a disposable synthetic family, child, policy, and rules, then decide which SDK to evaluate:

curl -X POST https://phosra-api-sandbox-production.up.railway.app/api/v1/setup/quick \
  -H "Content-Type: application/json" \
  -d '{"child_name":"Emma","birth_date":"2016-03-15","strictness":"recommended"}'

Real response from the sandbox (trimmed):

{
  "family": { "id": "7e1e2a77-1c5c-436d-9fc7-0d3b5bf4fc90", "name": "Emma's Family" },
  "child":  { "id": "65e1f14f-9d0a-491c-9108-bd6223a59778", "name": "Emma", "birth_date": "2016-03-15T00:00:00Z" },
  "policy": { "id": "8fd80f2d-6c29-4dcb-bcd1-a4794f8ded4e", "name": "Emma's Protection Policy", "status": "active" },
  "rules":  [ /* age-appropriate rules for a preteen */ ]
}

Decision checklist

Still torn between two paths? Match the strongest statement below:

• "A parent needs to authorize me before I can act." → Provider (@phosra/link) — it runs the consent ceremony and signs your rule-write directives.
• "I need to block or allow content on a device, in real time, offline-safe." → Platform (@phosra/gatekeeper) — it verifies the signed profile once and decides locally with isAllowed(), fail-closed, zero per-decision network calls.
• "I just need to script family/policy setup from my backend." → Direct REST — no SDK, any language.
• "An LLM agent should drive this." → MCP server.
• "I want the open standard's crypto, and I might swap providers later." → OCSS protocol SDK — identical across every OCSS-conformant implementation.

Next steps