AppMatic Tech designs multi-vendor wearable data integrations, connecting the Google Health API, WHOOP, Oura, Polar, Apple HealthKit, and Android Health Connect to Node.js and Laravel back ends and Swift, Kotlin, or Flutter apps. AppMatic Tech is based in Ahmedabad, India, with 330+ products shipped since 2017 and six BLE device integrations.
Any product that reads data from wearables the user already owns, such as a coaching app, a corporate wellness platform, a clinical study tool, or an AI health assistant, depends on vendor APIs it does not control. In 2026, those APIs changed faster than in any previous year. Google turns off the Fitbit Web API on October 30, 2026 and ends the Google Fit APIs at the end of 2026. Oura removed personal access tokens and published a new API agreement with strict AI terms. Garmin's application form for new API access went offline. This comparison sets out where each platform stands and how to choose.
Key takeaways
Choose wearable APIs by audience, access rules, and terms, not by feature lists.
| Point | Detail |
|---|---|
| Cloud and device APIs differ | Cloud APIs let a server read data; on-device stores need the phone app to upload it. |
| Approval caps launches | Google caps unverified apps at 100 users, WHOOP starts at 10, Oura at 10. |
| Memberships gate data | WHOOP requires membership by design; Oura requires it for Gen3 and newer rings. |
| AI terms now matter | Oura's June 2026 agreement routes LLM use through Oura's own MCP server. |
| Garmin is uncertain | The new-application form has been unavailable since spring 2026. |
| One internal model wins | Adapters per vendor, mapped into one data model, keep vendor changes contained. |
What changed for wearable data access in 2026?
| Platform | 2026 change |
|---|---|
| Google (Fitbit and Pixel) | Fitbit Web API support ended September 30, 2026; the API is turned off October 30, 2026. The Google Health API replaces it, with Google OAuth 2.0 and restricted scopes. |
| Google Fit | Google states the Google Fit APIs are supported only until the end of 2026, with Health Connect and the Google Health API as replacements. |
| Oura | Personal access tokens were deprecated in December 2025. A new API agreement took effect on June 8, 2026, with AI-use restrictions. |
| WHOOP | The v2 API is current and v1 webhooks have been removed. |
| Garmin | The Connect Developer Program's form for new API access requests has been unavailable since spring 2026, according to a Garmin forum reply. |
The common thread is tighter control: vendors are adding review steps, user caps, and usage terms. Products that integrate wearables need to treat each vendor as a dependency with its own release calendar.
How do the major wearable health data APIs compare?
| Platform | Type | Sign-in | Limits before approval | Ongoing obligations | Status in October 2026 |
|---|---|---|---|---|---|
| Google Health API | Cloud, REST and gRPC | Google OAuth 2.0 | 100 users until verified | Annual CASA security assessment; in-app health data disclosure | Active; replaces the Fitbit Web API |
| WHOOP API v2 | Cloud, REST | OAuth 2.0 | Sandbox tier of 10 members, then Build 100, Growth 1,000, Scale 5,000, Production unlimited | Terms of Use and Design and Brand Guidelines; 100 requests per minute and 10,000 per day by default | Active |
| Oura API v2 | Cloud, REST | OAuth 2.0 only | 10 users until Oura approves the app | Gen3 and newer users need an active membership; AI-use restrictions | Active, under the June 8, 2026 agreement |
| Garmin Connect Developer Program | Cloud | OAuth | Approved business developers only | License fees for some metrics in commercial use | New applications unavailable |
| Polar AccessLink | Cloud, REST | OAuth 2.0 | Free registration with a Polar Flow account | Only data recorded after the user authorises the app is available | Active |
| Samsung Health Data SDK | On-device, Android | Device permissions | Developer mode only until partner approval | Partnership with Samsung Health required; access code needed to write | Confirm partner programme intake with Samsung |
| Apple HealthKit | On-device, iOS | Device permissions | App Store review | No server-side access; the app uploads what the product needs | Active |
| Android Health Connect | On-device, Android | Device permissions | Google Play review of health permissions | No server-side access; limited default history window | Active; replaces the Google Fit APIs |
Three distinctions decide most architecture choices:
- Cloud versus device. Cloud APIs, such as the Google Health API, WHOOP, Oura, Polar, and Garmin, let a back end fetch data while the phone is closed. On-device stores, such as HealthKit, Health Connect, and the Samsung Health Data SDK, require the phone app to read and upload data. A server-side coaching engine therefore needs at least one cloud source or a reliable background upload.
- Approval ramps. User caps before approval mean every launch plan needs a beta that grows through each vendor's tiers. WHOOP's ramp is the most explicit, as described in the WHOOP API integration guide.
- History. Polar AccessLink provides no data recorded before authorisation, and Health Connect limits the default history window, so first-run experiences should not promise a full past.
Which wearable API fits which product?
- A coaching or training app for serious athletes. WHOOP and Oura users are paying, engaged audiences. Start with WHOOP and the Google Health API, add Polar for endurance athletes, and track Garmin's programme for reopening.
- A corporate wellness or insurance programme. Coverage matters more than depth. Read Apple HealthKit and Health Connect on the phone, which collect data from many devices, and add the Google Health API for Fitbit and Fitbit Air users.
- A clinical study or remote monitoring product. Consumer APIs return processed summaries on vendor schedules. Clinical products usually need a dedicated device with an open data interface, as covered in remote patient monitoring app architecture.
- An AI health assistant. Check AI terms before choosing sources; Oura's terms route LLM use through Oura's own MCP server.
- A hardware company with its own band. The vendor APIs above matter only for importing a user's history; the core product is the band's own pipeline, as covered in how to build a screenless fitness tracker app.
What do vendor terms say about AI and LLMs?
AI features are where vendor terms now bite hardest. Oura's API agreement, effective June 8, 2026, is the most explicit:
- LLM access through Oura's MCP server only
- Section 4(d) states that a developer using Oura data with a large language model may access and process that data solely through the MCP Server, defined as infrastructure operated by Oura that implements the Model Context Protocol.
- No AI training or prompting through the API
- Section 4(d) also prohibits using the Oura API to develop, train, fine-tune, evaluate, prompt, or otherwise provide data to any AI model or platform, and Section 6(g) treats training on user data as a material breach.
- Aggregators cannot pass data to AI
- Section 2(c) bars aggregators from passing Oura data or user data to any AI model, AI platform, or LLM.
- No charging for MCP access
- Section 4(a)(xiii) prohibits charging users for access to or use of the MCP Server, and Section 3(h) reserves Oura's right to introduce fees with notice.
The practical rule for every vendor: list each AI feature, map the data sources it touches, and confirm each vendor's terms allow that use before building it. Google's restricted scopes also fall under Google's API Services User Data Policy and its Limited Use requirements, and WHOOP's API Terms of Use apply to every WHOOP integration.
AppMatic Tech builds AI layers on wearable data through MCP servers that expose governed tools rather than raw data dumps, as explained in what is an MCP server and MCP server for IoT device management.
Should a product use a wearable data aggregator?
Aggregators, such as Terra, Junction, and the open-source Open Wearables project, wrap many vendor APIs behind one interface.
| Factor | Aggregator | Direct integration |
|---|---|---|
| Time to first vendor | Days | Weeks per vendor |
| Ongoing cost | Per-user or per-request fees | Engineering maintenance |
| Data path | Data passes through a third party | Data flows from vendor to the product |
| Vendor obligations | Still apply; Google CASA stays with the OAuth client owner, and Oura requires approval per aggregator end customer | Apply directly |
| Control over sync timing | Set by the aggregator | Set by the product |
AppMatic Tech's recommendation is a hybrid: integrate the two or three sources that define the product directly, where sync timing and data quality matter most, and use an aggregator for the long tail of devices.
Pro tip: Read every vendor's current API agreement during scoping, and diff it again before launch. Oura's agreement changed in June 2026 and Garmin's application form went offline in 2026, so a terms review that is six months old can already be out of date.
How should a multi-vendor integration be architected?
AppMatic Tech builds multi-vendor wearable integrations around one internal data model:
- One adapter per source. Each vendor API or on-device store has its own module that maps vendor records into the product's model.
- Provenance on every record. Each reading stores its source, device, and original ID, so duplicates can be detected and support can trace any number.
- Cross-source de-duplication. The same steps can arrive from a band, the phone, and a health store. A priority order per data type decides which source counts.
- A consent ledger. Every scope a user grants or revokes is recorded with a timestamp, so features degrade correctly and audits are answerable.
- Per-vendor rate limiting and token vaults. Each vendor's limits and refresh rules are enforced centrally, including WHOOP's refresh token rotation.
- Nightly reconciliation. A job re-fetches recent days from every cloud source to catch missed webhooks and late syncs.
The same adapter pattern for device protocols is covered in one app, many devices, and the on-device platforms are compared in HealthKit vs Health Connect vs Google Health API.
Which wearable APIs matter in which markets?
Device popularity varies by country, so the right source list does too.
- Fitbit Air markets. Google launched the Fitbit Air in 20 markets, including the United States, the United Kingdom, Germany, France, Japan, Australia, and Singapore, which makes the Google Health API a priority source there, as covered in Fitbit Air app development.
- India. The Fitbit Air launch list did not include India, Android holds about 93% of mobile web traffic, and IDC reports Samsung led India's smart wristband segment in 2025 with a 59.0% share, so Health Connect and Samsung sources matter more, as covered in wearable app development in India.
- Saudi Arabia and the UAE. Health data residency rules shape where an aggregator or back end may store data, as covered in wearable app development for Saudi Arabia and the UAE.
- United States, United Kingdom, and the EU. Privacy and medical device rules apply to what the product does with the data, as covered in when a wearable app becomes a medical device.
How AppMatic Tech builds wearable data integrations
AppMatic Tech has shipped 330+ products since 2017, holds a 5.0 Clutch rating across 11 verified reviews, and keeps an 83% client retention rate. Its wearable and sensor work includes EYVA, Trackwel, Capmedic, and SENS.
The service overview is on the AppMatic Tech wearable app development page, with AI work described under AI expertise. Scoping a multi-vendor wearable integration starts at contact@appmatictech.com or the contact page.
Sources
| Claim used in this article | Source |
|---|---|
| Fitbit Web API dates; Google Health API covers Fitbit and Pixel devices | Google Health API, About |
| 100-user cap, restricted scopes, CASA assessment | Google Health API, App verification |
| Google Fit APIs supported until the end of 2026 | Android Developers, Google Fit migration guide |
| WHOOP approval tiers and rate limits | WHOOP, App approval and API rate limiting |
| Oura API agreement, effective June 8, 2026, Sections 2(c), 3(h), 4(a)(xiii), 4(d), 6(g) | Oura API Agreement |
| Oura personal access token deprecation, 10-user cap, membership requirement | Terra, Oura API access and restrictions |
| Garmin programme terms and application form status | Garmin Health API and Terra, Garmin Connect Developer Program pause |
| Polar AccessLink registration and data availability after authorisation | Polar, Open AccessLink API |
| Samsung Health Data SDK partner approval and access code | Samsung Developers, Health Data SDK process |
| CASA responsibility stays with the OAuth client owner | Open Wearables, Google CASA verification |
| Samsung share of India's smart wristband segment | IDC, India wearables market 2025 |
| Android share of mobile web traffic in India | StatCounter, India mobile OS share |
| Fitbit Air launch markets | 9to5Google, Fitbit Air launch |
Frequently Asked Questions
- Which wearable APIs can a third-party app use in 2026?
- In 2026, third-party apps can read wearable data through cloud APIs from Google (the Google Health API for Fitbit and Pixel devices), WHOOP, Oura, and Polar, through Garmin's Connect Developer Program for approved business developers, and through on-device stores: Apple HealthKit on iOS, Health Connect on Android, and the Samsung Health Data SDK for approved partners. Each platform sets separate consent, approval, and usage rules.
- Does the Oura API require an Oura membership?
- Oura's access requirements state that users with a Gen3 ring or newer need an active Oura Membership for Oura data to be available through the API, including through partner integrations. Oura deprecated personal access tokens in December 2025, so apps use OAuth 2.0, and each app is limited to 10 users until Oura approves the app.
- Can wearable data be sent to ChatGPT, Claude, or other AI models?
- It depends on each vendor's terms. Oura's API agreement, effective June 8, 2026, permits large language model use of Oura data only through Oura's own MCP server and prohibits using the API to train, evaluate, or prompt AI models. WHOOP, Google, and Garmin data is governed by each vendor's own terms, which a product team should review before any AI feature ships.
- Is the Garmin Health API open to new developers?
- Garmin's Connect Developer Program describes access as free for approved business developers, with license fees for some metrics in commercial use. A Garmin forum reply quoted in September 2026 stated that the application form for new API access requests is currently unavailable, and Garmin has not announced a reopening date, so new products should confirm status with Garmin directly.
- Should an app use a wearable data aggregator or direct integrations?
- A wearable data aggregator speeds up multi-vendor coverage, but adds per-user cost and a third party in the data path, and does not remove vendor obligations: Google's CASA assessment stays with the OAuth client owner, and Oura requires approval per aggregator end customer. AppMatic Tech recommends direct integrations for the two or three sources that matter most and an aggregator only for the long tail.