> ## Documentation Index
> Fetch the complete documentation index at: https://developer.suki.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Provider Authentication
> Learn how to authenticate providers and users to use the Suki Ambient APIs
**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](/documentation/get-started/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 (`partner_token`) to authenticate your API requests. The `partner_token` is a JWT 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](/documentation/how-to/partner-authentication) guide.
All Suki Partner APIs require partner authentication. To authenticate, exchange your Partner Token (`partner_token`) to get a Suki access token. Use the Suki access token to call the [Register](/api-reference/authentication/register) and [Login](/api-reference/authentication/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 provider** 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](/documentation/get-started/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](/api-reference/single-auth-token-authentication) and [Bearer partner authentication](/api-reference/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](/api-reference/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](/api-reference/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](/api-reference/authentication/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**: [Register](/api-reference/authentication/register)
**Method:** POST
### Registration scenarios
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](/api-reference/authentication/login) endpoint to get a Suki access token (`sdp_suki_token`).
If you are a **Bearer partner**, send `provider_id` on every [Login](/api-reference/authentication/login) and [Register](/api-reference/authentication/register) request. Refer to [Bearer partner authentication](/api-reference/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](/api-reference/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 URL](/api-reference/authentication/jwks)
**Method:** GET
**Authentication:** None (Public)
### Use cases
* **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.