Authentication

Model

Partner integrations authenticate via OAuth 2.1 client-credentials grant — a system-to-system pattern, distinct from the member-facing PKCE flow described in the Ecosystem Blueprint (Section 1.1.1), which exists for a different actor (the member's own device) and is not applicable here.

POST https://api.ensure.health/oauth/token grant_type=client_credentials client_id=<issued at sandbox onboarding> client_secret=<issued at sandbox onboarding, rotated per your security policy> scope=integration.<your-category> Response: { "access_token": "<JWT, 15 min TTL>", "token_type": "Bearer" }

Scoping

Every partner credential is scoped to exactly one integration category (e.g., integration.pbm-formulary, integration.payer-eligibility) — a credential issued for formulary lookups cannot call the eligibility endpoints, enforced the same way Layer 0's policy engine scopes every internal request in the core architecture. This is not a separate security model built for partners; it's the same one.

Credential Rotation

Client secrets are rotated on a schedule agreed at onboarding (default 90 days). A rotation window overlaps the old and new secret for 24 hours so a live integration is never interrupted mid-rotation.

Sandbox vs. Production

Sandbox credentials are issued after a signed BAA. Production credentials are issued only after sandbox testing (including the malformed/slow-transaction test suite referenced in the Overview) passes — this gate exists so a partner integration never reaches live PHI without having proven its failure-mode handling first.