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.

The Product Parameter

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.

In-Clinic Booking APIs

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

How you use the DexCare APIs to book an in-clinic visit with depend on whether the patient is looking for a specific provider (referred Provider Direct) or they are agnostic to the provider and are just seeking care near a given location (we refer to this as Care Direct)

Provider Direct

This type of booking is for when the patient is booking for specific provider. Examples include primary care office visits and specialist office visits.

For this use cases patients will be selecting a specific time slot to be seen.

Start with our APIs describing how to select a Provider Direct timeslot.

Care Direct

This type of booking 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.

Start with our APIs for selecting a Care Direct timeslot.

Virtual Visits

DexCare offer an on-demand virtual (ODV) platform for booking and conducting telemedicine visits via video.

The DexCare APIs allow these visits to be booked programmatically so health systems may develop their own booking flows.

See the APIs described in Virtual Care for more information.

API Pages

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

Virtual Care — For booking virtual visits

Care Direct — For finding time slots without regard to provider

Provider Direct — For finding time slots for a specific provider

Care Options — For finding available time slots using DexCare’s intelligent navigation capabilities

Booking API — For booking in-person appointments once you have selected a time slot

Patient API — For retrieving paient information required by the other APIs

Reporting API — For retrieving DexCare reports