Post-live Partner API operations & testing

1. Register an API client — it has no access by default.
2. Grant it a specific Program in a specific environment.
3. Issue a scoped credential. The secret is shown once; Solia stores only a hash. Production issuance requires step-up verification.
4. Configure a public HTTPS webhook endpoint separately and store its signing secret.

• Scopes: programs:read, catalog:read, serviceability:read, subjects:write, orders:write, orders:read, orders:cancel, results:read, events:read, webhooks:manage.
• Order creation requires an Idempotency-Key; reusing a key with a different payload returns 409.
• Rotating a credential issues a new key and retires the old one. If retirement fails, Solia attempts to revoke the replacement; if both steps fail, operator reconciliation is required. This is not an atomic swap.

Build URLs from the environment handoff. If SOLIA_API_BASE already ends in /v1, append /health, /programs or /events without another version segment. Use the generated API reference for POST /serviceability and POST /orders schemas; examples are synthetic input, not proof of order eligibility.

After a notification gap, persist and resume the cursor from GET /v1/events, then re-read affected orders and released results. Notification retry is not permission to resend a clinical order. Sandbox, Production, API-key and webhook-secret rotations remain separate.

• Sandbox stays available after activation for synthetic regression tests; it never shares data or credentials with Production.
• Production checks in the Control Plane are metadata-only: they confirm configuration, not a clinical round trip.
• Real laboratory testing with synthetic patients requires the laboratory's own approvals and is not available as a self-service action.