Health data integration for fitness apps in 2026: build or buy

TL;DR

Health data integration for fitness apps in 2026 comes down to three routes: read Apple HealthKit and Android Health Connect directly, pay an aggregator such as Terra, or self-host an open-source aggregator. Direct integration costs engineering time and reads the phone's data for free. Terra starts at $399 a month on an annual plan and adds cloud wearables such as Garmin and Oura. We recommend direct integration for phone and watch data, an aggregator only when you need many cloud brands fast, and a data model you own either way.

• Google Fit APIs are supported only until the end of 2026; Health Connect and the Google Health API replace them.
• Health Connect reads only 30 days of history before the first permission grant unless you request the history permission.
• The FTC treats a fitness app that syncs with a tracker as a personal health record vendor with a 60 day breach notice duty.

Why every fitness app now needs a health data layer

Your users already own the sensors. IDC counted 145.7 million wearable devices shipped in the first quarter of 2026 alone, up 4.3% year over year, and forecasts 693.2 million units a year by 2030 (IDC). A fitness app that cannot read the watch, the ring or the scale looks broken next to one that can.

Reading that data is the price of admission for coaching, recovery scores and every AI feature on your roadmap. It also changes your legal status. The FTC says a fitness app that lets users enter their weight and sync a tracker is probably a vendor of personal health records under the Health Breach Notification Rule, even if some users never connect a device (FTC).

The decision is which route gets you there with a budget you can defend and a data model you still own in three years.

Two deadlines already on the 2026 calendar

Google is shutting down the Google Fit APIs, REST API included, at the end of 2026. New sign-ups closed on May 1, 2024. Google points mobile-first apps to Health Connect and web or server-to-server platforms to the Google Health API, which it describes as the next generation of the Fitbit Web API (Google, Google Health API). If any Android app in your portfolio still reads Google Fit, the migration belongs in this year's budget, not next year's.

The second date is European. The EU AI Act became applicable on August 2, 2026. Its transparency rules require that people are told when they are talking to a machine (European Commission). An AI coach that reads HealthKit data and chats with EU users now needs that disclosure in the product.

How we compared the three routes

One question per route: what does it cost you to get a user's steps, workouts, sleep and heart rate into your backend, and what do you give up to get it there.

• Coverage: which sources arrive, and whether the phone's own health store is one of them.
• Cost shape: engineering time up front, or a per-user fee that never stops.
• Control: who owns the schema, the tokens and the historical record.
• Constraints: what the platform vendor forbids, whichever route you pick.

Prices and platform rules come from the vendor pages linked in each section. Where a competitor page is the only source, we say so. Internal figures come from our own scoping records, aggregated. Any group with fewer than three data points is not published.

HealthKit, Health Connect and Terra at a glance

Route 1: direct HealthKit and Health Connect integration

This is the route we recommend first for connected fitness clients, whenever the data lives on the phone or the paired watch.

Apple's HealthKit gives your iOS app per-data-type read permissions. It wakes your app in the background when new samples arrive, and its anchored object query returns only what changed since the last sync, deletions included (Apple). Android's Health Connect is part of the operating system on Android 14 and higher and a Play Store app on Android 9 to 13, with permissions granted on the device rather than through OAuth (Google).

Best for: apps whose users mostly wear an Apple Watch, a Pixel Watch or a Galaxy Watch, and any product where the data model is a competitive asset.

Facts: no licence fee, no per-user fee, two native SDKs, one sync backend you own, and per-type permission prompts the user controls.

Strengths: you keep every token and every record, and no vendor sits between you and Apple or Google when a platform rule changes. Our Fitbit engagement has run since 2011 and continues now that the team is part of Google (Mercury Development).

The honest minus: cloud-only wearables such as Garmin or Oura do not appear unless the user syncs them into the phone's health store, and you carry the maintenance line every time iOS or Android changes.

Route 2: an aggregator API such as Terra

Terra, founded in 2020 and a Y Combinator W21 company, sells one API for wearable and lab data. Its own pages claim 500+ sources, standardised data across all of them, webhook delivery, and both HIPAA and SOC 2 Type II compliance (Terra). A competitor's audit of Terra's documentation counts roughly 90 direct server-to-server connections, with the rest arriving through the mobile SDK reading HealthKit and Health Connect (Sahha).

Best for: products whose users bring many cloud wearable brands and whose team needs data flowing in weeks, not quarters.

Facts: Quick Start from $399 a month billed annually or $499 monthly, 100,000 credits included, extra usage from $0.005 a credit, Health Scores from an additional $499 a month, signed Business Associate Agreement on the Enterprise plan only (Terra pricing).

Strengths: Terra handles OAuth, token refresh and provider quirks, and its Google Fit provider already reads Health Connect on-device, so the 2026 shutdown does not touch it (Terra docs).

The honest minus: your users' health data transits a third party, the bill scales with active users and events, and several popular providers still require your own developer credentials even through an aggregator (AIFitnessAPI).

Route 3: aggregator alternatives and self-hosting

Terra is the broadest hosted option, and it is not alone. ROOK, based in Spring, Texas, charges $399 a month for 750 active users and positions itself for clinical-adjacent and remote monitoring use cases rather than consumer fitness (ROOK). Sahha starts at $299 a month for 1,000 users and scores sleep and wellbeing from phone signal alone, which matters if most of your users own no wearable. Spike lists from $450 a month and was acquired by Raintree Systems in July 2026. Thryve, based in Berlin, hosts entirely in Europe from EUR 499 a month (Sahha).

Open Wearables is the open-source route: MIT licensed, self-hosted and free to run. Its maintainers put the SaaS market at $0.50 to $2 per connected user per month, so 10,000 users cost $5,000 to $20,000 a month with a hosted vendor and only infrastructure with a self-hosted one (Open Wearables). Sahha's July 2026 audit adds that the Open Wearables docs mark the Apple Health mobile SDK as coming soon and put compliance on the deployer.

Read all of these pages as marketing; each vendor's comparison ranks itself first. The useful signal is the shape of the trade. Hosted vendors sell time, self-hosting sells ownership, and neither removes the native work of reading the phone's own health store.

What the platforms will not let you do

Whichever route you pick, the platform owners set the rules and the aggregator inherits them.

• Health Connect reads only 30 days of records before your app's first permission grant. Older data needs the separate history read permission, and a reinstall resets the window (Google).
• HealthKit background delivery wakes your app at most once per chosen period, and step count on iOS is capped at hourly no matter what you request. Miss the completion handler three times and HealthKit stops waking you (Apple).
• Your app cannot tell whether a user denied HealthKit read access. From the app's point of view the data does not exist (Apple).
• HealthKit data may not be used for advertising or sold to data brokers, and it may not be shared with a third party unless that party also provides a health or fitness service to the user. The same page requires a privacy policy for any HealthKit app.
• App Review Guideline 5.1.3 repeats the advertising ban, and 5.1.1 requires apps in regulated fields to be submitted by a legal entity, not an individual developer (Apple).

One vendor blog states that HealthKit lacks a change-token pattern and recommends tracking sync position with local timestamps (Open Wearables). Apple's anchored object query is exactly that pattern. Timestamps miss deletions. Anchors do not. That detail separates a team that has shipped HealthKit from one that has read about it.

Compliance you own whichever route you take

An aggregator's certificate covers the aggregator. Your app is still the party the regulator writes to.

Under the FTC's Health Breach Notification Rule, amended in July 2024, a covered app must notify affected people without unreasonable delay and within 60 calendar days of discovering a breach, notify the FTC at the same time when 500 or more people are affected, and can face a civil penalty of up to $53,088 per violation. A disclosure to an ad platform without consent counts as a breach (FTC). Encrypted data that leaks is not a breach under the rule, which is a strong argument for encryption at rest in your own store.

If you serve employers, insurers or clinicians, HIPAA may apply through a business associate relationship, and your aggregator must sign a Business Associate Agreement. Terra offers one on Enterprise only. Mercury Development builds to HIPAA and GDPR requirements and ships SOC 2 aligned infrastructure, so contract terms and architecture are decided together at scoping rather than discovered at audit.

Which route fits your product

• Connected hardware with a companion app: direct HealthKit and Health Connect, plus your own Bluetooth layer. Our Tonal work covers iOS, Android and watchOS apps with Bluetooth and ANT+ sensors (Mercury Development).
• Coaching or habit app where users bring their own devices: direct integration first, an aggregator added for Garmin, Oura or WHOOP once users ask by name.
• Corporate wellness or insurance rewards with many cloud brands on day one: an aggregator with a signed BAA, and your own data model behind it so the vendor can be swapped.
• A team past product-market fit that resents the per-user bill: self-hosted open source, staffed for on-call, with the native health-store work still done by your mobile engineers.

What our own fitness inquiries say about integration scope

We reviewed the fitness and wellness opportunities in our own pipeline records, aggregated and anonymised, and asked how often health data integration appears as a hard requirement.

• Around 15% named Apple HealthKit, Apple Health, Google Fit or Health Connect explicitly in the brief, usually as a line item next to a hardware or watch requirement.
• Around 15% named third-party feeds by brand: Fitbit, Garmin Connect, Strava, MyFitnessPal or a glucose monitor.
• Buyers wrote the requirement in implementation terms. One brief asked for stable HealthKit and Fitbit integration specifically for calorie burn from watches. Another listed five named platforms to pull data from into one place.
• The defect pattern on inherited apps was consistent: Health Connect data shown without validation, including active calories that looked wrong and sleep stages that should not have been displayed.

Buyers do not want a vague sync feature. They want the feeds they named, and they judge the vendor on how each one will be validated.

The integration is rarely the hard part

Every route above gets steps into a database in a few weeks. What decides whether the product survives is what you do with them afterwards.

Terra normalises. Open Wearables normalises. HealthKit and Health Connect hand you raw samples with source attribution. In every case somebody has to decide what a day's active calories means when the watch, the phone and a treadmill each report a number. Aggregators hide that decision inside their schema, which is convenient until the vendor changes it or you change vendor.

Our position: own the canonical model from day one. Store raw samples with their origin, compute your own daily aggregates, and treat any aggregator as a transport you can replace. Since 1999 we have rebuilt more than one app whose previous vendor handed over less than the owner needed, and the rebuild always costs more than the sync layer did. With 500+ engineers and 50M+ users on apps we have built, the integrations were never the expensive part. The ownership was.

Written by Alexey Rodionov, Lead Front-end Developer at Mercury Development. Alexey has led front-end development at the firm since 2020 and is a Google Developer Expert in Web Technologies. The platform limits and integration trade-offs compared in this article were tested in the practice he leads or traced to the vendor documentation cited here.

Scoping a health data integration? Get the route and the budget before the sprint starts

You know which devices your users own and which feeds your product needs. We turn that into a route, a phased plan and a budget you can put in front of your board. Tell us your platforms and the data you need, and we will come back with the plan and the questions we would ask before writing code.