Developer access

Sign in through the right identity lane

Enterprise SSO, GitHub, and Slack can accelerate partner onboarding, but production API authority remains tenant-scoped, contract-gated, and audit-evidenced.

Review access policy View API authentication

Choose the entry lane

These entrypoints start an access request or sandbox review. They do not grant PHI access, production scopes, or live tenant administration by themselves.

Enterprise SSO requestFor organizations using OIDC/SAML, SCIM, MFA policy, domain verification, and tenant-managed role mapping.GitHub developer accessFor SDK review, sandbox keys, sample apps, issue triage, and technical collaboration that does not touch PHI.Slack partner accessFor partner launch rooms, support escalation, onboarding coordination, and non-PHI operational updates.

Compliance guardrails

Social identity never bypasses healthcare controls

Every identity option is evaluated by portal, tenant, environment, contract status, and data sensitivity before it becomes available.

No PHI by social login alone

Patient or clinical data requires tenant policy, BAA/privacy review, explicit role approval, and immutable access evidence.

No production API scope from workspace identity alone

Production API access still requires approved client credentials, tenant scopes, signing keys, rotation policy, and rate limits.

Every access path must be auditable

Approvals, role changes, session events, sandbox keys, and production promotions must be logged and exportable for audit review.

Server-to-server

Production APIs remain OAuth client_credentials

Human sign-in helps onboard developers. Runtime integrations still use scoped machine credentials with webhook signing, tenant isolation, and least privilege.

GitHub and Slack are onboarding gates, not production authorization.

Required evidence includes developer approval, organization membership, sandbox issuance, production scope approval, token events, and access reviews.

This page describes the intended access model. Live SSO/OAuth providers are enabled only after provider configuration, contracts, scope mapping, audit logs, and production tests are complete.