Skip to main content
This is the canonical billing reference. Read it before going to production.

​
What is billed

Phosra charges the provider (not the platform) per distinct family linked, measured by the FamilyMeter:
  • A “family” is the set of children sharing a family_id in the census, derived from the unlinkable household hash inside the grant.
  • One family with 3 children across 5 connected apps = 1 billable family, not 15.
  • The metric is: distinct family_id values with at least one active grant stamped with your developer_org, counted over the billing interval (interval-union — churn and reconnect within the same interval counts as one day, not two).

​
The attribution hook — your API key on the binding leg

Billing attribution happens at the binding leg of the connect ceremony. When runConnectCeremony → completeLink POSTs POST /api/v1/enforcement-endpoints, the census handler reads LinkConfig.developerOrgId and stamps it on the phosra_link_grants row immediately after the endpoint is minted. That stamp is the audit trail for invoicing.
Omit developerOrgId and the grant lands in the null/anonymous bucket — no invoice, no attribution, no SLA. This is the correct default for local development and self-hosted deployments where you do not want billing. To provision an org and get a phosra_live_ key, use the control-plane API or contact developers@phosra.com.

​
Platform pays nothing

The platform role is entirely free. These operations are never metered and never blocked:
You charge for the connection, never for keeping a kid safe.
If a provider account is over quota, invoices are issued but enforcement continues uninterrupted. No child is ever protected less because of a billing state.

​
Co-bound families

A family linked by more than one provider (e.g. both Guardline and BrightCanary have active grants for the same household) is held out of auto-invoicing until one owner is designated. Phosra will not charge both providers for the same family. Watch for a co_bound_family notification on your developer dashboard. Resolution is out-of-band; contact developers@phosra.com.

​
Anonymous / self-hosted bucket

Grants minted without a developerOrgId land in the anonymous bucket:
  • No invoice
  • No billing attribution
  • No support SLA
  • Full OCSS enforcement — safety is never gated on billing state
This is the intended path for:
  • Local development (phosra init wires this by default)
  • Self-hosted deployments (running your own census via @openchildsafety/bundle)
  • Open-source integrations built on the OCSS standard directly

​
The §12.3 line (free vs paid)

The OCSS specification §12.3 defines the boundary between the open protocol and metered hosted services. Phosra’s pricing follows this line exactly: The rule: local = free; hosted persistence and distribution = metered.

​
Getting a billing account

  1. Apply for production accreditation. Billing provisioning is part of the accreditation approval — Phosra will issue a phosra_live_... API key when your DID is promoted to accredited on the production Trust List.
  2. Alternatively, email developers@phosra.com to provision an org account directly if you are already accredited.
  3. Derive your developerOrgId from the key or retrieve it via GET /developers/orgs.
  4. Set developerOrgId in your LinkConfig.
  5. Families you link are attributed to your org and appear in usage rollups at GET /developers/orgs/{orgId}/usage.

​
Usage rollups

Pull hourly usage counts via the control-plane API. Like all org/key management calls, this endpoint authenticates with your WorkOS session bearer (the JWT from your dashboard session — see Create your account & get keys), not a phosra_ key:
@phosra/sdk-dev (the planned unified wrapper with a typed getOrgUsage helper) is not yet published — an npm install @phosra/sdk-dev fails today. Use the plain HTTP call above until it ships; see Phosra Developer SDK.

​
Next