RPM Device Aggregation APIs: Terra vs Validic vs Open Wearables vs Native Integration

TL;DR

Aggregation APIs normalize data from 200-600+ wearable devices into a single pipeline, compressing 20-40 weeks of per-vendor integration into 1-2 weeks. Terra ($3.3M funding, YC W21, 500+ sources) is fastest for startups building consumer health apps. Validic ($31.6M funding, 600+ devices, Epic integration) is built for enterprise health systems. Momentum’s Open Wearables (MIT-licensed, launched December 2025) eliminates vendor lock-in. Apple HealthKit is free but mobile-only. Each option trades something. The right choice depends on whether you need clinical-grade data, EHR connectivity, developer speed, or zero vendor lock-in.

We evaluated Terra, Validic, and native Apple HealthKit integration for a multi-wearable RPM platform build last year, and the decision came down to a question none of the vendor marketing addresses: what happens to the data after the aggregation layer delivers it?

Every aggregation API solves the same upstream problem: instead of building separate integrations for Dexcom, Abbott, Apple HealthKit, Fitbit, Oura, Garmin, and Withings, you connect once to an aggregation layer and receive normalized data from all supported devices. That is genuinely valuable. Ten vendor integrations at 2-4 weeks each is 20-40 weeks of engineering. One aggregation integration is 1-2 weeks.

But the aggregation layer delivers raw or semi-structured data. It does not interpret it clinically. It does not detect trends across devices. It does not generate composite risk scores. It does not route alerts to the care team. It does not write FHIR Observations to the EHR. The clinical value is created downstream, in the platform layer that sits on top of aggregation. Understanding what each aggregation option delivers (and what it leaves for you to build) is the real architecture decision.

What Problem Do Aggregation APIs Solve?

A multi-device RPM platform needs data from multiple manufacturers. Each manufacturer has a different API, different authentication (OAuth, API key, SDK), different data format (JSON structures vary), different sampling rates (Dexcom every 5 minutes, Libre every minute, Oura hourly), and different delivery methods (webhook, polling, SDK callback).

Native integration means building and maintaining each connection independently. For 5 vendors, that is manageable (we did it for Hearty). For 10 or more, the engineering cost becomes a significant line item. Two to four weeks per vendor for initial integration, plus ongoing maintenance as vendors update their APIs.

Aggregation APIs eliminate this by providing a single connection point. Your platform connects to the aggregation layer once. The aggregation layer maintains connections to all supported device vendors. When a patient’s Dexcom sends a glucose reading or their Withings scale sends a weight, the aggregation layer normalizes it and delivers it to your platform in a consistent format.

The trade-off: you add a dependency between your platform and your data. If the aggregation vendor has an outage, your data stops. If they change their pricing, your costs change. If they deprecate support for a device vendor you rely on, you scramble.

Visual Brief #1: Two architecture diagrams side by side. Left: “Native Integration” showing 10 device vendor APIs each connecting individually to RPM Platform (10 connections, 10 auth methods, 10 data formats). Right: “Aggregated” showing 10 device vendors connecting to Aggregation API, which connects once to RPM Platform (1 connection, 1 format). Title: “Native vs Aggregated Device Integration.” File name: rpm-native-vs-aggregated-integration.png. Alt text: “Architecture comparison showing native integration requiring 10 separate device vendor connections versus aggregation API providing a single normalized data feed from all vendors.” Sizes: 1200×600 blog, 1080×1080 social.

Terra API: Fast, Developer-Friendly, Fitness-First

Company profile: Founded 2021, London. Y Combinator W21 batch. $3.3M funding from Y Combinator, General Catalyst, Samsung NEXT. Approximately 25 employees (Crunchbase).

What it does: Health and fitness API providing access to data from 500+ sources including Apple HealthKit, Google Health Connect, Garmin, Fitbit, Oura, WHOOP, Samsung, Polar, Dexcom, Libre, and Withings. Mobile SDKs in Swift, React Native, and Flutter for HealthKit integration. Data delivered via webhooks or destination connectors.

Technical strengths:

• FHIR-native data format from day one. Data arrives in a structure compatible with healthcare interoperability standards
• Best developer documentation we have encountered in this category. Clear, well-organized, with working code examples
• Integration time: days, not weeks. We had a proof-of-concept pulling HealthKit data within 48 hours of account creation
• Webhook-based delivery: data pushes to your platform automatically when new readings arrive. No polling required
• Pricing is usage-based and competitive for startups. No enterprise contract required to start

Where it falls short for RPM:

• Clinical device depth is moderate. Terra excels at consumer wearables (Fitbit, Garmin, Oura, Apple Watch) and major CGMs (Dexcom, Libre). Clinical-grade medical devices (Tenovi cellular cuffs, BodyTrace scales, Nonin pulse oximeters) are not covered. If your RPM program uses clinical-grade cellular devices, Terra cannot replace native integration for those devices
• No EHR integration product. Terra delivers data to your platform. Getting that data into Epic or Cerner is your engineering problem
• Smaller team (25 employees) means less enterprise support infrastructure. Suitable for developer-led startups. May not meet enterprise SLA requirements for large health systems
• No AI or clinical intelligence layer. Terra delivers raw data. Trend analysis, risk scoring, and alert generation are downstream

Best for: Series A-B digital health companies building consumer-facing wellness or RPM apps. Development teams that prioritize API documentation quality and integration speed over clinical depth.

Visual Brief #2: Terra profile card. Logo, funding ($3.3M YC W21), devices (500+), tech (FHIR, webhooks, mobile SDK), best for (startups, consumer health), weakness (no EHR, clinical depth moderate). Title: “Terra API Profile.” File name: terra-api-profile-card.png. Alt text: “Profile card for Terra API showing $3.3M YC funding, 500+ device sources, FHIR-native data format, and best fit for startups building consumer health applications.” Sizes: 600×400 blog sidebar.

Validic: Enterprise, Clinical, EHR-Integrated

Company profile: Founded 2010, Durham, North Carolina. $31.6M total funding across 8 rounds from 15 investors. Approximately 70-130 employees (Crunchbase, varies by source).

What it does: Health IoT platform with two distinct products. Product 1: wearable data API for digital health companies (similar to Terra but with clinical device support). Product 2: EHR-integrated remote patient monitoring solution with patent-pending generative AI summaries for health systems and payers. Showcased both products at HLTH 2025 (Validic, October 2025).

Technical strengths:

• Deepest device coverage: 600+ connected devices including clinical-grade medical devices AND consumer wearables. This breadth is unmatched
• Built-in Epic integration. Validic’s EHR connector pushes device data into Epic as structured clinical observations. This is the feature that positions Validic differently from every other aggregation API
• Patent-pending AI-powered clinical summaries that transform raw device data into clinician-ready insights
• 15-year track record. Founded in 2010, Validic has been operating longer than most competitors have existed
• Enterprise support infrastructure: dedicated customer success, SLA commitments, compliance documentation (SOC 2, HIPAA BAA)

Where it falls short:

• Slower integration than Terra. Enterprise sales cycle, onboarding process, and configuration take weeks to months
• Enterprise pricing. Per-patient or per-connection contracts that scale linearly with patient volume. For a 50-patient startup, this may be cost-prohibitive relative to Terra
• More complex onboarding than developer-first platforms. Validic is built for procurement teams, not individual developers
• Less developer-community presence (no Y Combinator network effect, fewer open-source contributions, less Stack Overflow visibility)

Best for: Health systems deploying RPM at scale with Epic or Cerner. Enterprise digital health companies needing clinical-grade data plus EHR connectivity. Life sciences and pharma companies running device-based clinical trials.

Visual Brief #3: Validic profile card. Logo, funding ($31.6M), devices (600+), tech (EHR integration, AI summaries), best for (enterprise health systems, Epic customers), weakness (enterprise pricing, slower onboarding). Title: “Validic Profile.” File name: validic-profile-card.png. Alt text: “Profile card for Validic showing $31.6M funding, 600+ connected devices, Epic EHR integration, and best fit for enterprise health systems deploying RPM at scale.” Sizes: 600×400 blog sidebar.

Momentum’s Open Wearables: Open-Source, Zero Lock-In

Company profile: Momentum launched Open Wearables in December 2025 as an MIT-licensed, open-source platform (Momentum, December 2025).

What it does: Normalizes raw wearable data from 200+ devices into AI-ready schemas. MIT license means full source code access with no vendor lock-in. Supports Apple HealthKit, Garmin Health API, Fitbit, Oura, WHOOP, Strava, and growing.

Why it matters for the RPM space:

• Zero vendor lock-in. If you build on Terra or Validic and they change pricing, deprecate a device, or get acquired, your data pipeline is at risk. With Open Wearables, you own the code. Fork it, customize it, host it yourself
• AI-ready data schemas. The normalized output is designed for machine learning pipelines, not just dashboard display. For RPM programs that want to build proprietary AI models on wearable data (personalized baselines, exacerbation prediction), this schema design matters
• No per-connection fees. At 5,000 patients, the cost savings versus Validic’s per-patient pricing could be substantial

The honest caveats:

• Launched December 2025. Five months in production as of this writing. Less battle-tested than Terra (4 years) or Validic (15 years). Production bugs, edge cases, and scaling limits are still being discovered by early adopters
• 200+ devices versus 500-600+ for Terra and Validic. The coverage is growing but currently narrower
• No EHR integration out of box. Like Terra, getting data into Epic or Cerner is your engineering problem
• No enterprise support. Community-supported (GitHub issues, Discord). If you need a vendor on a phone call at 2 AM when data stops flowing, Open Wearables is not that
• Requires an engineering team to host, maintain, monitor, and update. This is not a SaaS product. It is infrastructure you operate

Best for: Engineering teams that want full control over the data pipeline. Organizations with vendor lock-in concerns (common in health systems that have been burned by vendor acquisitions). Research institutions that need open, modifiable data schemas. Companies building proprietary ML pipelines on top of wearable data.

Visual Brief #4: Open Wearables profile card. Logo, license (MIT open-source), devices (200+), tech (AI-ready schemas, self-hosted), best for (engineering teams, research, zero lock-in), weakness (new, no support, self-managed). Title: “Open Wearables Profile.” File name: open-wearables-profile-card.png. Alt text: “Profile card for Momentum’s Open Wearables showing MIT open-source license, 200+ devices, AI-ready schemas, and best fit for engineering teams wanting zero vendor lock-in.” Sizes: 600×400 blog sidebar.

Native Integration: Apple HealthKit and Google Health Connect

Apple HealthKit and Google Health Connect are not aggregation APIs in the traditional sense. They are native operating system frameworks that aggregate health data from apps and devices connected to the patient’s phone.

Apple HealthKit aggregates data from Apple Watch, CGMs (Dexcom, Libre), BP cuffs (Omron, Withings), scales (Withings), sleep trackers, and 300+ third-party health apps. FHIR-native through Apple Health Records. Free. No API cost. Accessible via Swift SDK or React Native bridge.

Google Health Connect does the same for Android: Fitbit, Samsung, Garmin, Oura, 100+ Android health apps. Free. Accessible via Android SDK.

When native is enough:

• Your RPM program already has a patient-facing mobile app
• Patients already own and use Apple Watch, Fitbit, or CGM
• You want zero aggregation cost
• You accept mobile-only data access (no server-side API pull without a middleware layer)

When native is not enough:

• You need server-side data processing without a patient-facing app
• You need clinical-grade medical devices not connected to HealthKit (cellular BP cuffs, cellular scales)
• You need multi-platform support (iOS and Android) through one integration
• You need guaranteed data delivery (HealthKit depends on patient granting and maintaining permissions)

For many RPM programs, the practical approach is hybrid: HealthKit as the primary data source for patients with Apple Watch and CGM, supplemented by Terra or Validic for devices not in the HealthKit platform, and native integration for clinical-grade cellular devices.

Head-to-Head Comparison

The comparison that matters most for RPM specifically: clinical device depth and EHR connectivity. If your RPM program uses clinical-grade devices (cellular BP cuffs, medical pulse oximeters, clinical scales) and needs data in Epic, Validic is the only option that covers both natively. Terra and Open Wearables require you to build the clinical device integration and EHR connectivity yourself.

Start a Conversation about which aggregation strategy fits your RPM platform architecture.

Visual Brief #5: Full comparison table (above) styled as a designed visual with color-coded cells. Green for strengths, yellow for adequate, gray for not available. Title: “Device Aggregation APIs: Head-to-Head for RPM.” File name: rpm-aggregation-api-comparison-table.png. Alt text: “Full comparison table of Terra, Validic, Open Wearables, and HealthKit across 12 factors including device count, FHIR support, EHR integration, pricing, and best-fit use case for RPM platforms.” Sizes: 1200×700 blog, 1080×1350 social.

How Does WearConnect Fit Into This?

WearConnect is not an aggregation API competitor. It is a device normalization layer that sits downstream from aggregation, solving a different problem.

Aggregation APIs solve: “How do I get data from 10 device vendors into my platform?”

WearConnect solves: “Now that the data is in my platform, how do I make clinical sense of it?”

The architecture stack:

Devices → Aggregation (Terra / Validic / HealthKit / Native)
       → WearConnect (normalize, align, gap-fill)
       → RPM Platform (clinical logic, alerts, dashboards)
       → EHR (FHIR Observations via HealthConnect CoPilot)

What WearConnect handles that aggregation APIs do not:

• Timezone reconciliation across multi-state patient populations (a patient travels from Eastern to Central timezone, their readings shift by an hour, trend analysis breaks without timezone normalization)
• Sampling rate alignment (Libre sends readings every 1 minute, Dexcom every 5 minutes, Oura sends hourly summaries, weight scale sends once daily: all need to be in one timeline)
• Gap-filling interpolation (when a device loses connectivity for 4 hours, the gap in the time-series needs interpolation so trend analysis doesn’t treat it as a sudden drop)
• Clinical alert logic on the normalized multi-device data stream (composite risk scoring across vitals from different devices)

For the Hearty build, we used native HealthKit plus direct Dexcom API plus Oura API plus Withings API. Five data sources, no aggregation API. WearConnect normalized the five streams into a single patient biometric view. The aggregation was native (5 vendors was manageable). The normalization was WearConnect.

For programs supporting 15+ device types, the recommended stack is: aggregation API (Terra or Validic depending on clinical requirements) plus WearConnect for normalization plus HealthConnect CoPilot for EHR delivery.

Visual Brief #6: Architecture diagram. Three layers: Bottom (Device Layer: 10+ device vendors). Middle (Aggregation Layer: Terra or Validic or Native). Top (Normalization Layer: WearConnect → Clinical Logic → Care Team Dashboard → EHR). Arrows show data flow upward. Labels clarify what each layer does. Title: “The Full Stack: Aggregation + Normalization + Clinical Logic.” File name: rpm-aggregation-normalization-full-stack.png. Alt text: “Three-layer architecture diagram showing device vendors feeding into an aggregation layer (Terra, Validic, or native), which feeds WearConnect normalization, clinical logic, and EHR delivery for a complete RPM data pipeline.” Sizes: 1200×600 blog, 1080×1080 social.

The Decision Is What You Do With the Data, Not How You Get It

Aggregation APIs solve data collection. They do not solve data interpretation. The clinical value of RPM is created in the platform layer that sits on top of aggregation: trend analysis, anomaly detection, composite risk scoring, alert generation, care team routing, and EHR delivery.

The decision framework:

Need the data fast, building a consumer app: Terra. Best documentation, fastest integration, startup-friendly pricing.

Need the data in the EHR, running an enterprise RPM program: Validic. Epic integration built in, clinical device depth, enterprise support.

Need zero vendor lock-in, have an engineering team: Open Wearables. MIT-licensed, self-hosted, AI-ready schemas. Accept the maturity trade-off.

Patients already own Apple Watch or CGM: Start with HealthKit. It is free and already aggregating. Add Terra or Validic when you outgrow HealthKit’s limitations.

Supporting 5-8 device vendors with engineering capacity: Consider native integration. We did this on Hearty with five vendors and found the direct API connections gave us more control over data quality than the aggregation layer would have. Aggregation becomes essential when device count exceeds 8-10 vendors.

We initially assumed we needed an aggregation API for every multi-device build. On the Hearty project, native integration produced better results because we controlled the data quality at each vendor connection. The assumption was wrong. Aggregation is the right choice at scale (10+ vendors). Below that threshold, native integration often produces higher data quality because you control each connection.

If you are evaluating aggregation APIs for your RPM platform and want to know which ones we have built with and what broke in production, reach out. The integration stories are more useful than the comparison tables.

Start a Conversation about RPM device aggregation architecture.