Skip to main content
With SAML single sign-on your institution holds one API key instead of one key per doctor. Your identity provider (Okta, Azure AD, ADFS…) authenticates the doctor, and your backend exchanges the institution key plus a signed SAML assertion for a doctor session token. Every business endpoint stays the same — only the Authorization value changes.

How it works

  1. Your IdP authenticates the doctor and signs a SAML assertion.
  2. Your backend calls POST /v1/sso/exchange with your institution secret key and the assertion.
  3. Telepatia verifies the signature, issuer, audience and validity against the SAML configuration of your institution, and returns a doctor access token plus a refresh token.
  4. Your backend calls the API with the doctor token, and renews it through POST /v1/sso/refresh — no new IdP round-trip until the refresh chain ends.

Prerequisites

  • An institution secret key (sk_…) created with the SAML SSO exchange permission (the saml:exchange checkbox in the platform’s API Keys page).
  • The SAML configuration saved in the platform’s Developers → SSO tab: your IdP’s entity ID (issuer) and its signing certificate.
  • The doctor must already exist in your institution. SSO authenticates doctors; it does not create them.

Service Provider details

Register these fixed Telepatia values in your identity provider. They are the same for every institution.

Exchanging an assertion

Send the base64-encoded SAML response with your institution key:
Response 200:
Cache the session and reuse it until it expires. Each assertion is single use — a second exchange with the same assertion returns 403.

Assertion requirements

  • The assertion is signed (RSA-SHA256, enveloped signature) with the certificate configured for your institution.
  • The Issuer equals the IdP entity ID configured for your institution.
  • The Audience equals the SP entity ID above.
  • The Destination equals the ACS URL above.
  • The validity window (NotBefore / NotOnOrAfter) covers the moment of the exchange.
  • The assertion carries an AttributeStatement — standard IdPs always include one.
  • The doctor’s email arrives as the subject NameID (format emailAddress), or in the attribute named by the optional email attribute setting.

Refreshing the session

The refresh token is the credential — no institution key and no assertion:
The response carries the same session shape as the exchange. Refresh tokens rotate: the old one is revoked when the new pair is issued, and reusing it returns 401.

Calling the API as the doctor

Use the access token exactly where the API key would go:

Error responses

Example: replayed assertion

Example: invalid assertion