Single Sign-On with Healthie

As part of our web white-label, Healthie can provide a Single Sign-On (SSO) to help you connect this platform to other software tools that your business uses. 

Overview of Single Sign-On (SSO) with Healthie

Single sign-on (SSO) is an authentication mechanism that allows a user to log in to Healthie, or conversely to another software system, with a single ID and password, to any of several related but independent software systems. SSO allows a user to log in once and access services that may otherwise be disparate sites. 

Healthie supports single sign-on via OAuth. Healthie can serve as the OAuth client, and your platform would be the OAuth provider. This allows clients to sign into Healthie via the credentials from your platform, and not have to maintain two separate log-in details. 

Note: If your client is accessing Healthie from one of your website embeds (e.g., of packages or session booking), they are not prompted to log into the platform, so SSO is not needed on these embeds. 

Examples of when to leverage SSO with Healthie

  • Your organization has an internal software that has provider and/or client login credentials (e.g., a consumer-facing app)
  • You use Athenahealth or another EMR platform alongside Healthie, and your patients already login to AthenaHealth (in this instance, we can set up SSO such that your patients and providers can use their AthenaHealth login credentials to log into Healthie)

Setting up SSO

Here is information on our typical process for OAuth Integration:

1) You act as the OAuth provider, and are able to expose a standard openid configuration (e.g If you use Okta, here's more information on how to set up this configuration
2) You add us an authorized OAuth client, and are able to provide us with a client ID and client secret, and whitelist our redirect URL (generally something like

3) It's normally helpful to provide us with sample credentials so that we can sign in and verify the connection. Please e-mail us:, to complete the SSO process. There is a 14 business day turnaround time for setting up SSO.

Adding on SSO with Existing Users

To add on SSO to an existing account with existing users, we see two common options: 

1) Match accounts by email (and potentially first/last name) the first time the user signs in via SSO. Once they do that the first time, those accounts are linked moving forward.

2) You provide us with a mapped list of users from your IDP including their UID in the IDP, and their associated account in Healthie. We pre-load in their SSO UID so that the accounts are already linked, and we don't need to match by email.

SSO for Sub-orgs

On a full web white-label, we can help you set up SSO for a specific sub-org. This is limited to one SSO for providers, and one SSO for clients, per sub-org. 

Getting Started

If you are interested in setting up SSO with your web white-label, please e-mail with the subject line "SSO" and we will help you get this set up.

Note: We cannot guarantee SSO compatibility, but we will make our best effort to help you identify a plan to streamline logins for your providers and clients. In some instances, there may be an additional fee for SSO. 

Leverage an SSO with other Applications (ie. Cloudfare)

If you're able to expose an openID configuration, we'd be able to set it up; here's how we handle SSO:

1) You act as the OAuth provider, and are normally able to expose a standard openid configuration (e.g Here's information about how to set that up with Okta if you are using them ->

2) You add us an authorized OAuth client, and are able to provide us with a client ID and client secret, and whitelist our redirect URL (generally something like It is best practice to give us two different OAuth clients, one for dev/staging, and one for production, as well as a test log-in for the dev/staging one.

3) Healthie will take it from there!

Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.

Still need help? Contact Us Contact Us