The latest Auth Service API is now the only Auth Service API available. The legacy Auth Service API has been removed, so users can no longer interact with the legacy API by setting the Content-Type API header to application/legacy+5-9-2022.

If you have any questions or concerns about the new Auth Service API, please complete this support ticket form and select "Account log-in/authentication" for the question "What portion of the Zus Developer Sandbox does your support ticket relate to?"

We are excited to release the new, default Auth Service API with capabilities closely aligned with the latest JSON v1.0 API spec. Please read on for details on breaking changes and legacy Auth Service API deprecation timeline.

The new Auth Service API is now the default. Users can opt out of the new Auth Service API to use the legacy API by setting the Content-Type API header to application/legacy+5-9-2022 until May 9, 2022, when the legacy Auth Service API will be deprecated.

The Auth Service API now includes pagination and expanded filtering capabilities for all endpoints, as well as a new “include” parameter for getting information about related objects. Auth Service API objects now consist of attributes and relationships, resulting in breaking changes (see below).

If you have any questions or concerns about the new Auth Service API, please complete this support ticket form and select "Account log-in/authentication" for the question "What portion of the Zus Developer Sandbox does your support ticket relate to?"

Breaking changes:

• The IdentityRoleLink object is no longer available, as users can be assigned to roles directly through the POST User endpoint.
• Casing changes
  • Object field names are camel case (e.g., RoleID instead of role_id)
  • URL terms are kebab case (e.g., app-clients instead of appclients)
• Model structure changes for all object models: fields other than type or id are now modeled as attributes of the object or relationships to the object. Example:

{
  "type": "auth/users",
  "id": <UUID>,
  "attributes": {
    "email": <string>,
    "name": <string>,
    "userType": <string>
  }, 
  "relationships": {
    "role": {
      "data": { "type": "auth/roles", "id": <UUID> }
    }, 
    "practitioner": {
      "data": { "type": "fhir/practitioner", "id": <UUID> }
    }
  }
}

On April 25, 2022, Zus Health will release a new version of the Auth Service API with new capabilities more closely aligned with the latest JSON v1.0 API spec. Please read on for details on breaking changes and rollout timeline.

The new Auth Service JSON API includes pagination and expanded filtering capabilities for all endpoints, as well as a new “include” parameter for getting information about related objects (e.g., get details about a user and their roles in one API call). Auth Service API objects now consist of attributes and relationships, resulting in breaking changes (see below). Zus will support the old and new API versions according to the rollout timeline below. This change does NOT affect any Zus APIs other than the Auth Service API.

Rollout Timeline:

• April 15, 2022: New API version available for opt-in
• April 25, 2022: New API version is the default, users can opt-out
• May 9, 2022: New API is the only version available (opt-out period ends)

How to opt-in: Set the Content-Type API header to application/vnd.api+json.
How to opt-out: Set the Content-Type API header to application/legacy+5-9-2022.

If you have any questions or concerns about switching to using the new API version, please complete this support ticket form and select "Account log-in/authentication" for the question "What portion of the Zus Developer Sandbox does your support ticket relate to?"

Breaking changes:

• The IdentityRoleLink object is no longer available, as users can be assigned to roles directly through the POST User endpoint.
• Casing changes
  • Object field names are camel case (e.g., RoleID instead of role_id)
  • URL terms are kebab case (e.g., app-clients instead of appclients)
• Model structure changes for all objects: fields other than type or id are now modeled as attributes of the object or relationships to the object. Example:

{
  "type": "auth/users",
  "id": <UUID>,
  "attributes": {
    "email": <string>,
    "name": <string>,
    "userType": <string>
  }, 
  "relationships": {
    "role": {
      "data": { "type": "auth/roles", "id": <UUID> }
    }, 
    "practitioner": {
      "data": { "type": "fhir/practitioner", "id": <UUID> }
    }
  }
}

Zus applications and Postman now support single sign-on (SSO) with external enterprise identity providers. See below for information on the SSO experience and how to set up an SSO connection with Zus. 🙌

Users can now log into Zus App and get Zus API access tokens in Postman by authenticating with their identity provider. In all cases, the login screen now contains a single prompt for the user’s email address, also known as an “identifier-first” login flow (see image below). If the domain of the email address matches a known identity provider, Zus will redirect the user to that identity provider for authentication, also known as “home realm discovery.” If there is no identity provider for the email domain, Zus will prompt the user for their password to log in.

To set up SSO with your identity provider in Zus, please complete this support form and someone will reach out to you shortly.

For more details on the SSO login flow and provisioning users to log in with SSO, please see our linked documentation.

We are very excited to announce the launch of our payer data ingestion, medical history, and medication history APIs! More information below ✨

• Using the Zus Payer Data Ingestion engine, Builders can now more easily ingest payer data files and normalize that data to standardized FHIR endpoints. Zus Payer Data Ingestion is available for all payers in the U.S. Read the overview here for more details!

• Using the Zus Medical History APIs, Builders can pull clinical history from providers across the U.S., parsing clinical documents from legacy formats into a broad array of FHIR resources. The medical history APIs also enable Builders to exchange clinical data back to organizations nationwide. While still in Beta functionality, you can find an overview here!

• Using the Zus Medication History APIs, Builders can pull medication dispense history from 99% of pharmacies across the US, providing information in relevant FHIR resources. While still in alpha functionality, you can find an overview of the APIs here.

Builder admins can now add new users and configure their access permissions in a self-service fashion via the Zus API. This comes with an important breaking change. Details below 👇

As a builder admin, you can use Zus Auth Service APIs to manage two types of accounts within your Builder Org on Zus: users and app clients. More details can be found here.

🚧

Note: This comes with a Breaking Change

Builders will need to update their audience when authenticating with Zus from https://zus-sandbox.us.auth0.com/api/v2/ to https://api.sandbox.zusapi.com. Not doing this will result in a failed authentication error. We plan to disable access to the legacy audience on Thursday, December 23, 2021 at 10am EST.

Zus Health has launched a HIPAA compliant production environment! More below 🎉

• Builders now have access to a HIPAA compliant production environment
  • Upon signing a BAA with Zus Health, Builders can now place PHI in a production environment. Please do not put PHI in the Sandbox!
• Builders can now specify different levels of access permissions for their users. Read more here.
• Builders now have access to a number of new documentation resources
  • We’ve published new tutorials providing an overview of seeder data, patient creation, and care team management. See “Tutorials” section of our documentation for more information.
  • We’ve made a number of readability improvements across the documentation

Zus has launched its first Sandbox environment and FHIR service! Details below 🙌

• Builders have access to a Sandbox environment with pre-populated sample data. Please review the "Getting Started" section of our documentation to get started in our Sandbox.
  • Builders have access to a library of FHIR APIs that can edit information in the Zus ODS, accessible via curl and a postman collection. Review the API overview to authenticate, tutorials for an introduction to some initial capabilities of our APIs, and the API reference for a full overview of our current API offering.