DexCare provides a RESTful service for customers to access business information and perform actions against their DexCare managed environments.

For the purposes of this documentation, we will reference DexCare’s service, web sites, and configuration.


Each DexCare customer is provided with two tiers, each with a specific domain to access the APIs.

There will be a user acceptance testing (UAT) tier, and a production (PRD) tier. This document presents all URL examples with the DexCare demo tier, Acme.

Using Acme as an example health system, there would be two tiers and the would be named the following:

  • UAT:

  • PRD:

Because Acme is a demo tier, the UAT version of Acme doesn’t exist and is presented as an example. The PRD version of Acme will be used in all examples below and can be used to try out the calls.

Your health system will be provided with the domain to use in your URLs.


Many of the APIs provided by DexCare do not require authentication. This is particularly true of APIs that return publicly-available information about clinics, providers or other public-facing elements of the healthcare system, which is also available from directories, mapping services and so on.

However, API calls that work with personal healthcare information (PHI) or personally identifiable information (PII), require a JSON web token (JWT) for authentication, obtained through either an OAuth 2 or single sign-on (SSO) process. DexCare API calls require the JWT to be provided as a “bearer” token in the Authorization header of each protected request.

In this documentation, the calls that require a JWT in the header will be indicated with the annotation: 


Generally, the process for obtaining these JWT tokens closely follows the OAuth 2 Authorization Code Grant flow. This flow helps to ensure that the patient or their authorized caregiver is aware that permission to access sensitive healthcare information is being given, that they understand the nature of the permissions being granted, and that they have an opportunity to approve or deny sharing of the data by the healthcare provider.

While DexCare does exchange PHI and PII in its role as an intermediary in the care booking process, it relies on the healthcare provider to manage this information. For that reason, the process for obtaining JWTs is specific to each healthcare system. Developers working with the APIs for care booking must consult with each individual healthcare system to obtain application keys and secrets necessary for obtaining JWT tokens to access sensitive data.

Booking APIs

The DexCare offers booking of in-clinic visits through its APIs.

Types of Booking

Two factors come into play when booking.

  • provider type: provider-agnostic / provider-direct
  • booking type: scheduled / on-demand

These two items define the four base booking mechanisms supported by the DexCare platform.

Provider Specific, Scheduled

This is for when the patient is booking for a specific timeslot and a specific provider.

Examples include primary care office visits and specialist office visits.

Provider Specific, On-Demand

This covers the use cases where the patient is getting in a queue to be seen as-soon-as-possible and are booking with a specific provider.

Provider Agnostic, Scheduled

Covers the use cases where the patient is booking a specific timeslot but are not booking with a specific provider.

Examples include low acuity clinics run with physicians from a pool and another would be physician’s office that support scheduled flu shots, vaccines, or COVID19 tests.

Provider Agnostic, On-Demand

Covers the use cases where the patient is getting in a queue to be seen as-soon-as-possible but are not booking with a specific provider.

Examples include DexCare’s virtual product where the patient enters the waiting room immediately upon booking.

Another example would be a patient “getting in line” or walking into an Urgent Care clinic.

Additional Use Case Support

In many of the calls to the DexCare platform you will see a product parameter.

This parameter is optional but allows DexCare to better support different use cases.

For instance, if you make timeslot calls from a Find A Doctor section you might make “product=findadoctor”.

If you were calling from a Get a Flu Shot web page you might make “product=flushot”.

Doing this allows DexCare to quickly identify which of your use cases are having issues.

API Pages

Below are links to the different functionality and uses cases supported by our API.

Patient API

Provider Agnostic Time Slots API

Provider Specific Time Slots API

Virtual Visit API

Reporting API