Skip to main content
This guide gives an overview of data type support across the integrated wearable providers. Use this matrix to understand what data you can expect when integrating with specific devices.

Quick Overview

  • Full support — Fully implemented and collecting data
  • Partial — Limited data or only during certain contexts (e.g., workouts only)
  • 🔜 Coming soon — Provider API supports this, processing not yet implemented
  • Not available — Provider doesn’t support this or not applicable
Timeseries = Granular, timestamped data points (heart rate samples, step counts, HRV readings) available via the /timeseries API endpoint.24/7 Data = Continuous health monitoring throughout the day (not just during workouts), including resting heart rate, HRV during sleep, SpO2 spot checks, and daily activity samples.

Detailed Coverage Matrix

Heart & Cardiovascular

Blood & Respiratory

Body Composition

Fitness Metrics

Activity - Basic

Activity - Distance

Activity - Walking

Activity - Running

Activity - Swimming

Activity - Generic

Environmental

Provider-Specific

Other


Workout Data Coverage


Sleep Data Coverage


Women’s Health Coverage


Health Scores Coverage


Provider Quirks

Key differences and limitations to be aware of when working with each provider:
Integration Method: Push-based via SDK (no OAuth)
  • Data arrives via client SDK push, not server-to-server sync
  • Workouts (most metrics), sleep (stages, duration), and 100+ health record types via HealthKit SDK
  • Most comprehensive data coverage (100+ metric types)
  • Full sleep processing with stages (deep, light, REM, awake), duration, and time in bed
  • Sleep biometrics (HR, HRV, SpO2 during sleep) not yet extracted as part of sleep records
  • Some walking metrics require iPhone in pocket during activity
  • HRV is measured as SDNN, typically during sleep or rest periods
Integration Method: OAuth 2.0 + Webhooks
  • Webhooks push data for 16 data types: activities, sleep, dailies, epochs, body composition, HRV, stress, respiration, pulse ox, blood pressure, user metrics, skin temperature, health snapshots, activity details, Move IQ, and menstrual cycle tracking
  • Full sleep processing with stages (deep, light, REM, awake), duration, efficiency score, and heart rate biometrics
  • Continuous 24/7 timeseries data: heart rate, steps, energy, HRV (RMSSD, overnight sleep window), stress levels, body battery, respiratory rate, SpO2, and more
  • Body composition from Garmin Index scale: weight, body fat %, BMI
  • Garmin-specific metrics: stress level, body battery, fitness age, skin temperature
  • 135+ workout type mappings to unified taxonomy
  • Workout details include distance, calories, avg/max heart rate, elevation gain, and average speed
  • Backfill orchestration for historical data retrieval (up to 5 years)
  • Menstrual cycle tracking (MCT): cycle phase, day in cycle, cycle/period length, fertile window, and pregnancy snapshot via the mct webhook type
Integration Method: OAuth 2.0 (pull + webhook)
  • Data synced via periodic polling; real-time webhook notifications for exercise, sleep, activity, nightly recharge, and Sleepwise events
  • Webhooks are notify-only: Polar sends a lightweight event payload, Open Wearables acknowledges immediately and enqueues a targeted sync for the affected data type
  • Full sleep processing with stages (deep, light, REM, awake), duration, time in bed, and stage timestamps from hypnogram; sleep efficiency not available in the API
  • Sleep HR timeseries saved from per-night heart rate samples (not summarised avg/min on the sleep record)
  • Continuous 24/7 heart rate sampled at ~5-min intervals via range endpoint (90-day lookback)
  • Daily activity: steps, active calories, and walking/running distance from /v3/users/activities
  • Health scores: sleep score, Nightly Recharge (recovery), Cardio Load (strain)
  • Sleepwise Alertness and Circadian Bedtime scores require an active Polar Sleepwise subscription
  • Body temperature, sleep skin temperature, SpO2, and wrist ECG (HRV RMSSD) require a Polar Elixir device
  • HRV RMSSD available from Elixir SpO2 spot tests and wrist ECG measurements; not available from standard devices; SDNN not provided
  • 75+ workout type mappings to unified taxonomy
  • Exercises fetched from /v3/exercises (all exercises in Polar Flow for the connected user; no date filter)
Integration Method: OAuth 2.0 + 24/7 Data API
  • Most complete cloud-based provider (workouts + sleep + continuous data)
  • Full sleep analysis with stages and biometrics (HR, HRV, SpO2)
  • Activity samples include heart rate, steps, SpO2, energy, and HRV
  • HRV measured as RMSSD, available during activity and sleep
  • Daily activity statistics for aggregated steps and energy
  • 121+ workout type mappings to unified taxonomy
  • Recovery data: Balance score (0-100) mapped to recovery_score
Integration Method: OAuth 2.0 + Webhooks
  • Webhooks push real-time notifications for: daily activity, daily readiness, daily sleep, daily SpO2, and workouts
  • Full sleep processing with stages (deep, light, REM, awake), duration, time in bed, efficiency score, stage timestamps, and nap detection
  • Sleep biometrics: lowest heart rate persisted as a daily resting_heart_rate sample and average breathing rate persisted as respiratory_rate; average HR and average HRV are available from the API but not yet persisted per sleep record
  • Continuous 24/7 timeseries: heart rate (5-min intervals), HRV (RMSSD, 5-min intervals), daily SpO2, steps, active calories, walking distance
  • Recovery data from daily readiness: recovery score, skin temperature deviation, and skin temperature trend deviation
  • Fitness metrics: VO2 max (daily estimate) and cardiovascular age — both require the heart_health OAuth scope
  • Personal info sync: height and weight from user profile
  • Oura does not expose heart rate data during workouts via API; workout records include only duration, type, calories, and distance
  • temperature_deviation and temperature_trend_deviation reflect skin temperature relative to baseline (not absolute body temperature)
  • Backfill defaults to 30 days when no date range is specified
Integration Method: OAuth 2.0 (pull + webhook)
  • Data synced via periodic polling (default: every hour) and real-time webhook notifications for workout, sleep, and recovery events
  • Full workout support with 145+ workout type mappings to unified taxonomy
  • Workout metrics include: avg/max heart rate, calories, distance, elevation gain, moving time
  • Continuous heart rate data is not available via API (only during workouts)
  • Does not track steps (device limitation)
  • Sleep data fully implemented with all stages and efficiency
  • Recovery data fully implemented: recovery score, resting heart rate, HRV (RMSSD), SpO2, skin temperature
  • Body measurements (height, weight) synced from user profile
  • Strain scores available but not yet implemented
Integration Method: OAuth 2.0 (pull-based polling)
  • Data synced via periodic polling (default: every hour); Ultrahuman does not support webhooks
  • Daily metrics endpoint returns all data types for a single day: sleep, HR, HRV, skin temperature, steps, VO2 max, recovery indices
  • Full sleep processing with stages (deep, light, REM, awake), duration, time in bed, and efficiency score
  • Continuous 24/7 timeseries: heart rate, HRV (SDNN), skin temperature, steps
  • VO2 max as a daily aggregate value
  • Recovery metrics (recovery index, movement index, metabolic score) are normalized but not yet persisted
  • No workout/activity data available via the Partnership API
  • Skin temperature values are typically lower than core body temperature (~29-37°C)
  • Backfill defaults to 30 days when no date range is specified
Integration Method: OAuth 2.0 + Webhooks
  • Activity/workout platform only — no sleep, HRV, or continuous health data
  • Real-time webhook notifications for new and updated activities
  • 50+ sport type mappings to unified taxonomy (SportType) plus legacy ActivityType support
  • Workout metrics include: avg/max heart rate, distance, avg/max speed, avg/max watts, elevation (gain/high/low), calories, moving time, device name
  • Per-sample workout streams (heart rate, speed, cadence, power) ingested as /timeseries data when ingest_workout_samples is enabled — scoped to workouts only, not continuous 24/7
  • Calories fall back to kilojoules when calorie data is not available from the API
  • Only one webhook subscription allowed per application
  • Webhook must respond with HTTP 200 within 2 seconds; retries up to 3 times on failure
Integration Method: OAuth 2.0 with PKCE (pull-based polling)
  • Data synced via periodic polling only; the Fitbit Subscriptions API (webhooks) is not yet implemented
  • Workout/activity data only today, fetched from the Activities List API with pagination; backfill defaults to 30 days
  • Workout metrics populated: avg heart rate, calories, distance, steps, and device name; min/max heart rate, speed, and elevation are offered by the API but not yet processed; power is not available
  • Workout distance is currently stored as the raw kilometer value from the API; conversion to the platform meter unit is pending
  • Sleep, intraday heart rate, HRV, SpO2, breathing rate, skin temperature, and body measurements are available in the Fitbit Web API but processing is not yet implemented
  • Intraday timeseries requires a Fitbit “Personal” app type or Fitbit approval for server applications
  • 14 activity type ID mappings plus 25 name-based fallbacks to the unified taxonomy; unrecognized activities map to “other”
Google is a single provider with two ingestion paths under one google identity. This is the Health Connect path; stored records carry the originating app’s name in source (e.g. the app that wrote to Health Connect), which distinguishes them from the cloud API path below.Integration Method: Push-based via Android SDK (no OAuth)
  • 25+ Health Connect record types mapped to unified series: heart rate, resting HR, HRV, SpO2, blood pressure, respiratory rate, body measurements, steps, calories, and distance
  • Full sleep processing with stages (deep, light, REM, awake), duration, time in bed, efficiency score, and stage timestamps
  • Workout sessions currently carry duration, type, and start/end times only; heart rate, speed, calorie, and elevation gain aggregates are planned
  • HRV is measured as RMSSD; SDNN is not available
  • Body fat percentage arrives already in percent
  • Blood glucose arrives in mmol/L; values are stored as received until unit conversion ships
  • Health Connect basal metabolic rate is a kcal/day rate stored into the kcal basal_energy series
  • All Health Connect distance is stored as distance_walking_running regardless of activity type
  • No health scores; GPS routes and in-workout sample streams are accepted by the SDK payload but not yet processed
The cloud API path of the unified google provider; stored records carry the fixed marker source = "google_health_api", which separates them from Health Connect SDK data (whose source is the originating app name). All endpoints are under https://health.googleapis.com/v4/users/me.Integration Method: OAuth 2.0 (cloud pull) + push webhooks (notify-only, trigger a windowed pull)
  • 24/7 metrics (heart rate, steps, calories, distance, SpO2, respiratory rate, body measurements, etc.) come from dataTypes/{dataType}/dataPoints:reconcile (default) or dataTypes/{dataType}/dataPoints (list) at native resolution, or dataTypes/{dataType}/dataPoints:rollUp when an hourly/daily granularity is configured
  • reconcile merges and deduplicates datapoints across all contributing source apps to match what the native Google Health app shows; list returns raw per-source datapoints (carries dataSource). Steered by the GOOGLE_USE_RECONCILE flag (reconcile is the default)
  • Sleep sessions come from dataTypes/sleep/dataPoints, with full stages, duration, time in bed, and efficiency
  • Workouts come from dataTypes/exercise/dataPoints; ~150 Exercise.ExerciseType values mapped to the unified workout taxonomy
  • Identity (healthUserId) is read from users/me/identity and stored as the provider user id for webhook routing
  • Webhooks are registered per GCP project at projects/{project}/subscribers; notifications are notify-only and only carry the changed window, which is then pulled via the operations above
  • Coverage in the matrix above is the union of both paths; the cloud API path alone does not populate every workout/sleep field the shared SDK pipeline does

Data Normalization

Open Wearables normalizes all incoming data to consistent units and formats:

Unit Standardization

All data is normalized to these canonical units:

Timestamp Handling

All timestamps are normalized to UTC with timezone information preserved when available:

Checking User Data Availability

To see what data is available for a specific user, query the connections endpoint:
Response shows which providers are connected:
Then query the timeseries endpoint to see available data: