Provider Overview

What providers are

A provider (a vendor::Vendor in the code) is a compiled-in C++ client for one health-data source. Every provider implements the same authorize / fetch / webhook contract and is resolved at runtime by id. For the architecture — the contract, honest stubs, the registry — see Vendor System.

This page lists the sources that actually ship in src/health/vendor/, in four categories.

Aggregator platforms (platform/)

Fifteen B2B health-data aggregators that broker wearable, lab, or clinical data behind one contract. Each carries real VendorInfo metadata (positioning, region, compliance, data domains) queryable without credentials. Transport targets each platform’s public API; undocumented operations stay explicit stubs.

Vendor (id)	Region	Notes
Terra (terra)	Global	Connect widget + HMAC webhooks; broad wearable coverage
Validic (validic)	US	Enterprise PGHD; EHR write-back gated
Human API (human_api)	US	Clinical + wearable aggregation
Junction (junction)	US	Wearables + US lab network
Metriport (metriport)	US	Open-source; consolidated FHIR + devices
Rook (rook)	Global	Wearable API; per-source revoke
Spike (spike)	Global	Wearables + Nutrition-AI
Thryve (thryve)	EU	EU-hosted medical-grade wearable API
WeFitter (wefitter)	EU	Gamification; per-profile connections
Vitalera (vitalera)	Global	FHIR-capable; HMAC webhooks
Open Wearables (open_wearables)	Self-hosted	Open-source; base_url required
Redox (redox)	US	EHR interoperability; FHIR R4
Particle Health (particle_health)	US	Clinical records via FHIR $everything
HealthConnect (healthconnect)	US	EHR + wearable; FHIR Observation
LexisNexis (lexisnexis)	US	Life-insurance underwriting; sales-gated

Note

Implementation depth varies per operation — some vendors implement fetch + authorize_url + handle_webhook + revoke, others only fetch. The per-vendor status table lives in src/health/vendor/README.md.

Device brands (device/)

Direct clients for consumer wearable brands — for deployments that talk to the brand instead of an aggregator:

Fitbit

fitbit — Fitbit Web API, OAuth 2.0. fetch (per-domain time-series), authorize_url, revoke, and signed handle_webhook (X-Fitbit-Signature) all implemented.

Withings

withings — Health Mate API, OAuth 2.0. fetch (form action services) and authorize_url implemented; webhook / revoke are stubs.

Garmin

garmin — Garmin Health API. Partner-gated and push-based; only revoke is wired. See the Garmin example.

Dexcom

dexcom — Dexcom API, OAuth 2.0. fetch (v3 egvs glucose, retrospective) and authorize_url (v2 /oauth2/login); defaults to the sandbox host.

Oura

oura — Oura API v2, OAuth 2.0. fetch (daily_activity / daily_sleep / heartrate) and authorize_url implemented.

Whoop

whoop — WHOOP Developer Platform v2, OAuth 2.0. fetch (activity/sleep, recovery [HR/HRV], cycle for strain), authorize_url, and the full token lifecycle (exchange_code / refresh) implemented; revoke / handle_webhook stay stubs — WHOOP documents no self-serve revoke endpoint.

Polar

polar — Polar Open AccessLink v3, OAuth 2.0. fetch (sleep — training/activity uses a transaction model), authorize_url, revoke implemented.

Note

Six pull-based brands ship first-party fetch implementations; which OAuth operations they support varies. Garmin is the exception: its partner API is push-based, and only revoke is wired here. Check each card and the source before designing a connection flow.

Clinical EHRs (ehr/) — SMART on FHIR

A single generic client (ehr) targets SMART App Launch + FHIR R4 servers, parameterized by each tenant’s FHIR base URL. Many US certified-EHR deployments expose this surface, but a working integration still needs the tenant endpoint, app registration, scopes, and whichever resources the organization enables.

• base_url is required and per-tenant (each hospital has its own FHIR service base URL); the client refuses to guess one.
• Auth is a SMART-on-FHIR OAuth 2.0 bearer token; fetch issues standard FHIR R4 Observation searches (patient + category + date range) and returns FHIR JSON.
• EhrDirectory can search public Service Base URL directories (ehr/directory.hpp): ONC Lantern and Oracle Health / Cerner’s published bundle. Discovery does not guarantee authorization or resource availability.

The browser-driven connect flow lives at /health/ehr/* — see Using Providers.

Phone health stores (phone/)

Vendor (id)	Notes
Huawei (huawei)	Huawei Health Kit Cloud REST API (Account Kit OAuth). fetch via sampleSet:polymerize; consent OAuth and subscription webhooks are stubs.

Note

Apple Health, Samsung Health, Google Health Connect, and Xiaomi / Mi Fitness are on-device-only — they expose no server API, so they are not vendor clients. The host apps read them on-device and POST FHIR Observations to the embedded FHIR endpoint. See Data Flow.

Data domains

Every vendor declares which normalized DataDomains it brokers, and fetch takes one:

Activity · Sleep · HeartRate · Glucose · Nutrition · BodyMetrics (weight, BMI, blood pressure, SpO2, …) · Labs · Clinical

Next steps

Using Providers

Configure credentials and link an account

→

Vendor System

The vendor::Vendor contract in depth

→

Garmin Example

A device-brand client against the contract

→

Provider Integration

Add a new source

→