Skip to main content
Not a Suki Partner yet?To use the Suki APIs, you must first register your organization as a partner. To begin, follow the Partner onboarding guide to learn more or schedule a call with Suki using the Ask AI chat assistant.After you register, you use a (partner_token) to authenticate your API requests. The partner_token is a that you provide, and it is a required parameter when registering a provider. Find more details on how to get a partner_token in the Partner authentication guide.
All Suki Partner APIs require partner authentication. To authenticate, exchange your (partner_token) to get a Suki access token. Use the Suki access token to call the Register and Login APIs and authenticate clinicians with Suki. Suki access tokens are valid for 1 hour. This guide explains the two main endpoints for the authentication workflow:
  • Register user: A one-time call to register a new in the Suki system.
  • Authenticate user: Call this endpoint to get a suki_token (sdp_suki_token) for a registered provider.

​
Choose your authentication model

Before integrating with Suki, determine which authentication model your organization uses. Your authentication model defines how clinician identity is sent to Suki and which fields are required during authentication and subsequent API requests. Suki supports the following authentication models and defines your model during Partner onboarding process.
This guide is for Standard partner authentication only. For Single Auth Token authentication and Bearer partner authentication, refer to the Single Auth Token authentication and Bearer partner authentication guides respectively.

​
1. Standard partner authentication

Each clinician authenticates with their own partner_token. Suki derives provider identity from that token, so you do not need to send provider_id on Register or Login. Best for
  • Enterprise deployments where each clinician has their own account in your identity provider
  • Integrations where your IdP issues a per-user ID token or user-scoped JWT as partner_token
  • Flows where the token already identifies the signed-in provider without a separate provider_id

​
2. Single Auth Token authentication

Your backend uses one shared partner_token for multiple clinicians. The token proves your organization is authorized, but it does not identify who is signed in. With Single Auth Token authentication, you send provider identity on every request: provider_id on Register and Login, and sdp_provider_id on every subsequent REST and WebSocket call. Best for
  • Server backends that authenticate to Suki with one organization-level token for many clinicians
  • Applications that already know the active provider from your session, EHR, or user directory
  • Identity setups that cannot include per-user claims in the partner_token
If you plan to use Single Auth Token authentication, see Single Auth Token authentication for more details.

​
3. Bearer partner authentication

Bearer is a separate partner type that Suki configures during onboarding. A Bearer partner validates the end-user identity with provider_id during Login and Register, instead of relying on per-user claims in the token. Best for
  • Partners whose shared partner_token cannot carry per-user identity
  • Integrations where Suki must validate provider_id against an agreed expression during authentication
  • Web SDK and other clients that pass provider_id for a Bearer partner configuration
For Login and Register fields, validation rules, and security guidance, refer to Bearer partner authentication guide.
  • Single Auth Token partners cannot be a Bearer partner.
  • To refresh a Suki access token, send another POST request to Login with a valid partner_token.

​
Register provider/user account

Use the below endpoint to register a new provider/user in the Suki platform. You only need to do this once for each new provider.
Endpoint: RegisterMethod: POST

​
Registration scenarios

Flowchart: POST register leads to User Exists; if No, New User Registration, Create User and Link, then Response 201; if Yes, Linked to this Partner; if No, Existing User New Partner Link, Link User to Partner, then Response 201; if Yes, Existing User Already Linked, then Response 409 Conflict. The Register endpoint handles three main scenarios:
  • New user registration: If the provider does not exist in the Suki system, this call creates a new user and links them to your partner account and organization.
  • Existing user, new partner link: If the provider already exists but is not linked to your partner account, this call links them to your partner and their existing organization.
  • Existing user, already linked: If the provider is already registered and linked to your partner account, the API returns a 409 Conflict error.

​
Authenticate provider/user session

After a provider is registered, call Login endpoint to get a Suki access token (sdp_suki_token).
If you are a Bearer partner, send provider_id on every Login and Register request. Refer to Bearer partner authentication. If you use Single Auth Token authentication, also send sdp_provider_id on every API call after Login. Refer to Single Auth Token authentication.

​
JWKS endpoint

Suki provides a public JWKS (JSON Web Key Set) endpoint that you can use to verify the signature of the sdp_suki_token that our API returns.
Endpoint: JWKS URLMethod: GETAuthentication: None (Public)

​
Use cases

Diagram: Fetch Public Keys leads to JWKS Endpoint; from JWKS, three branches to Token Verification, Signature Validation, and Key Rotation.
  • Token verification: Fetch public keys to verify JWTs issued by Suki.
  • Signature validation: Validate the signature of the sdp_suki_token.
  • Key rotation: Automatically discover new public keys when Suki rotates our signing keys.
Last modified on July 24, 2026