Skip to main content
Enforcement is the process of pushing a child’s active policy rules to connected platforms. When you trigger enforcement, Phosra creates an enforcement job that fans out to each connected platform in parallel, translating universal rules into platform-specific configurations.

Flow

  1. Trigger — Call POST /children/{childID}/enforce (optionally targeting specific platforms)
  2. Job created — Returns 202 Accepted with {"job_id": "...uuid..."}
  3. Fan-out — Phosra pushes rules to each connected platform in parallel
  4. Poll for results — there is no push callback on enforcement completion (see below)
  5. Job completes — overall status reflects the aggregate result

Verification contract — poll, do not expect a webhook

There is no per-platform push webhook fired on enforcement completion. Webhooks exist for other events (policy.updated, family.created, etc.) but not for the completion of a per-platform enforcement result. To verify enforcement, poll:GET /api/v1/enforcement/jobs/{jobId}/results
The developer surface is identical: GET /api/v1/developer/enforcement/jobs/{jobId}/results Both return []EnforcementResult:

Reading the result

A non-empty manual_steps array means the platform is manual_attested — Phosra generated the steps but the parent is the actor, not the API. Do not count these as rules_applied. See Platforms & enforcement modes for the full breakdown.

EnforcementJob vs BrowserEnforcementJob

EnforcementJob (the GET /enforcement/jobs/{jobId} response shape) is deprecated. Use BrowserEnforcementJob for all new enforcement workflows — it carries richer state (screenshots, deployment_model, duration_ms) and is the type returned by all current handler code. Both share the same polling pattern: poll results until status is completed, partial, or failed.

Consumer vs developer surface

The consumer and developer enforcement routes use the same handlers — the path prefix is the only difference: This split is deliberate, not drift — it is an auth-path decision so server integrators (developer keys) and end-user apps (WorkOS JWTs) each reach the same logic through their respective credential type. Response shapes are identical.