Support & getting help
Stuck on an integration? Start with the self-serve fixes below — most 4xx responses resolve in under a minute without opening a ticket. When you do need a human, this page tells you exactly who to reach, what to include, and how quickly to expect a reply — no invented SLAs, no dead links.
Fix it yourself first
Nearly every error the API returns is self-explaining and has a documented cause and fix. Check these before you write to us — you will usually be faster.
Troubleshooting
Organized by symptom, not by code. Find what you are seeing, run the check, apply the fix.
Error reference
Every HTTP status and error class, each with its cause, its fix, and a live example.
Platform status
Is it you or us? Live operational status for the OCSS census, plus the full incident history.
Changelog
Recent API and SDK changes — check here first if something worked yesterday and not today.
Before you contact anyone, grab the X-Railway-Request-Id header from the
failing response. It lets us find your exact request in the logs — with it, a
reply is minutes; without it, it is a guessing game.
curl -s -D - -o /dev/null "https://phosra-api-sandbox-production.up.railway.app/health" \
| grep -i x-railway-request-idReach the developer team
For integration questions, sandbox behaviour, key/access requests, and anything that is not a security issue or a public-repo bug, email the developer inbox:
[email protected]
The one address for developer support, SDK access requests, and integration help.
To get a useful answer on the first reply, include:
- 1The request id
The
X-Railway-Request-Idfrom the failing response (see the tip above). - 2The error, verbatim
The full JSON body — at minimum
codeandclass, plusfailed_stepif the response is a403 standing_failure. Do not paraphrase; paste it. - 3What you expected vs. what happened
The route you called, the identity (
key_idor DID) you called it as, and the behaviour you expected. A minimalcurlthat reproduces it is ideal.
Never paste any secret. Sandbox keys, production keys, private signing keys, endpoint labels, connect secrets, and session tokens must all be redacted. If a secret has leaked, revoke or rotate it before continuing.
Response expectations
We would rather tell you the truth than publish a number we cannot keep. Here is what is actually committed:
| Channel | What it is for | What we commit to |
|---|---|---|
[email protected] | Vulnerabilities & security incidents | Triage within one business day, with updates through remediation (published on our Trust page) |
[email protected] | Sandbox & integration support | Best-effort, monitored during business hours. No published SLA for the free sandbox |
| Design-partner pilot | Beta participants | Any pilot-specific support commitment must be written in the pilot agreement; no public production SLA is claimed here |
| GitHub issues | Bugs in the public repos | Community best-effort; maintainers triage on a rolling basis |
The sandbox is a best-effort developer environment, not a paid production service — treat the developer inbox accordingly. The design-partner beta does not confer accreditation, certification, or a public production SLA. Use the status page for the availability of documented evaluation surfaces.
File a bug
Where a bug goes depends on which component it is in.
iOS Link Kit — PhosraLinkKit
The native-iOS Phosra Link connect sheet (Swift). Open an issue on the public repo.
OCSS evaluation harness — Touchstone
The open @openchildsafety/provider-harness (TypeScript). File conformance-tooling bugs here.
For everything else — the control-plane / data-plane API, the dashboard, the
managed @phosra/* SDKs, or the MCP server
— the source is not public, so there is no issue tracker to file against. Email
[email protected] with the request id and the
verbatim error instead. A good bug report is reproducible: include the exact
route, the identity you called it as, and a minimal curl.
A crash or 5xx that you can reproduce is one of the most useful things you can
send. Retry with backoff first (5xx are transient); if
it persists, send the X-Railway-Request-Id — that is what lets us pull your
exact trace.
Report a security issue
Found a vulnerability? Please do not open a public GitHub issue. Email:
[email protected]
Responsible-disclosure contact. Triaged within one business day; researchers are credited in our disclosure log with your permission.
We welcome good-faith research under a few ground rules, taken directly from our Trust & security page:
- Do not access data that is not your own. Use your own sandbox org and test identities.
- Use synthetic sandbox identities only. Public production parent/child accounts are not part of the documented evaluation surface.
- Do not run scanners that degrade service for other developers.
In return, we triage within one business day, keep you updated through remediation, and — with your permission — credit you in our public disclosure log. Confirmed breaches are notified within 72 hours, consistent with GDPR Article 33 and CCPA. Full detail lives on the Trust page.
Community & staying informed
Phosra does not run a public chat community (no Discord or Slack) — so if you see one claiming to be us, it is not. The honest set of channels today:
Changelog
The canonical feed of API and SDK changes. Check it before assuming a regression.
Status & incidents
Live operational status and the full incident history for the OCSS census.
Open-source repos
Public repos (Link Kit, Touchstone). Issues are the place for questions on those components.
OCSS standard
The open specification Phosra implements — protocol, roles, and the trust framework.
The vendor-neutral OCSS protocol library ships on npm as
@openchildsafety/* (there is no @ocss/* scope). SDK install and status
details are on the SDKs overview.