Third-Party Wearable & Health Platform API Research¶

Related task: RES-004 (Combat Sports Wearable Technology) Purpose: Evaluate server-side integration options for ingesting health data from users' existing wearables Last updated: 2026-03-09 Knowledge basis: Compiled from documentation review up to May 2025; verify links and pricing before implementation

1. Oura Ring — Oura API v2¶

Public server-side API?¶

Yes. The Oura API v2 is a REST API for server-side access to Oura Ring data. Replaced the older v1 API (deprecated/sunset 2023-2024).

Data available¶

Endpoint	Data
Daily Sleep	Sleep score, total duration, efficiency, latency, deep/REM/light stages
Sleep Periods	Per-sleep-period breakdown, hypnogram, HRV during sleep, HR during sleep
Daily Activity	Activity score, steps, calories, equivalent walking distance, inactive time
Daily Readiness	Readiness score, temperature deviation, HRV balance, recovery index, resting HR
Heart Rate	5-minute interval HR throughout the day
HRV	Nightly RMSSD, per sleep session
Daily SpO2	Average SpO2 (Gen 3 only)
Workouts	Activity type, duration, calories, distance, intensity
Daily Stress	Stress metrics (Gen 3)
Temperature	Skin temperature deviation from baseline (not absolute)
Sessions	Meditation/breathing sessions

Auth method¶

OAuth 2.0 (Authorization Code flow) — for multi-user apps
Personal Access Token (PAT) — simpler, for dev/testing. Generate at cloud.ouraring.com

Free or paid? Rate limits?¶

Free. No API fees.
~5,000 requests per 5-minute window per token

Real-time or historical?¶

Historical only (REST, query by date range)
Webhooks supported — push notifications when new data arrives (near-real-time)
No streaming/WebSocket
Data available after ring syncs to phone → phone uploads to Oura Cloud

Restrictions / approval¶

PAT: Anyone with Oura account, instant, no approval
OAuth apps: Register at developer portal, may need review for broad distribution
No paid developer program

Notable limitations¶

No real-time HR streaming
Temperature is relative deviation, not absolute
SpO2 is daily average (sleep only, Gen 3)
HR resolution is 5-minute intervals
No direct BLE device communication — all data goes through Oura Cloud
Data depends on user syncing the Oura app
Gen 3 vs Gen 2 feature differences

URLs¶

API v2 Base: https://api.ouraring.com/v2/usercollection/
Docs: https://cloud.ouraring.com/v2/docs
Developer portal: https://cloud.ouraring.com/docs

Verdict for Sellwyse¶

Good for recovery/sleep/readiness data. Not suitable for real-time coaching. Complements your BLE devices as a secondary data source.

2. WHOOP — WHOOP Developer API¶

Public server-side API?¶

Yes. The WHOOP Developer Platform provides a REST API. Launched ~late 2022 / early 2023.

Data available¶

Endpoint	Data
Recovery	Recovery score, HRV (rMSSD), resting HR, SpO2, skin temp
Sleep	Sleep stages (wake, light, REM, SWS), duration, performance score, respiratory rate
Cycle (Strain)	Day strain score, average HR, max HR, kilojoules
Workout	Workout strain, sport type, HR zones, kilojoules
Body Measurement	Height, weight, max HR
Profile	User profile info

No raw second-by-second HR data — only aggregated/summary metrics.

Auth method¶

OAuth 2.0 (Authorization Code flow)
Scopes: read:recovery, read:sleep, read:workout, read:cycles, read:profile, read:body_measurement

Free or paid? Rate limits?¶

Free. No per-call charges.
User must have active WHOOP membership (~$30/mo or $239/yr)
Rate limit: ~100 requests per minute per user token

Real-time or historical?¶

Historical/polling only. No webhooks, no streaming, no push.
Recovery/sleep scores available after WHOOP processes them (after waking)

Restrictions / approval¶

Register at developer.whoop.com — open, no approval needed
WHOOP reserves right to revoke for ToS violations
Commercial/enterprise use may need partnership contact

Notable limitations¶

No raw HR streaming — significant for live coaching
Read-only — cannot push data back
User must have active WHOOP subscription
No historical bulk export (cursor-based pagination)
Refresh tokens are single-use (rotated)
Device-locked ecosystem (WHOOP strap only)

URLs¶

Developer Portal: https://developer.whoop.com
API Docs: https://developer.whoop.com/docs
API Base: https://api.prod.whoop.com/developer/v1/

Verdict for Sellwyse¶

Good for recovery/strain data post-workout. Not suitable for live coaching due to no real-time HR. Nice complement for users who own a WHOOP.

3. Garmin — Health API¶

Public server-side API?¶

Yes, but requires partner approval. The Garmin Health API is a server-to-server REST API for health/fitness data.

Garmin also has Connect IQ SDK (on-device apps) and Health Enterprise SDK (firmware-level), but the Health API is what Sellwyse needs.

Data available¶

Daily Summaries: Steps, distance, calories, floors, intensity minutes, active/sedentary time
Heart Rate: Resting HR, HR time-in-zones, timestamped HR samples (15-sec or per-second during activities)
HRV: Nightly summary, HRV status
Sleep: Stages (deep, light, REM, awake), sleep score
Activities: Recorded activities with GPS tracks, laps, splits (FIT file format)
SpO2: Spot checks and overnight
Stress: All-day stress scores (HRV-derived)
Body Battery: Energy level throughout day
Respiration: Breathing rate
Body Composition: Weight, BMI, body fat % (with Garmin Index scale)

Auth method¶

OAuth 1.0a (NOT 2.0) — notable quirk. May have migrated to 2.0 by now, verify.
Long-lived tokens (don't expire, but users can revoke)

Free or paid? Rate limits?¶

Free for approved partners — no per-call fees
Must apply to the Garmin Health API partner program
Rate limits shared upon approval; prefer push pings over polling

Real-time or historical?¶

No real-time streaming.
Push notifications (pings): Garmin sends webhooks when new data is available. You then fetch the data. This is the recommended pattern.
Historical backfill available (~24 months)

Restrictions / approval¶

Must apply and be approved — 2-6 week review process
Application at https://developer.garmin.com/gc-developer-program/health-api/
Full API docs only available after approval
Not self-service like Oura/WHOOP/Fitbit

Notable limitations¶

OAuth 1.0a — need specific library (Rust: oauth1-request crate)
Not self-service — approval gate adds lead time
FIT file format for activity data — binary, needs parser (Rust: fitparser crate)
Data latency depends on user syncing watch to Garmin Connect app
Read-only API
Data availability varies by device model

URLs¶

Developer Portal: https://developer.garmin.com/
Health API Program: https://developer.garmin.com/gc-developer-program/health-api/
Full docs: provided after partner approval

Verdict for Sellwyse¶

Worth applying for now — large athlete user base, good data (especially GPS activities). The 2-6 week approval wait means you should apply early. FIT file parsing and OAuth 1.0a add implementation complexity.

4. Fitbit (Google) — Fitbit Web API¶

Public server-side API?¶

Yes. The Fitbit Web API is a mature REST API designed for server-side (and client-side) access to user health data. It has been available since ~2014 and is now managed under Google's umbrella.

Data available¶

Activity: Steps, distance, calories, active minutes, activity logs, exercise sessions
Heart Rate: Resting HR, intraday HR (1-sec or 1-min resolution), HR zones
HRV: Daily HRV (RMSSD-based), HRV intraday (requires scope approval)
Sleep: Sleep stages (light, deep, REM, wake), sleep duration, sleep score
SpO2: Nightly SpO2 readings, SpO2 intraday
Body: Weight, BMI, body fat %, logged via scale or manual
Nutrition: Food/water logging
Breathing Rate: Daily breathing rate
Temperature: Skin temperature variation (relative)
ECG: ECG readings (limited availability by region)
Active Zone Minutes (AZM)

Auth method¶

OAuth 2.0 with PKCE (Authorization Code Grant with PKCE is required)
Scopes: activity, heartrate, sleep, weight, nutrition, oxygen_saturation, respiratory_rate, temperature, electrocardiogram
Intraday data (1-sec/1-min HR, detailed sleep) requires a separate application approval — you must apply and describe your use case

Free or paid? Rate limits?¶

Free to use. No API fees.
Rate limit: 150 API requests per user per hour
No per-app global cap documented, but abuse can lead to throttling
Intraday access requires approved "Personal" or "Server" application type

Real-time or historical?¶

Historical: Full historical data accessible via API
Near-real-time: Subscription API (webhooks) available — Fitbit pushes notifications when new data syncs. You then pull the updated data.
Intraday: Available for HR (1-sec), steps (1-min/15-min), but requires approved app
No true real-time streaming; data is available after device syncs to Fitbit servers

Restrictions / approval process¶

Register an app at dev.fitbit.com
Personal apps: Immediate access to intraday data for a single user (good for dev/testing)
Server apps: Must apply for intraday access; review process can take days to weeks
Must comply with Fitbit's Terms of Service and data use policies
Cannot sell raw Fitbit data; must add value
Google account migration is ongoing — some users may need to migrate their Fitbit accounts to Google accounts

Notable limitations¶

Data availability depends on device sync (Bluetooth to phone, then to cloud) — can be delayed minutes to hours
150 req/user/hour can be restrictive if polling frequently for multiple data types
HRV data is relatively new and only available on newer devices (Sense, Charge 5/6, Versa 3/4)
Google has been migrating Fitbit into the Google ecosystem; long-term API strategy may shift toward Google Health Connect / Google Fit APIs. Monitor for deprecation announcements.
Intraday HR data at 1-second resolution creates large payloads

Verdict for Sellwyse¶

Strong candidate. Mature API, good data coverage (HR, HRV, sleep, SpO2), webhooks for near-real-time updates. The 150 req/user/hour limit is workable. Main risk is Google's migration strategy.

5. Apple Health — HealthKit¶

Public server-side API?¶

No. Apple does not provide any server-side/cloud REST API for accessing HealthKit data. HealthKit is strictly an on-device framework (iOS/watchOS only).

How it works¶

HealthKit stores data locally on the user's iPhone
Third-party apps can read/write HealthKit data only from an iOS app running on the user's device
Data never goes to Apple's servers in a way that third parties can access (Apple encrypts and syncs via iCloud for the user's own backup, but provides no API to access that)

Data available (on-device only)¶

300+ data types: HR, HRV, steps, sleep, SpO2, respiratory rate, ECG, blood glucose, blood pressure, body measurements, workouts, nutrition, mindfulness, menstrual tracking, etc.
Apple Watch provides: HR (continuous), HRV (SDNN, sporadic), SpO2, sleep stages, wrist temperature, crash detection

Auth method¶

iOS app must request HealthKit entitlement and user authorization per data type
No OAuth, no API keys — it is all on-device permission grants

Free or paid?¶

Free (part of iOS SDK). Requires Apple Developer Program membership ($99/year) to distribute apps.

Real-time or historical?¶

On-device: Both real-time (background delivery observers) and full historical
Server-side: Neither — no server API exists

Restrictions¶

Must have a native iOS/watchOS app
App Review required; Apple scrutinizes health apps
Cannot access HealthKit from a web app, Android, or server

Notable limitations¶

The biggest limitation for Sellwyse: You cannot pull Apple Health data server-side. You MUST build an iOS app component that reads HealthKit locally and then uploads data to your own server.
Users must explicitly grant permission for each data type
HealthKit is not available on iPad (only iPhone and Apple Watch)
Background delivery is limited and unreliable for some data types
No web SDK or REST API — full stop

Workarounds¶

Build a Flutter iOS app (which you already plan) that reads HealthKit and POSTs data to your Rust backend
Use an aggregator (Terra, Vital) that has already built the iOS SDK component and provides a server-side API
Apple's Health Records (FHIR-based clinical data) is a separate system and also on-device only

Verdict for Sellwyse¶

Cannot integrate server-side directly. Must go through your iOS app (Flutter + HealthKit plugin) or use an aggregator service. Since you are building a Flutter app anyway, the health Flutter package can bridge HealthKit data to your backend.

6. Samsung Health¶

Public server-side API?¶

Effectively no. Samsung's approach has changed multiple times:

Samsung Health SDK (Android): Was available for on-device data access on Samsung phones. Samsung deprecated the Partner Apps program and the Health Data SDK in 2024. They directed developers to use Google Health Connect instead.
Samsung Health Stack (open source): Samsung released an open-source backend platform for health research studies, but this is for running your own studies, not for accessing Samsung Health user data.
Samsung Privileged Health SDK: Available only to select partners (e.g., Samsung Galaxy Watch app developers with a partnership agreement). Not publicly accessible.

Data available (historically, via deprecated SDK)¶

Steps, HR, sleep, SpO2, body composition (via Samsung scales), blood pressure (via Samsung Galaxy Watch with approved app), ECG, stress

Auth method¶

The deprecated SDK used on-device permissions
No OAuth-based server API ever existed for Samsung Health

Free or paid?¶

The deprecated SDK was free
Samsung Health Stack is open-source (Apache 2.0)

Restrictions¶

Samsung has moved toward Google Health Connect as the interoperability standard
Samsung Galaxy Watch data flows into Samsung Health app, which can now sync to Health Connect
Direct server-side access to Samsung Health cloud data is not available to third parties

Notable limitations¶

No server-side API. Period.
Samsung Galaxy Watch data is accessible indirectly via Health Connect (on-device, Android only)
Fragmented: different SDKs for phone vs watch, mostly deprecated

Verdict for Sellwyse¶

No direct server-side integration possible. Use Google Health Connect (on-device, via your Android app) or an aggregator service to capture Samsung Health data indirectly.

7. Xiaomi / Mi Band¶

Public server-side API?¶

No. Xiaomi does not provide any public API (server-side or otherwise) for accessing Mi Band / Xiaomi Smart Band health data.

How it works¶

Mi Band data syncs to the Zepp Life app (formerly Mi Fit) or Xiaomi Wear app via Bluetooth
Data is stored on Xiaomi's servers but there is no developer API
Xiaomi has never offered a developer program for health data access

Data available (in the app, not via API)¶

Steps, HR, SpO2, sleep (stages on newer bands), stress, PAI (Personal Activity Intelligence)

Workarounds¶

Health Connect (Android): Xiaomi Wear / Zepp Life can write data to Google Health Connect. Your Android app can then read from Health Connect.
Aggregators: Terra API and Vital do not support Xiaomi directly (as of early 2025). Some support it indirectly through Health Connect.
Zepp (Amazfit) API: Zepp (formerly Amazfit, Huami — Xiaomi's wearable manufacturer) has the Zepp Health API (see below). Older Mi Bands used Huami hardware, so some data may flow through Zepp, but this is not reliable for Mi Band specifically.

Zepp Health (the company behind Amazfit watches and previously manufactured Mi Bands) offers the Zepp Health Developer Platform with a cloud API
OAuth 2.0-based
Covers: HR, SpO2, sleep, activity, stress for Amazfit devices
Requires partner application and approval
May work for users who use the Zepp app (not Xiaomi Wear)

Verdict for Sellwyse¶

No direct integration. Xiaomi is a walled garden. Best path is Health Connect (on-device via Android app) or hope the user uses the Zepp app with a compatible device. Low priority for direct integration.

8. Polar — AccessLink API¶

Public server-side API?¶

Yes. Polar provides the AccessLink API, a REST API for server-side access to user health and training data from Polar devices.

Data available¶

Training data: Workout sessions with HR data, route (GPS), sport type, duration, calories, training load (via Training Load Pro)
Daily activity: Steps, calories, active time, activity goal progress
Sleep: Sleep duration, sleep stages (on supported devices like Polar Ignite, Vantage, Grit X)
Physical info: Weight, height, max HR, resting HR
Recovery: Nightly Recharge (ANS status = HRV-based recovery metric)
Continuous HR: Available in exercise sessions, not as a standalone 24/7 stream
HRV: Available within Nightly Recharge data and exercise sessions

Auth method¶

OAuth 2.0 (Authorization Code flow)
Register at admin.polaraccesslink.com

Free or paid? Rate limits?¶

Free to use
Rate limits are not heavily documented but are generous for normal use
Data is pulled (no webhooks for push notifications as of early 2025)

Real-time or historical?¶

Historical + near-real-time: Data is available after the user syncs their Polar device to the Polar Flow app/service
New data notification via pull model — you poll for new transaction data
No webhooks / push notifications (this is a notable gap vs. Fitbit/Withings)
Intraday HR data is available within exercise sessions, not as a 24/7 continuous stream

Restrictions / approval process¶

Register as a developer, create a client
No heavy approval process — relatively easy to get started
Must comply with Polar's data use terms
Users must authorize your app via Polar Flow

Notable limitations¶

Pull-only model — no webhooks, must poll for new data
Exercise HR data is detailed, but resting/continuous HR between workouts is limited
Sleep data requires newer devices (Ignite 3, Vantage V2/V3, Grit X Pro, etc.)
Smaller user base than Fitbit or Apple Watch
API documentation is decent but less polished than Fitbit's
Transaction-based data retrieval: you create a "transaction," list available data, fetch it, then commit. Somewhat unusual pattern.

Verdict for Sellwyse¶

Viable but niche. Good for serious athletes (Polar's core market overlaps with Sellwyse's UFC/fitness audience). API is free and functional. Lack of webhooks is annoying. The transaction-based model adds complexity.

9. Withings — Health Mate API¶

Public server-side API?¶

Yes. Withings provides a comprehensive HTTP API for server-side access to health data from Withings devices (scales, watches, blood pressure monitors, sleep trackers).

Data available¶

Activity: Steps, distance, calories, elevation, active/inactive duration
Body: Weight, body fat %, muscle mass, bone mass, water %, BMI (via Body+ / Body Scan scale)
Heart: HR, HRV, ECG traces (ScanWatch), SpO2, vascular age
Sleep: Duration, sleep stages (light, deep, REM), snoring, breathing disturbances, sleep score
Blood Pressure: Systolic, diastolic, pulse (via BPM Connect/Core)
Temperature: Skin temperature (Thermo thermometer, ScanWatch)
Workouts: GPS tracks, HR during exercise

Auth method¶

OAuth 2.0 (Authorization Code flow)
Register at developer.withings.com
Scopes: user.info, user.metrics, user.activity, user.sleepevents

Free or paid? Rate limits?¶

Free for development and production use
Rate limits: ~120 requests per minute per user (generous)
No per-API-call charges

Real-time or historical?¶

Historical: Full access to historical data
Webhooks (push notifications): YES — Withings supports webhook subscriptions. When new data is available, Withings pushes a notification to your server. This is a major advantage.
Data categories for webhooks: weight, activity, sleep, heart, blood pressure
Near-real-time: data available shortly after device sync

Restrictions / approval process¶

Register as a developer — straightforward
For medical-grade data (blood pressure, ECG), additional compliance may be required depending on your jurisdiction
Must comply with Withings terms and GDPR
App review is relatively light compared to Apple

Notable limitations¶

Device ecosystem is narrow: Withings makes scales, the ScanWatch (smartwatch), BPM monitors, and the Thermo thermometer. If users don't own Withings hardware, this API is irrelevant.
ScanWatch is the only Withings device with continuous HR, HRV, SpO2, and sleep stages — it is a premium device (~$300-$500)
No support for third-party device data — only Withings hardware
ECG feature availability varies by country (FDA/CE cleared)

Verdict for Sellwyse¶

Excellent API quality, but limited device reach. If users happen to have Withings devices (especially ScanWatch or Body Scan scale), this is one of the best-documented, most developer-friendly health APIs available. Webhooks are a big plus. But you cannot use it to aggregate data from non-Withings devices.

10. Google Fit / Health Connect¶

Background — Google Fit vs Health Connect¶

Google Fit REST API was Google's cloud-based health data API. Google deprecated the Google Fit REST API and the Google Fit app. The shutdown deadline was announced for June 30, 2025. After that date the REST API is expected to be non-functional.
Health Connect (formerly Android Health) is the replacement. It is an on-device API only (Android), not a cloud/server-side API.

Health Connect — Public server-side API?¶

No. Health Connect is strictly an on-device Android API. There is no cloud REST endpoint.

How Health Connect works¶

Health Connect is a system service on Android (built into Android 14+, installable on Android 9+)
Apps write/read health data to a local on-device store
Supported sources: Samsung Health, Fitbit, Oura, Garmin Connect, Strava, Peloton, MyFitnessPal, Xiaomi Wear, and many more
Your Android app can read from Health Connect to aggregate data from all these sources

Data available (on-device)¶

80+ data types: steps, HR, HRV, sleep, SpO2, body measurements, nutrition, exercise sessions, speed, power, cadence, cycling, hydration, blood glucose, blood pressure, respiratory rate, VO2max, and more

Auth method¶

Android runtime permissions (per data type read/write)
No OAuth — entirely on-device
Requires declaring permissions in your app manifest and requesting them from the user

Free or paid?¶

Free (part of Android SDK / Jetpack Health library)

Real-time or historical?¶

On-device: Both — can observe changes in real-time and access historical data (up to 30 days in the past for non-priority data by default, longer for apps that contributed the data)
Server-side: N/A

Restrictions¶

Android only (no iOS)
Your app must be published on Google Play to access Health Connect in production
Google Play requires a health data use declaration
Data retention: Health Connect may limit how far back third-party apps can read data (30 days for "read" permissions for most data types, unless the user has opted into longer retention)

Notable limitations¶

Not a server-side API. You must build an Android app that reads Health Connect and uploads to your server.
30-day default read window limits historical access
Data depends on which apps the user has installed and syncing to Health Connect
No iOS support (use HealthKit for iOS)
Google Fit REST API shutdown removes the only server-side Google option

Verdict for Sellwyse¶

Important for Android users, but requires app-side integration. Since you are building a Flutter app, use the health Flutter package which supports Health Connect. Your app reads Health Connect on-device and sends data to your Rust backend. This is your primary path for capturing data from Samsung, Fitbit (on Android), Garmin, and other Android wearables.

11. Health Data Aggregators¶

These services solve the fragmentation problem by providing a single server-side API that connects to multiple wearable platforms.

8a. Terra API¶

Website: tryterra.co

Aspect	Details
What it does	Unified REST API that connects to 20+ wearable/health platforms. Handles OAuth flows, data normalization, and webhook delivery.
Supported sources	Fitbit, Garmin, Oura, WHOOP, Polar, Withings, Suunto, Xiaomi (via Health Connect), Samsung (via Health Connect), Apple Health (via mobile SDK), Google Health Connect (via mobile SDK), Peloton, Strava, Cronometer, MyFitnessPal, Eight Sleep, Dexcom, Freestyle Libre, Coros, and more
Data types	Activity, body metrics, daily summaries, sleep, nutrition, menstruation, athlete data (HR zones, training load). Normalized into a consistent schema.
Auth method	Your server uses an API key + dev ID. Users authenticate via Terra's widget (OAuth flow to each provider). For Apple Health / Health Connect, Terra provides mobile SDKs.
Pricing	Free tier: Up to 25 connected users, limited API calls. Paid: Starts ~$100-200/mo for startups (usage-based). Enterprise pricing available. Pricing may have changed — verify at tryterra.co/pricing.
Real-time	Webhooks: Yes, Terra pushes data to your server when new data arrives from any connected source. Near-real-time for most cloud-connected sources.
Rate limits	Varies by plan; generous on paid tiers
Notable strengths	Handles the Apple Health problem (provides iOS SDK), handles Health Connect (Android SDK), handles OAuth complexity for every provider. One normalized data schema.
Notable limitations	Added dependency and cost. You rely on Terra's uptime and their integrations staying current. Some data types may have reduced granularity after normalization. Intraday HR resolution varies by source.

8b. Vital (Tryvital)¶

Website: tryvital.io

Aspect	Details
What it does	Unified health data API similar to Terra. Connects wearables + lab testing. Positioned more toward health/wellness companies and telehealth.
Supported sources	Fitbit, Garmin, Oura, WHOOP, Polar, Withings, Dexcom, Freestyle Libre, Apple Health (via SDK), Google Health Connect (via SDK), Strava, Peloton, Cronometer, Eight Sleep, and more
Data types	Activity, sleep, body, vitals (HR, HRV, SpO2), workouts, nutrition, blood glucose (CGM). Also supports lab test ordering (blood work via partner labs).
Auth method	API key for server-side. Link widget or SDK for user connection. OAuth handled by Vital.
Pricing	Free tier: Yes (limited users/API calls). Paid: Usage-based, starts around $100-200/mo. Pricing varies — verify at tryvital.io/pricing.
Real-time	Webhooks: Yes. Data pushed when available.
Rate limits	Varies by plan
Notable strengths	Lab test integration is unique. Good documentation. SDKs for iOS (HealthKit), Android (Health Connect), React Native, Flutter.
Notable limitations	Similar to Terra: added dependency, cost, potential data normalization loss. Lab testing is US-focused.

8c. Humanapi (now part of Ciitizen/Invitae)¶

Historically another aggregator, but has pivoted more toward clinical/medical data and EHR integration. Less relevant for wearable fitness data. Not recommended for Sellwyse's use case.

8d. Comparison: Terra vs Vital¶

Feature	Terra	Vital
Wearable coverage	Slightly broader (more sports platforms)	Strong, plus lab tests
Apple Health	iOS SDK	iOS SDK
Health Connect	Android SDK	Android SDK
Flutter SDK	Yes	Yes
Webhooks	Yes	Yes
Data normalization	Strong	Strong
Pricing	Similar	Similar
Lab tests	No	Yes (US)
Best for	Sports/fitness apps	Health/wellness + clinical

12. Recommendation for Sellwyse¶

Strategy: Hybrid Approach¶

Given Sellwyse's architecture (Flutter mobile apps + Rust/Axum backend), the recommended approach is:

Tier 1 — Direct Integration (Priority)¶

Platform	Method	Why
Fitbit	Fitbit Web API (server-side REST)	Mature, free, webhooks, large user base. Direct integration is straightforward and avoids aggregator costs.
Apple Health	Flutter `health` package -> POST to backend	No server API exists. Your iOS app reads HealthKit and uploads. This is mandatory for iPhone users.
Google Health Connect	Flutter `health` package -> POST to backend	No server API exists. Your Android app reads Health Connect and uploads. This captures Samsung, Garmin, Xiaomi, Strava, etc. indirectly.

Tier 2 — Direct Integration (If User Base Demands)¶

Platform	Method	Why
Withings	Withings API (server-side REST)	Excellent API with webhooks. Only if you have users with Withings devices.
Polar	AccessLink API (server-side REST)	Good for athlete-focused users. Free. No webhooks (polling needed).
Garmin	Garmin Health API (server-side REST)	Not covered in detail above, but Garmin has a Health API for enterprise/B2B partners (requires partnership application). Large athlete user base. Worth investigating.

Tier 3 — Aggregator (Scale / Convenience)¶

Option	When
Terra API	When you need to support 10+ wearable brands without building each integration individually. When time-to-market matters more than per-unit cost.
Vital	Same as Terra, plus if you want lab test integration for future features.

Key Architecture Notes¶

Flutter health package handles both HealthKit (iOS) and Health Connect (Android). This single package gives you on-device access to Apple Watch, Samsung Galaxy Watch, Garmin, Fitbit (Android), and any other app writing to these stores.
Background sync is critical: your Flutter app needs to periodically read new health data and POST it to your backend, even when the app is not in the foreground. Both iOS and Android have background execution limitations that require careful handling (iOS Background App Refresh, Android WorkManager).
Data normalization is your responsibility if doing direct integrations. Each source uses different units, resolutions, and schemas. An aggregator handles this for you.
Deduplication is important: if a user has a Fitbit and you read data both via Fitbit Web API and via Health Connect (where Fitbit also writes), you will get duplicates.

Implementation Priority¶

Phase 1 (MVP):
  - Flutter health package (HealthKit + Health Connect) -> covers Apple + Android ecosystem
  - Fitbit Web API -> covers Fitbit cloud data with webhooks

Phase 2 (Growth):
  - Garmin Health API (if approved)
  - Withings API (if user demand)
  - Polar AccessLink (if user demand)

Phase 3 (Scale, optional):
  - Evaluate Terra or Vital to replace/supplement individual integrations
  - Only if maintaining 5+ individual integrations becomes burdensome

Quick Reference Table¶

Platform	Server-Side API?	Auth	Cost	Webhooks	Approval?	Best Path for Sellwyse
Oura Ring	YES	OAuth 2.0 / PAT	Free	YES	No (PAT instant, OAuth may need review)	Direct REST API
WHOOP	YES	OAuth 2.0	Free	NO	No (open portal)	Direct REST API
Garmin	YES	OAuth 1.0a	Free	YES (pings)	Yes (2-6 weeks)	Apply for partnership
Fitbit	YES	OAuth 2.0	Free	YES	No (intraday needs review)	Direct REST API
Apple Health	NO	On-device	Free (dev $99/yr)	N/A	No	Flutter `health` pkg
Samsung Health	NO (deprecated)	N/A	N/A	N/A	N/A	Health Connect via Flutter
Xiaomi / Mi Band	NO	N/A	N/A	N/A	N/A	Health Connect via Flutter
Polar	YES	OAuth 2.0	Free	NO	No	Direct REST API
Withings	YES	OAuth 2.0	Free	YES	No	Direct REST API
Google Health Connect	NO (on-device)	Android perms	Free	N/A	No	Flutter `health` pkg
Google Fit REST	DEAD (shut down Jun 2025)	—	—	—	—	Use Health Connect instead
Terra	YES (aggregator)	API key	Paid (~$100+/mo)	YES	No	Single API for all
Vital	YES (aggregator)	API key	Paid (~$100+/mo)	YES	No	Single API for all

Links to Verify (as of 2026-03-09)¶

Oura API v2: https://cloud.ouraring.com/v2/docs
WHOOP Developer: https://developer.whoop.com/docs
Fitbit Web API: https://dev.fitbit.com/build/reference/web-api/
Apple HealthKit: https://developer.apple.com/documentation/healthkit
Health Connect: https://developer.android.com/health-and-fitness/guides/health-connect
Polar AccessLink: https://www.polar.com/accesslink-api/
Withings Developer: https://developer.withings.com/
Garmin Health API: https://developer.garmin.com/health-api/overview/
Terra API: https://tryterra.co/
Vital: https://tryvital.io/
Flutter health package: https://pub.dev/packages/health

NOTE: Web search and web fetch tools were unavailable during this research session. All information is based on documentation knowledge up to May 2025. Before implementing, verify current API status, pricing, and any deprecation announcements — particularly for Fitbit (Google migration) and Google Fit REST API (shutdown timeline).

Third-Party Wearable & Health Platform API Research¶

Table of Contents¶

1. Oura Ring — Oura API v2¶

Public server-side API?¶

Data available¶

Auth method¶

Free or paid? Rate limits?¶

Real-time or historical?¶

Restrictions / approval¶

Notable limitations¶

URLs¶

Verdict for Sellwyse¶

2. WHOOP — WHOOP Developer API¶

Public server-side API?¶

Data available¶

Auth method¶

Free or paid? Rate limits?¶

Real-time or historical?¶

Restrictions / approval¶

Notable limitations¶

URLs¶

Verdict for Sellwyse¶

3. Garmin — Health API¶

Public server-side API?¶

Data available¶

Auth method¶

Free or paid? Rate limits?¶

Real-time or historical?¶

Restrictions / approval¶

Notable limitations¶

URLs¶

Verdict for Sellwyse¶

4. Fitbit (Google) — Fitbit Web API¶

Public server-side API?¶

Data available¶

Auth method¶

Free or paid? Rate limits?¶

Real-time or historical?¶

Restrictions / approval process¶

Notable limitations¶

Verdict for Sellwyse¶

5. Apple Health — HealthKit¶

Public server-side API?¶

How it works¶

Data available (on-device only)¶

Auth method¶

Free or paid?¶

Real-time or historical?¶

Restrictions¶

Notable limitations¶

Workarounds¶

Verdict for Sellwyse¶

6. Samsung Health¶

Public server-side API?¶

Data available (historically, via deprecated SDK)¶

Auth method¶

Free or paid?¶

Restrictions¶

Notable limitations¶

Verdict for Sellwyse¶

7. Xiaomi / Mi Band¶

Public server-side API?¶

How it works¶

Data available (in the app, not via API)¶

Workarounds¶

Zepp Health (Amazfit) API — related¶

Verdict for Sellwyse¶

8. Polar — AccessLink API¶

Public server-side API?¶

Data available¶

Auth method¶

Free or paid? Rate limits?¶

Real-time or historical?¶

Restrictions / approval process¶

Notable limitations¶

Verdict for Sellwyse¶

9. Withings — Health Mate API¶

Public server-side API?¶

Data available¶

Auth method¶