Heart Rate Variability data from every wearable, in one schema
RMSSD and SDNN heart-rate variability from rings, straps and watches — as separate, clearly-labelled streams.
6 / 9
Providers connectable today
3
Webhook events in this family
milliseconds
Canonical units
What heart rate variability looks like through one API
HRV is the single most misused number in consumer health data. It is reported by nearly every serious wearable, it is the backbone of most recovery and readiness features, and it is almost never comparable between two devices — because "HRV" is not one measurement. It is a family of statistics computed over inter-beat intervals, and providers pick different ones.
WearLink does not flatten that difference. RMSSD and SDNN are emitted as separate series — series.heart_rate_variability_rmssd.created and series.heart_rate_variability_sdnn.created — because averaging them together produces a number with no physiological meaning. Apple Health reports SDNN; Oura and WHOOP work in RMSSD. If your code treats those as one field, your baselines are wrong for a subset of users and you will not notice.
The summary event carries the provider's own headline HRV figure with its method labelled, so you can either use the provider's convention or compute your own baseline from the underlying series.
Where providers disagree
The part that costs you weeks if you build this yourself. None of the following is a WearLink limitation — it is how the underlying providers actually behave.
RMSSD and SDNN are different statistics
RMSSD reflects short-term, parasympathetically-mediated variation; SDNN reflects total variability over the measurement window and scales with window length. SDNN values are typically larger than RMSSD for the same person. Charting them on one axis produces an artificial step change whenever a user switches device.
Measurement windows are not the same
Some providers report an overnight average across the whole sleep period, some a fixed early-morning window, some a rolling 5-minute sample. A longer window mechanically increases SDNN. Compare a user to their own history on the same device, not to a population figure or to their previous device.
Artefact filtering is invisible and inconsistent
HRV is computed from inter-beat intervals, and optical sensors miss and mis-time beats. Every vendor applies its own artefact-rejection pass before computing the statistic, and none of them tell you how aggressive it was or how many beats were discarded. Two devices that recorded the same night can therefore differ because of cleaning, not physiology. A night with poor sensor contact can produce a plausible-looking HRV value derived from a small fraction of the intervals, with nothing in the payload to warn you. Where a provider exposes a confidence or coverage figure WearLink passes it through; where it does not, treat single-night swings with suspicion and prefer multi-day baselines.
Absolute values are close to meaningless across people
HRV varies enormously between individuals for reasons unrelated to fitness or recovery — age dominates. Products that show a user their raw HRV next to a "normal range" tend to generate support tickets. Baseline per user, then show deviation.
Providers that supply heart rate variability
Status is read from the same provider table the rest of the site uses, so nothing here can claim a provider is connectable when it is not. Coverage also varies by hardware generation within a brand.
| Provider | Category | Status |
|---|---|---|
| Oura | Cloud OAuth | Live |
| WHOOP | Cloud OAuth | Live |
| Fitbit | Cloud OAuth | Live |
| Garmin | Cloud OAuth | Onboarding |
| Polar | Cloud OAuth | Onboarding |
| Ultrahuman | Cloud OAuth | Onboarding |
| Apple Health | Mobile SDK | Mobile SDK |
| Google Health Connect | Mobile SDK | Mobile SDK |
| Samsung Health | Mobile SDK | Mobile SDK |
Webhook events for heart rate variability
Subscribe to the summary event for settled records, and to the series streams when you need the underlying samples. Event names below are generated from the backend enum, so they cannot drift out of date relative to the API.
Summary object
heart_rate_variability.created
Series streams
series.heart_rate_variability_rmssd.createdseries.heart_rate_variability_sdnn.createdFrequently asked questions
- Does WearLink return RMSSD or SDNN?
- Both, as separate event streams, labelled by method. WearLink does not convert between them because no valid conversion exists — they measure different things.
- Which devices report HRV through WearLink?
- Oura, WHOOP, Fitbit, Garmin, Polar and Ultrahuman on the cloud side, plus Apple Health, Health Connect and Samsung Health via SDK push. Coverage varies by hardware generation within each brand.
- Can I build a readiness score from WearLink HRV data?
- Yes, and it is a common use of the series streams. Use a per-user rolling baseline over at least 14 days and express the current value as a deviation from it. Do not mix RMSSD and SDNN inside one baseline.
Related data types
15 normalised data families in total — see them all or browse integrations by provider.