> ## Documentation Index > Fetch the complete documentation index at: https://docs.synheart.ai/llms.txt > Use this file to discover all available pages before exploring further. # Wearable signals > What data you actually get from each supported wearable — the three access gates, the raw signals, and the processed human-state output. 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`](/synheart-wear/data-schema) shape. These keys are the stable, cross-vendor contract: | Signal | `metrics` key | Typical path | Notes | | ------------------------- | ------------------------------- | ------------------------------------- | ---------------------------------------------------------------------------------------- | | Heart rate | `hr` | Real-time (BLE) or historical | Produced by every adapter. | | Heart rate variability | `hrv_rmssd`, `hrv_sdnn` | Historical | Computed over the adapter's window; SDNN may be derived on-device from RR. | | Inter-beat (RR) intervals | `rr_ms` (top-level) | Real-time when the source provides it | The highest-fidelity cardiac signal — see [tiers](#from-raw-signals-to-processed-state). | | Steps, calories, distance | `steps`, `calories`, `distance` | Historical | Period totals. | | Stress | `stress` | Historical | A **vendor-specific** score (e.g. Garmin `0–100`); not normalised across vendors. | Signals that are **not** part of the normalised `WearMetrics` contract today: | Signal | Status | | ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | SpO2 / blood oxygen | Not a normalised `WearMetrics` key. Real-time SpO2 is available only through the licensed Garmin Health SDK (see [Garmin](#garmin)). Cloud vendors hold a nightly value, but Synheart Wear does not surface it. | | ECG | Not exposed by any adapter. | | Skin / wrist temperature | Not 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](/synheart-core/hsi-specification#modality--tier-derivation-in-the-sdk), 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 | Wearable | Access path | Real-time signals | Historical signals | Gate | | ------------------- | ------------------------------- | --------------------------------- | -------------------------------------------- | ------------------------------------- | | Apple Watch | HealthKit | HR (companion watchOS app) | HRV, RR (workout), steps, calories, distance | Live HR needs a companion watchOS app | | WHOOP | BLE Broadcast / cloud API | HR, RR (BLE) | recovery, strain, sleep (cloud) | OAuth for the cloud path | | Garmin (Connect) | Cloud API | — | HR, HRV, stress, sleep | OAuth + program approval | | Garmin (Health SDK) | On-device RTS | HR, RR, respiration, stress, SpO2 | — | Garmin commercial license | | Fitbit | Cloud API | — | HR, HRV, sleep, activity | OAuth | | Oura | Cloud API / health-store proxy | — | HRV, sleep, temperature, SpO2 (daily) | OAuth | | BLE HRM | BLE Heart Rate Profile (0x180D) | HR, RR (optional) | — | Bluetooth permission | | Samsung | — | planned | planned | planned | ### 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](#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](/synheart-wear/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](/synheart-wear/adapters#garmin-health-sdk-real-time-streaming). ### 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](/synheart-wear/ble-hrm) (`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](/synheart-session/overview) 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](/synheart-session/watch-protocol) for the wire format. | Capability | BLE chest strap | Smartwatch, phone-only | Smartwatch + companion app | | ------------------ | ------------------------ | ---------------------- | ------------------------------ | | Real-time HR | ✅ direct | ❌ batched / throttled | ✅ streamed from the watch | | RR intervals | ✅ when device sends them | ❌ | ✅ | | On-watch metrics | n/a | ❌ | ✅ HR/HRV computed on the watch | | Extra app to build | none | none | a 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. ```text theme={null} 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](/synheart-core/overview)** — the runtime fuses the signals on-device and emits **processed human state** as [HSI 1.3](/hsi/overview). 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](/synheart-core/hsv-specification#tier-capped-confidence). ## Related * [Wear Overview](/synheart-wear/overview) — full SDK surface and device matrix. * [Adapters](/synheart-wear/adapters) — per-vendor flow and capabilities. * [Data shape](/synheart-wear/data-schema) — the `WearMetrics` contract in detail. * [BLE Heart Rate Monitor](/synheart-wear/ble-hrm) — direct BLE HRM flow. * [How it fits together](/guides/how-it-fits-together) — where Wear sits in the stack.