Flow
- Trigger — Call
POST /children/{childID}/enforce(optionally targeting specific platforms) - Job created — Returns
202 Acceptedwith{"job_id": "...uuid..."} - Fan-out — Phosra pushes rules to each connected platform in parallel
- Poll for results — there is no push callback on enforcement completion (see below)
- Job completes — overall status reflects the aggregate result
Verification contract — poll, do not expect a webhook
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.
Related API Endpoints
- Trigger enforcement — Push rules to all or selected platforms
- Get job status — Poll for completion
- Get results — Per-platform breakdown
- Retry failed job — Re-attempt a failed enforcement