HRV API
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 event types
Canonical unit
milliseconds
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
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.
Webhook events for heart rate variability
Summary: heart_rate_variability.created
Series streams:
series.heart_rate_variability_rmssd.createdseries.heart_rate_variability_sdnn.created
The full catalogue is in the event catalogue.
FAQ
Heart Rate Variability — frequently asked questions
Does WearLink return RMSSD or SDNN?
Which devices report HRV through WearLink?
Can I build a readiness score from WearLink HRV data?
Get heart rate variability from every device your users own
Free for up to 3 connected users. No credit card. Your first API key is issued the moment you sign up.