Dexcare Authentication

generated: '2026-08-15'
method: searched
source: https://developers.dexcarehealth.com/api/
docs: https://developers.dexcarehealth.com/api/
specs:
  - openapi/dexcare-visit-service-openapi.yml
  - openapi/dexcare-care-options-openapi.yml
  - openapi/dexcare-slots-availability-openapi.yml
  - openapi/dexcare-visit-booking-openapi.yml
  - openapi/dexcare-provider-data-management-openapi.yml
  - openapi/dexcare-omni-search-openapi.yml
summary:
  types: [oauth2, http, apiKey, none]
  api_key_in: [header]
  oauth2_flows: [authorizationCode]
  note: >-
    DexCare runs two distinct credential families, and which one applies depends on
    who is calling. Server-to-server integrations (care options, slot availability,
    booking, provider data, reporting) authenticate with an API key DexCare issues to
    the customer; patient- and staff-facing operations that touch PHI/PII
    authenticate with a JWT bearer token obtained through the health system's own
    identity provider using an OAuth 2 authorization-code flow. Public directory and
    availability reads require no credential at all. There is no global authorization
    server — credentials, IdP and tenant host are all provisioned per health system,
    so a developer must go through DexCare onboarding with each system they integrate.
schemes:
  - name: ApiKey
    type: apiKey
    in: header
    header: x-api-key
    description: >-
      API key issued by DexCare to the customer for API-key-to-API-key authorization.
      Used by the Care Options, Slots Availability, Visit Booking and Provider Data
      Management services. The Slots Availability document names the specific key as
      API_KEY_SLOTS, indicating keys are scoped per service rather than per account.
    sources:
      - openapi/dexcare-care-options-openapi.yml
      - openapi/dexcare-slots-availability-openapi.yml
      - openapi/dexcare-visit-booking-openapi.yml
      - openapi/dexcare-provider-data-management-openapi.yml
  - name: PatientJWT
    type: http
    scheme: bearer
    bearerFormat: JWT
    in: header
    header: Authorization
    description: >-
      Patient bearer token, format `Bearer {KEY}`. Required by createVisitV9,
      getEstimatedVirtualVisitWaitTime and updateAcceptTerms on the Visit Service.
    sources: [openapi/dexcare-visit-service-openapi.yml]
  - name: StaffJWT
    type: http
    scheme: bearer
    bearerFormat: JWT
    in: header
    header: Authorization
    description: >-
      Staff bearer token, format `Bearer {KEY}`. Required by visitSummaryV9. Not
      interchangeable with the patient token — the two are declared as separate
      security schemes and bound to different operations.
    sources: [openapi/dexcare-visit-service-openapi.yml]
  - name: bearerJWT
    type: http
    scheme: bearer
    bearerFormat: JWT
    in: header
    header: Authorization
    description: >-
      The documentation-level name for the same bearer pattern: any endpoint working
      with protected health information (PHI) or personally identifiable information
      (PII) is annotated AUTH TOKEN REQUIRED in the REST API reference and needs a JWT
      in the Authorization header.
    sources: [https://developers.dexcarehealth.com/api/]
  - name: oauth2AuthorizationCode
    type: oauth2
    flow: authorizationCode
    scopes: {}
    description: >-
      OAuth 2.0 Authorization Code Grant used to obtain the JWT bearer token. DexCare
      states the flow exists so the patient or authorized caregiver knowingly consents
      to sharing health information. Authorization and token endpoints are supplied per
      health system by that system's identity provider; no global endpoint, no
      discovery document (all /.well-known/ probes 404 — see
      well-known/dexcare-well-known.yml) and no scope vocabulary are published.
    sources: [https://developers.dexcarehealth.com/api/]
  - name: dcTokenServiceKey
    type: apiKey
    in: header
    header: Authorization
    value_prefix: 'dc-token '
    description: >-
      Reporting service key, sent as `Authorization: dc-token <SECRET_TOKEN>`. Used by
      the All Visits Report and All Providers Report endpoints. DexCare warns
      explicitly that this token must never live in a mobile or client-side JavaScript
      application. Obtained from a DexCare account manager. Rejection is a 403 with
      {"message":"Authorization failed: bad service token"}.
    sources: [https://developers.dexcarehealth.com/api/reporting]
  - name: public
    type: none
    description: >-
      Publicly available information is served without authentication: clinic and
      provider directories, care-options discovery, and — confirmed in the published
      specifications — getAggregatedSlotsV1, getAvailabilityAndWaitTimes,
      getRegionAvailabilityAndWaitTimes, getModalities, getAssignmentQualifiers and
      the entire Omni Search surface, which declares `security: [{}]`.
    sources:
      - https://developers.dexcarehealth.com/api/
      - openapi/dexcare-visit-service-openapi.yml
      - openapi/dexcare-omni-search-openapi.yml
gaps:
  - No OAuth scope vocabulary is published anywhere, so scopes/ cannot be derived.
  - >-
    No /.well-known/openid-configuration or /.well-known/oauth-authorization-server is
    served on any DexCare host; every probe returned 404.
  - >-
    Key rotation, expiry and revocation policy is undocumented for both the x-api-key
    and dc-token credentials.