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.
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:
- The device has the sensor. No optical SpO2 sensor on the strap means
no SpO2, regardless of software.
- 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.
- 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:
| 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. |
| 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. |
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). 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,
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
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.
| 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 |
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.
