Skip to main content
A wearable having a sensor and your app being able to read it are two different things. This page is the reality check: what each supported wearable actually delivers into Synheart Wear, what it does not, and what the data becomes once it is downstream.

​
The three gates

A physiological signal reaches your app only if it clears all three gates:
  1. The device has the sensor. No optical SpO2 sensor on the strap means no SpO2, regardless of software.
  2. The vendor exposes the data. Many sensors feed only the vendor’s own app and are never published on a public API, SDK, or standard BLE profile. A sensor that exists but is not exposed is, for an integrator, the same as no sensor.
  3. Synheart Wear has an adapter for that path. Synheart Wear normalises the paths a vendor does expose — HealthKit, Health Connect, standard BLE, OAuth cloud APIs, the licensed Garmin Health SDK. It does not reverse-engineer private protocols.
A signal that clears all three is still either real-time (streamed as it is measured) or historical (delivered in batches after the device syncs). That distinction is as important as availability — see the matrix below.

​
What Synheart Wear delivers

Every adapter normalises into the unified WearMetrics shape. These keys are the stable, cross-vendor contract:
Signalmetrics keyTypical pathNotes
Heart ratehrReal-time (BLE) or historicalProduced by every adapter.
Heart rate variabilityhrv_rmssd, hrv_sdnnHistoricalComputed over the adapter’s window; SDNN may be derived on-device from RR.
Inter-beat (RR) intervalsrr_ms (top-level)Real-time when the source provides itThe highest-fidelity cardiac signal — see tiers.
Steps, calories, distancesteps, calories, distanceHistoricalPeriod totals.
StressstressHistoricalA vendor-specific score (e.g. Garmin 0–100); not normalised across vendors.
Signals that are not part of the normalised WearMetrics contract today:
SignalStatus
SpO2 / blood oxygenNot a normalised WearMetrics key. Real-time SpO2 is available only through the licensed Garmin Health SDK (see Garmin). Cloud vendors hold a nightly value, but Synheart Wear does not surface it.
ECGNot exposed by any adapter.
Skin / wrist temperatureNot exposed by any adapter.
EDA (electrodermal activity)Not available from any supported wearable — see below.

​
EDA: why it is not here

Electrodermal activity is the most restricted signal in consumer wearables. There is currently no supported device that gives a third-party integrator open EDA access:
  • Apple Watch, WHOOP, Oura — no EDA sensor on any model.
  • Fitbit Sense / Sense 2 — have an EDA sensor, but Fitbit never exposes EDA scan data through the Web API; it stays inside the Fitbit app.
  • Samsung Galaxy Watch — exposes EDA only through Samsung’s partner-gated privileged SDK, not the open Health Connect path.
The Synheart pipeline already recognises an eda signal as a physiological modality, so if a source ever exposes EDA it can flow through unchanged. But no Wear adapter produces it today, and these docs will not claim otherwise. If your use case depends on EDA, treat it as unavailable until a device vendor opens that path.

​
Per-device reality

WearableAccess pathReal-time signalsHistorical signalsGate
Apple WatchHealthKitHR (companion watchOS app)HRV, RR (workout), steps, calories, distanceLive HR needs a companion watchOS app
WHOOPBLE Broadcast / cloud APIHR, RR (BLE)recovery, strain, sleep (cloud)OAuth for the cloud path
Garmin (Connect)Cloud API—HR, HRV, stress, sleepOAuth + program approval
Garmin (Health SDK)On-device RTSHR, RR, respiration, stress, SpO2—Garmin commercial license
FitbitCloud API—HR, HRV, sleep, activityOAuth
OuraCloud API / health-store proxy—HRV, sleep, temperature, SpO2 (daily)OAuth
BLE HRMBLE Heart Rate Profile (0x180D)HR, RR (optional)—Bluetooth permission
Samsung—plannedplannedplanned

​
Apple Watch

HealthKit is the only public path — there is no raw-sensor or BLE API on Apple Watch. HR, HRV (SDNN), steps, calories, and distance arrive as historical samples. Real-time HR is possible, but only with a companion watch app — see Smartwatches need a companion app below.

​
WHOOP

WHOOP illustrates gate 2 directly. The strap has more sensors than it publishes — but it does expose HR (and RR) through standard BLE Broadcast Heart Rate mode, so HR is supported, in real time, via the shared BLE HRM adapter. The WHOOP cloud API adds recovery, strain, and sleep as historical summaries over OAuth. WHOOP has no EDA sensor; its 4.0-and-later SpO2 and skin-temperature values live in the cloud API but Synheart Wear surfaces neither today.

​
Garmin

Garmin has two paths with very different gates:
  • Garmin Connect API — cloud, historical only: HR, HRV, stress, sleep, Pulse Ox. Delivered as summaries after the device syncs.
  • Garmin Health SDK (Real-Time Streaming) — on-device streaming of HR, beat-to-beat RR, respiration, stress, and SpO2 / Pulse Ox. This is the direct integration that yields real-time SpO2.
The Health SDK RTS path is commercially licensed by Garmin. The GarminHealth façade is bundled on demand for licensed integrations only; without that license, Garmin data is limited to the historical Connect API. See Adapters → Garmin Health SDK.

​
Fitbit and Oura

Both are cloud OAuth integrations mediated by the Synheart Wear API — the device never sees vendor access tokens. They deliver historical, sync-based data only: there is no real-time path. Fitbit provides HR, HRV, sleep, and activity; Oura provides readiness, sleep, HRV, temperature, and a daily SpO2 value. Neither exposes EDA or ECG to integrators.

​
BLE heart rate monitors

The standard BLE Heart Rate Profile (0x180D) carries exactly two things: HR and — when the device sets the optional flag — RR intervals. Nothing else. Richer vendor data (Polar raw ECG, accelerometer) lives only behind each vendor’s proprietary SDK, which Synheart Wear does not use. What you get is real-time HR + RR from any compliant strap, with no cloud and no OAuth.

​
Smartwatches need a companion app

A smartwatch — Apple Watch or a Wear OS device — is not like a BLE chest strap. The strap streams HR and RR over a standard Bluetooth profile the moment you connect. A smartwatch does not: its OS gates continuous sensor access behind an app running on the watch itself. Without a watch app:
  • watchOS — an iPhone-only app reads HealthKit, but there is no live stream. Background delivery is batched and throttled to roughly a handful of updates per hour. You get historical samples, not real-time data.
  • Wear OS — an Android phone app reads Health Connect, but the same limit applies: passive monitoring delivers batched, low-frequency data, with no continuous stream to a phone-only app.
With a small companion watch app:
  • The app holds an active workout/exercise session, which keeps the optical sensor running at high frequency.
  • It streams frames to the phone in real time over the platform’s watch channel (WatchConnectivity on watchOS, the Wearable Data Layer on Wear OS).
  • It can compute HR/HRV metrics on the watch — so the phone receives derived metrics, not just a raw HR trace.
Synheart Session is the SDK for exactly this. Its on-watch SessionEngine runs on both watchOS and Wear OS, computes session frames locally, and streams them to the phone — with a transparent local-engine fallback when no watch is reachable. If your app needs continuous or real-time data from a smartwatch, this is the path; see the watch protocol for the wire format.
CapabilityBLE chest strapSmartwatch, phone-onlySmartwatch + companion app
Real-time HR✅ direct❌ batched / throttled✅ streamed from the watch
RR intervals✅ when device sends them❌✅
On-watch metricsn/a❌✅ HR/HRV computed on the watch
Extra app to buildnonenonea small watch app
That tradeoff is the core decision for any smartwatch integration: phone-only is simpler but historical; a companion app is the only route to real-time data.

​
From raw signals to processed state

Synheart Wear gives you normalised raw readings. It does not interpret them — it will not tell you the user is stressed, recovered, or focused. That interpretation is a separate layer. 
wearable ──► Synheart Wear ──► normalised WearMetrics (HR, HRV, RR, …)
                                        │
                                        ▼  add Synheart Core
                               Synheart Runtime
                       feature pipeline → HSV inference → flux
                                        │
                                        ▼
                     HSI 1.3  (focus, capacity, recovery,
                               strain, emotion, sleep)
  • Synheart Wear alone — raw normalised readings. Right for displaying live numbers, threshold alerts, and logging.
  • Synheart Wear + Synheart Core — the runtime fuses the signals on-device and emits processed human state as HSI 1.3. Right for “is the user recovered / focused / strained” questions.
Signal fidelity carries all the way through. The runtime caps inference confidence by how good the raw signal was — native beat-to-beat RR is tier 1 and supports high-confidence inference; a lone HR snapshot is tier 4 and is capped low. So the quality of what you get out of a wearable directly bounds the quality of the processed state. See the tier-capped confidence table.