sdp_suki_token header. That token lasts 1 hour. Long ambient, Form filling, Dictation, or Patient Summary jobs can outlive that window and fail with 401 / invalid_sdp_token.
Partner APIs vs SDKs
A Partner Token alone is not enough to create sessions, stream audio, or retrieve Form filling or Patient Summary output. Exchange it for a Suki Token first (Login on Partner APIs, or SDK sign-in).
Common causes
- A session, poll loop, or WebSocket stays open longer than 1 hour.
- Your server caches Login and never calls Login again.
- You refresh the Partner Token in the EHR but never exchange it for a new Suki Token on Partner API clients.
- On SDKs, the Partner Token expired, so automatic Suki access token refresh fails.
Fix Partner API clients
1
Plan for the 1 Hour Lifetime
Refresh before the hour ends, or as soon as you get
invalid_sdp_token / 401 on a provider-scoped endpoint.2
Call Login Again
POST
/api/v1/auth/login with a valid partner_id and partner_token (and provider_id when your partner type requires it). Read the new suki_token.3
Update Headers and New Connections
Set
sdp_suki_token on later REST calls and on new WebSocket connections. Do not keep the expired value.Fix SDK clients
1
Keep the Partner Token Valid
Automatic Suki access token refresh uses the current
partnerToken. If that JWT is expired, refresh fails and API calls fail.2
Rotate Partner Token at Runtime
Web SDK: Call
setPartnerToken when your EHR issues a new Partner Token.Headless Web SDK: Call updatePartnerToken() with the new Partner Token.Next steps
Partner authentication - Token exchange and 1 hour Suki Token lifetime Login - Obtain and refreshsuki_token / sdp_suki_token
Form filling API authentication - Register, Login, and 1 hour refresh for Form filling APIs
Web SDK token refresh - Automatic Suki access token refresh and setPartnerToken
401 Unauthorized or invalid Partner Token - Partner Token failures vs invalid_sdp_token