Skip to main content
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-id

​
Reach 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:

developers@phosra.com

The one address for developer support, SDK access requests, and integration help.
To get a useful answer on the first reply, include:
1

The request id

The X-Railway-Request-Id from the failing response (see the tip above).
2

The error, verbatim

The full JSON body — at minimum code and class, plus failed_step if the response is a 403 standing_failure. Do not paraphrase; paste it.
3

What you expected vs. what happened

The route you called, the identity (key_id or DID) you called it as, and the behaviour you expected. A minimal curl that reproduces it is ideal.
Never paste a live secret. phosra_test_ keys are safe to share for debugging; phosra_live_ keys, private signing keys, and session tokens are not — redact them. If a live secret has already leaked, revoke it in the dashboard and mint a new one before anything else.

​
Response expectations

We would rather tell you the truth than publish a number we cannot keep. Here is what is actually committed:
ChannelWhat it is forWhat we commit to
security@phosra.comVulnerabilities & security incidentsTriage within one business day, with updates through remediation (published on our Trust page)
developers@phosra.comSandbox & integration supportBest-effort, monitored during business hours. No published SLA for the free sandbox
Accreditation agreementProduction partnersSupport commitments are defined in your signed production-accreditation agreement, not here
GitHub issuesBugs in the public reposCommunity 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. Time-sensitive production guarantees come with accreditation. For real-time platform health during an outage, the status page is always the source of truth, not email.

​
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 conformance 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 developers@phosra.com 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:

security@phosra.com

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.
  • Do not test against production parent or child accounts. This is a child-safety platform — real accounts are strictly off-limits.
  • 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.

​
Still stuck?

Troubleshooting

Symptom-first fixes with a runnable check for each — start here.

Error reference

The complete status-code and error-class tables, every field documented.