Wearable Data APIs for Corporate Wellness Programs

An employer wellness program does not choose its devices. Employees bring whatever they already wear, the employer may manage some of their phones, and the employer must never see any one person's health data. In our reading, those three constraints decide the data source. This page covers that decision only; challenges, rewards, the HR dashboard and the legal tracks are in our guide to building a corporate wellness app.

Start from the device mix#

Our build guide lists what employees show up with: Fitbits, Garmins, Apple Watches, Ouras, WHOOPs, Samsung devices and phone step counters, each with its own API, auth and data model. Unless the program issues the device, you inherit the whole list.

Our recommendation: before writing integration code, ask the pilot employer which devices employees wear and whether company phones are enrolled in device management. The first answer picks your route. The second can rule one out.

Three routes to the data#

The routes stack. Our health-data aggregator comparison notes that aggregators typically sit on top of the other two, with mobile SDKs that pull from HealthKit and Health Connect and servers that pull from vendor cloud APIs. Our wearable data API comparison found that each vendor API returns data only for individual users who authorize your app, and none is a bulk or population feed. Enrollment is an authorization flow every employee completes, not a workforce-wide switch.

Access gates to clear before a pilot#

The Fitbit row is from Google's pages as of October 12, 2026, and the Garmin row from Garmin's program FAQ as of October 17, 2026. The Oura, WHOOP and Polar rows are from our July 2026 checks; confirm them in current vendor docs.

Fitbit: the Web API turns off on October 30, 2026#

As of October 12, 2026, Google's Google Health API overview lists September 30, 2026 as the end of support, after which the Fitbit Web API keeps operating but Google no longer fixes bugs or provides API support. On October 30, 2026 the Fitbit Web API "will be turned off and will no longer function or sync data to or from Fitbit users." Its successor is the Google Health API.

Google's migration guide says existing tokens cannot be transferred, requiring users to re-consent. So every Fitbit participant authorizes your app again, and in our reading anyone who does not stops counting toward challenges. Google also categorizes all Google Health API scopes as Restricted, which means a privacy and security review before access.

Our recommendation: if your program still reads the Fitbit Web API, migrate and plan the re-consent campaign now, and keep challenge scoring windows on the old integration clear of October 30. If an aggregator supplies your Fitbit data, ask how its connection moves and whether participants must reconnect; we have not verified any aggregator's answer. Our Fitbit Web API to Google Health API migration guide covers the mechanics.

Garmin: approval first, Starter or Enterprise#

Garmin must approve your application before you receive any API credentials. Its program FAQ, read on October 22, 2026, describes Starter and Enterprise Access and says that once your request is approved you get the Garmin Developer Portal; it no longer states a review time. Garmin's Health API page names corporate wellness among the markets it serves. For a program that issues devices, the FAQ says to request the program and contact Garmin through its inquiry form with details of your project. Garmin's overview gives Starter Access limited user capacity and Enterprise Access unlimited user capacity, with commercial terms tailored to business and technical requirements, so an employer-scale rollout should expect to talk to Garmin about Enterprise. Earlier versions of this section passed on community reports that new sign-ups were on hold; Garmin's own pages do not say that. Confirm the status on developer.garmin.com before you promise Garmin support to an employer.

An aggregator may not remove this gate. One that holds its own Garmin partnership can resell access, but our aggregator comparison lists Garmin among the providers where you commonly must bring your own developer or partner credentials. Ask each shortlisted aggregator which applies before counting Garmin wearers as covered.

Company iPhones: MDM can switch HealthKit off#

Apple's documentation for errorHealthDataRestricted says "A Mobile Device Management (MDM) profile restricts the use of HealthKit on this device," and notes that such a profile can disable HealthKit on a managed device. Nothing in your app lifts the restriction. Only whoever administers the device can.

In the wellness case, the employer pushes your app to managed phones, the same profile may have HealthKit disabled, and every HealthKit-based data path is dead for that group while it works in your testing. In our reading that includes an aggregator's mobile SDK, which pulls from the same store, while a server-side connection to a wearable vendor's cloud account does not touch HealthKit. We have not verified whether Android device management affects Health Connect the same way, so test managed Android phones too.

Our recommendation: ask the employer whether HealthKit is allowed on its managed devices, give its administrator a short note on what your app needs, test on one of their phones before launch, and keep manual logging as the fallback. HealthKit restricted by MDM covers detection and user messaging.

Employer visibility is a routing rule#

Our build guide treats aggregate-only, de-identified reporting to the employer as an architecture requirement, with small groups suppressed and no drill-down that exposes one person. The legal tracks behind it are in the corporate wellness build guide. This is general information, not legal advice. Confirm your program's obligations with counsel.

In our reading, that sets two routing rules. Per-person samples from any route land in a participant-scoped store that no employer-facing screen, export or report can query. Aggregation runs in your own layer, after small-group suppression, and only participation, engagement and category-level results cross to the employer. No route does this for you, because what the employer may see is a policy decision specific to your program.

Which privacy rules can reach a wellness vendor#

The FTC's Mobile Health Apps Interactive Tool asks whether you are "developing, offering, or operating an app on behalf of a HIPAA covered entity (such as a hospital, doctor's office, health insurer, or health plan's wellness program)", and says that if so, you likely are a HIPAA business associate. Outside HIPAA, the FTC's Health Breach Notification Rule can apply: the FTC's guidance says a fitness app that can sync with wearable fitness trackers is likely a vendor of personal health records, even if some users never connect a tracker. Our pages on HIPAA for fitness apps, the FTC breach rule and Washington's My Health My Data Act cover each test. This is general information, not legal advice.

HR systems are a separate integration#

Rosters and eligibility come in from the employer's HR side, and single sign-on from its identity provider. Wearable data comes in from each employee, on that employee's own consent. Aggregate engagement goes back out, plus incentive payouts if the program pays them. We have not evaluated HRIS or benefits-platform integrations and make no claims about them.

Our recommendation is to keep the two inbound pipes apart in your schema. The roster says who may join, the wearable connection says what a participant did, and on the employer side the two meet only as an aggregate.

Our recommendation by situation#

• Mixed devices across the workforce → one aggregator. Shortlist from Terra, Vital/Junction, Rook and Spike. For each provider your employees use, check whether the aggregator needs your own credentials, and ask how it handles the Fitbit turn-off. Advertised device counts are marketing figures, so test coverage against the employer's actual device list, and compare cost models on our aggregator pricing page.
• One issued device → that vendor's API. Confirm access first against the gate table above, Garmin approval and the Google Health API review especially.
• Phone-only step challenge → HealthKit plus Health Connect. First find out whether company phones are managed and whether HealthKit is allowed on them. Where it is not, those employees need manual logging or a wearable connected through its vendor's cloud.