> ## 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.
# Bearer Partner Type Authentication
> Learn how Bearer partner authentication works, when to pass provider_id, and how to integrate with REST APIs
Some partners cannot include per-user identity information in the OAuth 2.0 token they send to Suki. During onboarding, Suki configures these organizations as **Bearer partners**.
Bearer partners authenticate the same way as other server-to-server partners. Send `partner_token` in the JSON request body for [Login](/api-reference/authentication/login) and [Register](/api-reference/authentication/register).
Because the token is shared across providers, Bearer partners must also send `provider_id` in every Login and Register request so Suki can identify the active provider.
**Important:**
Suki assigns your partner type during onboarding. If you are not sure whether your organization is configured as a Bearer partner, contact your partnership team.
This guide applies only to Bearer partners. It does not apply to partners that use a per-user ID token or user-scoped access token as partner\_token.
## Prerequisites
Before you implement Bearer partner authentication, confirm the following:
* **Bearer partner configuration** - Your Suki partner contact confirms that your organization is configured as a Bearer partner.
* **Provider ID format** - You and Suki agree on a stable provider identifier format, such as an email address or external user ID. Use the same format on every login and register call.
* **HTTPS required** - Send [Login](/api-reference/authentication/login) and [Register](/api-reference/authentication/register) requests as HTTPS POST requests with a JSON body. Do not send credentials in query parameters.
## Use cases
Use Bearer partner authentication when your integration matches one of these scenarios:
Your backend uses a single shared `partner_token` for multiple clinicians, and the token does not identify the signed-in provider. Send `provider_id` on every [Login](/api-reference/authentication/login) and [Register](/api-reference/authentication/register) request so Suki can identify the correct provider.
Your application already knows the signed-in provider, such as through a session or database record, but you cannot include that identity in the `partner_token`. Instead, send a stable identifier as `provider_id` in the authentication request body.
Your identity provider does not issue a per-user ID token for Suki, or you cannot add user claims to the access token. Bearer partner authentication lets you keep your existing token model and identify the provider by using `provider_id`.
## How Bearer partners differ from other partners
| Topic | Standard partner authentication | Bearer partner authentication |
| :--------------------------------- | :------------------------------------- | :------------------------------------------------------ |
| User identity source | Derived from `partner_token` | Passed as `provider_id` in the request body |
| `partner_token` type | Per-user ID token or user-scoped token | Typically one shared `partner_token` for many providers |
| `provider_id` on login or register | Optional and ignored | Required |
In Bearer partner authentication, the partner application provides the provider identity on behalf of the signed-in user. This is different from the HTTP `Authorization: Bearer` header format.
You still send `partner_token` in the JSON request body for login and register requests.
## Authentication workflow
For Bearer partners, Suki validates `partner_id` and `provider_id` on [Login](/api-reference/authentication/login). If the provider is not registered, call [Register](/api-reference/authentication/register), then call Login again.
The flow matches standard partners after registration. Learn more about registration scenarios in [Provider authentication](/api-reference/provider-authentication#registration-scenarios).
## Login and Register request fields
Bearer partners use the same login and register endpoints as standard partners. You must include `provider_id` on every login and register call.
### Login
**Endpoint:** [Login](/api-reference/authentication/login)
**Method:** POST
| Field | Bearer partners |
| :-------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `partner_id` | Required. Partner ID from Suki. |
| `partner_token` | Required. Shared `partner_token` your integration uses for authentication. |
| `provider_id` | Required. Stable identifier for the provider in your system. Must match the format agreed with Suki during onboarding. |
#### Example request
```bash cURL theme={"theme":{"light":"github-dark","dark":"material-theme-darker"}}
curl -X POST https://sdp.suki-stage.com/api/v1/auth/login \
-H "Content-Type: application/json" \
-d '{
"partner_id": "your-partner-id",
"partner_token": "your-shared-partner-token",
"provider_id": "provider-123"
}'
```
On success, the API returns `suki_token`. Use it as the `sdp_suki_token` header on later Ambient API calls. The token is valid for **1 hour**. To refresh it, call Login again with a valid `partner_token`.
### Register
Register a provider once before their first login. Refer to [Provider authentication](/api-reference/provider-authentication#registration-scenarios) for new user, existing user, and conflict responses.
**Endpoint:** [Register](/api-reference/authentication/register)
**Method:** POST
| Field | Bearer partners |
| :------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------- |
| `partner_id` | Required. Partner ID from Suki. |
| `partner_token` | Required. Shared `partner_token` your integration uses for authentication. |
| `provider_id` | Required. Stable identifier for the provider in your system. Use this as the user identifier at registration. |
| `provider_name` | Required. Display name for the provider. |
| `provider_org_id` | Required. Organization the provider belongs to. |
| `provider_specialty` | Optional. Defaults to `FAMILY_MEDICINE` if omitted. |
#### Example request
```bash cURL theme={"theme":{"light":"github-dark","dark":"material-theme-darker"}}
curl -X POST https://sdp.suki-stage.com/api/v1/auth/register \
-H "Content-Type: application/json" \
-d '{
"partner_id": "your-partner-id",
"partner_token": "your-shared-partner-token",
"provider_id": "provider-123",
"provider_name": "Dr. Jane Smith",
"provider_org_id": "org-123"
}'
```
For all Register fields and response codes, refer to the [Register API reference](/api-reference/authentication/register).
**Security considerations**
If an attacker gets your shared `partner_token` and a valid `provider_id`, they could try to impersonate a provider. To reduce risk:
* Allow only trusted systems to call the login and register endpoints.
* Monitor for suspicious or unexpected authentication activity.
* Rotate shared `partner_token` values regularly when your identity provider allows it.