The Wearables Interoperability Stack
A field guide to the aggregators providing the wrist-to-API layer and why so many exist without a regulatory floor
Interoperability is just a series of workflows in a trenchcoat. The overloaded buzzword contains multitudes - all sorts of cross-organizational exchanges, some of which are fully ubiquitous in digital form and others that are totally analog.
Patient access has a clinical side and a wearables side. The clinical side gets all the regulatory attention: data standards, HIPAA Right of Access, ONC certification, information blocking enforcement. The wearables side gets none of it. Yet it’s not a barren wasteland and hellhole of data exchange. On the contrary, the wearables side supports twice as many aggregators across hundreds of devices!
So let’s break it down, as we've covered wearables aggregators only in passing before in “The API Bible’s New Testament: Aggregators”:
Lastly, a number of wellness aggregators have emerged, connecting to Fitbits, Ouras, and a variety of other devices in order to aggregate and standardize the sleep, activity, and fitness metrics produced by the wide variety of wearables and trackers on the market today. Validic and HumanAPI were the first to build support here, but new players Terra, ROOK, Metriport, WeFitter and Vital purport to offer lower prices and superior developer experience.
The Fundamentals
Mechanically, these all work like Plaid:
The app embeds the aggregator’s connection widget
The user authenticates with their device platform (Fitbit, Oura, Garmin, etc.)
The app retrieves normalized, deduplicated data via the aggregator’s API.
The aggregator handles token management, polling the upstream source, normalizing across vendors, and delivering clean output via webhook or REST. Most also offer a mobile SDK for Apple HealthKit and Android Health Connect, which require on-device code rather than a server-to-server OAuth flow.
From a data perspective, it’s the logical counterpart to patient access aggregators (b.well, HealthEx, Flexpa, and Fasten Health) detailed in The Rise of Consumer Health On-Ramps. In both markets, the value prop is identical: hide health data fragmentation behind a single integration after consumer authentication. But instead of EHRs as the source and clinical data like problems, medications, allergies, labs, and notes, the wearables side normalizes data generated from the full spectrum of normie wearables and mobile apps to heavy duty clinical devices for chronic conditions, including things like:
Activity and movement: steps, workouts, VO2 max, GPS traces
Cardiovascular signals: resting heart rate, HRV, ECG, blood pressure, afib notifications
Sleep: stages, efficiency, breathing disturbances
Respiratory and oxygenation: SpO2, respiratory rate
Body composition: weight, body fat, hydration from connected scales
Metabolic and glucose: CGM streams from Dexcom and Libre, insulin pump records
Reproductive and hormonal: cycle tracking, basal body temperature, fertility windows
Stress and recovery scores: Whoop strain, Oura readiness, Garmin Body Battery, each calculated differently
Nutrition: logged meals and macros from MyFitnessPal and the like
Clinical device output: smart inhalers, home INR monitors, connected peak flow meters
Who's Selling Shovels
Human API and Validic were the OGs. Both got started in the early-to-mid 2010s when the original wave of consumer wearables (Fitbit, Jawbone, the first Apple Watch) created the integration problem in the first place, and both built their initial businesses on the same insight: digital health startups and life insurance carriers would pay to skip the per-device integration work.
The market has churned in predictable ways, though.
Human API got acquired by LexisNexis Risk Solutions in 2023 and pulled into the life insurance underwriting orbit, effectively exiting the digital health developer market.
Validic split its offering in two: a wearable data API for consumer apps on one track, and an Epic-integrated RPM solution for health systems on the other (a tell about where the actual revenue lives).
The second generation of wearables APIs that emerged to compete with the OGs on developer experience and pricing has evolved too:
Metriport exited wearables and pivoted hard toward the health information exchange on-ramp business.
WeFitter’s change log went quiet in 2023.
Vital rebranded to Junction, repositioning by bundling a first-class lab ordering product as a combined healthcare infrastructure play.
Terra has leaned into a premium developer experience, offering a variety of modalities (REST, GraphQL, streaming, MCP)
ROOK is similar to Terra, but has notable Latin American traction.
Thryve has built a meaningful European footprint, reaching 50M+ end-users through partnerships with insurers and clinical trials.
A newer wave is taking angles the originals didn’t:
Vitalera is a newer EU-based entrant focused on RPM for chronic respiratory disease and GLP-1 weight management programs
Sahha leaned into smartphone-native passive sensing and app connections only, although wearables now are marked as ‘Coming Soon’.
Open Wearables came out of the Polish development firm Momentum as an open-source, self-hosted alternative.
Why So Crowded?
Upon reflection, what's striking is how busy this segment is compared with its clinical patient access counterpart. The clinical side has numerous regulatory tailwinds (HIPAA Right of Access, certification program requirements, and information blocking) and supports the aforementioned four main aggregators.
Given the wearables side has literally none of that regulatory scaffolding, you’d expect a “there be dragons here” sign in such lawless hinterlands without data standards. Instead, we see a landscape of voluntary developer programs across devices and platforms supporting roughly double the aggregator vendor count! What gives? A few theses come to mind to explain the inversion:
Population mismatch. The people who buy wearables and the people who use digital services are largely the same cohort: affluent, engaged, opinionated about their data. There’s an inherent tech literacy by default. On the clinical side, an EHR’s patient panel is whoever the health system happens to treat, which rarely maps cleanly to any given app’s target user. Wearables aggregators need access for a population that pre-selected into caring, but clinical aggregators need access for a more diverse population that just happened to get sick somewhere.
Aligned incentives on the wearables side. Wearables are bought, registered, and proudly owned by their users, who expect the device’s data to flow into other apps and services. Platforms respond accordingly, treating third-party developers as a growth channel and shipping modern, well-documented APIs. Clinical data has no equivalent consumer-pull dynamic. It lives in enterprise software sold to health systems, where third-party access is a risk to manage, not a channel to cultivate. The APIs reflect it.
Substitutes on the clinical side. Digital health apps that need clinical data can route through treatment-use-case HIE on-ramps like Health Gorilla, Particle, Zus, Metriport, or Connective Health, accessing data via Carequality and Commonwell without the friction of a portal log-in or identity proofing. Wearables aggregators have no equivalent, as no provider-mediated network today hands you Whoop or Oura data without the user authenticating (although maybe that changes as they lean into clinical care).
Source diversity. Niche coverage can unlock buyer segments that broad coverage can't reach. Clinical patient access is Pareto-distributed: integrating top EHRs gets you most patients as a commodity offering, while specialty EHRs (oncology, behavioral health, LTC) often aren't ONC-certified and therefore don't expose USCDI via FHIR, making them inaccessible regardless of demand. Wearables face the opposite shape: a long tail of devices where each niche integration unlocks new use cases (remote patient monitoring, longevity, metabolic health, endurance training, life insurance, clinical trials).
International market. Wearables data is global by default. ROOK, Vitalera, Sahha, and Thryve all have non-US origins or strong international focus. Clinical patient access is much more US-bound because of how regulatory-specific the data sources are.
Winners-Take-Some
Now I bet you’re thinking to yourself, “Okay, Brendan, that’s all great, but which one is best?” Unfortunately, I am here to disappoint you. As with almost all infrastructural tools (EHRs, HIE on-ramps, payment processors) in a competitive market with limited moats, these various products are functionally substitutable at a base level, so the “best” for one buyer may be the worst for another.
What separates them is fit to the unique prerogatives and needs of each buyer. Whether a buyer is underwriting life insurance, running an RPM program for chronic care, or enrolling participants in a decentralized clinical trial drastically impacts priorities across key domains:
Coverage: The aggregator will need to match the matrix along two axes: normalized data types (steps, HRV, sleep stages, CGM, etc.) across supported devices (Apple Watch, Oura, Whoop, Dexcom, etc.)
Cost: A consumer app's propensity to pay is dramatically lower than an RPM platform billing CPT codes or a life insurance carrier pricing a policy.
Developer experience: A consumer app team will tolerate (and prefer) a REST-and-webhooks setup, while a clinical trial sponsor may want flat-file batch delivery into their data warehouse.
Consumer experience: The connection widget is the only part of the aggregator the end user ever sees, so polish and branding flexibility may matter significantly (such as a fitness app) or very little (life insurance carrier doing one-time data pulls)
Geography: A US-only life insurance carrier doesn't care about GDPR, while a European clinical trial sponsor cares about nothing else
For aggregators, coverage is typically key, per Maslow’s API Hierarchy because it’s the only dimension where a gap can’t be worked around. Clunky docs, a bad API, or higher fees are all tolerable. A missing device or data type is not.
