Heart Rate API: How to Get Heart-Rate Data Into Your App
Updated July 24, 2026
Heart rate (HR) is a measured signal — most consumer devices read it from a PPG optical sensor (green or infrared LEDs at the wrist or finger), while chest straps use electrical, ECG-style sensing. You get HR into an app from three kinds of source: the on-device platform stores (Apple HealthKit on iOS, Android Health Connect), the cloud APIs of nearly every wearable vendor (Fitbit, Garmin, Oura, WHOOP, Strava), and aggregators that normalize all of them behind one schema. HR itself is measured and wellness-grade, not an ECG or arrhythmia diagnostic; values like resting and walking-average HR are derived aggregates of that measured data. Best pick in one line: for live in-workout HR use on-device (or a direct chest strap), and for all-day and resting HR across many devices use per-vendor cloud OAuth or an aggregator.
Where you can get it
Heart rate shows up as several distinct shapes — continuous (intraday) samples, a once-daily resting value, spot readings, and per-workout streams. The table below maps the common sources; every field name, scope, and device-coverage claim is volatile, so treat it as "as of 2026, verify" against the provider's live data dictionary.
| Source | How you access it | Notes |
|---|---|---|
| Apple HealthKit | On-device read (iOS), per-type permission; no cloud pull | HKQuantityTypeIdentifierHeartRate (general samples), HKQuantityTypeIdentifierRestingHeartRate, walkingHeartRateAverage, heartRateRecoveryOneMinute; beat-to-beat series via HKDataTypeIdentifierHeartbeatSeries. See the HealthKit integration guide. |
| Android Health Connect | On-device read (Android), per-record permission; no cloud pull | HeartRateRecord (a series of BPM samples). See on-device vs cloud health data. |
| Fitbit Web API | Cloud OAuth 2.0 | Heart Rate Time Series including resting HR; intraday HR needs Intraday approval — verify. |
| Garmin Health API | Cloud OAuth 2.0 | HR is part of daily summaries / epochs. |
| Oura API v2 | Cloud OAuth 2.0 | heartrate endpoint (timestamped BPM); interbeat_interval (IBI). Verify endpoint names in live docs. |
| WHOOP API v2 | Cloud OAuth 2.0 | HR contributes to Recovery (resting HR) and cycle/workout data. |
| Strava API | Cloud OAuth 2.0 | HR only as a per-workout activity stream (BPM) — no resting or all-day HR. |
| Aggregators (Terra, Junction, Rook) | One cloud API + webhooks over many providers | Normalize HR and resting HR across sources. See health data aggregator APIs. |
For the per-vendor cloud route and how the wearable APIs compare, see wearable data APIs.
Measured or estimated?
Heart rate is measured, not modeled. The caveat is accuracy conditions, not the nature of the metric: optical PPG accuracy degrades with motion, cold, tattoos, and poor sensor fit, so accuracy varies by device and conditions — do not rely on a single published accuracy percentage, and verify any device-specific claim. Resting HR and walking-average HR are derived aggregates computed once daily from measured samples, not live readings.
A few sampling and timing gotchas to plan around:
- "Continuous" HR is usually sampled (every few seconds to minutes at rest, faster in workouts), not truly beat-by-beat, and higher-resolution intraday data can require extra scopes or approval — verify per provider.
- Resting HR is a once-daily aggregate, not something you can poll for a live number.
- Cloud data is latent: it lands only after the user's device syncs to the vendor cloud, so it is not suitable for hard real-time.
One honest framing to keep: consumer HR is a general wellness signal, not a clinical diagnostic. Apple's ECG and irregular-rhythm notifications are separate, regulated features — do not present ordinary HR samples as arrhythmia detection.
Which should you pick?
Match the source to the shape of HR you need:
- Live in-workout HR (real-time): read on-device via a HealthKit workout session or Health Connect, or connect directly to a chest strap over the BLE Heart Rate Profile. Cloud APIs are too latent for this.
- All-day and resting HR across many devices: cloud OAuth per provider, or an aggregator so you avoid maintaining N separate integrations.
- Activity route plus HR for athletes: Strava streams — but note they are workout-scoped only, with no resting or continuous all-day HR.
- On-device privacy over cloud reach: HealthKit and Health Connect keep the read on the user's phone with no server-to-server pull; you upload it yourself only if you need it server-side.
Before you ship
Confirm the current field names, endpoints, scopes, and device coverage in each provider's live data dictionary — these change often and are flagged "as of 2026, verify." And keep the framing honest: heart rate from a consumer wearable is a measured wellness signal, not a medical-grade or diagnostic reading.
Frequently asked questions
- Is heart rate from a wearable measured or estimated?
- Heart rate itself is measured, not modeled. Most consumer devices read it optically with a PPG sensor (green or infrared LEDs at the wrist or finger); chest straps use electrical, ECG-style sensing. What varies is accuracy under conditions: optical PPG degrades with motion, cold, tattoos, and poor fit, so accuracy depends on the device and situation. Resting and walking-average heart rate are derived aggregates computed from measured samples, not live readings. It is a wellness signal, not a clinical diagnostic.
- How do I get real-time heart rate into an app?
- For live, in-workout HR, read on-device through a HealthKit workout session on iOS or Android Health Connect, or connect directly to a chest strap over the Bluetooth Low Energy Heart Rate Profile. Cloud wearable APIs (Fitbit, Garmin, Oura, WHOOP, Strava) are too latent for hard real-time because their data only lands after the user's device syncs to the vendor cloud. Verify current on-device session behavior in each platform's docs.
- Which data types expose heart rate on HealthKit and Health Connect?
- On Apple HealthKit, general samples come from `HKQuantityTypeIdentifierHeartRate`, with `HKQuantityTypeIdentifierRestingHeartRate`, `walkingHeartRateAverage`, and `heartRateRecoveryOneMinute` for derived values, plus the beat-to-beat `HKDataTypeIdentifierHeartbeatSeries`. On Android Health Connect, use `HeartRateRecord`, a series of BPM samples. Both are on-device reads that need per-type user permission and have no cloud pull. Confirm exact identifiers in each platform's live data dictionary.
- Can I get all-day and resting heart rate from Strava?
- No. Strava exposes heart rate only as a per-workout activity stream in BPM, not resting or continuous all-day HR. For resting HR and continuous intraday data across devices, use per-vendor cloud OAuth (Fitbit, Garmin, Oura, WHOOP) or an aggregator that normalizes them. Note that resting HR is a once-daily derived aggregate, not a value you can poll live. Verify each provider's current fields and scopes.
- Should I use an aggregator or integrate each wearable directly?
- Integrate directly when you support one or two sources or need on-device, low-latency reads; that keeps the data path simple. Use an aggregator such as Terra, Junction, or Rook when you want all-day and resting HR from many wearables behind one normalized schema and webhooks, so you avoid building and maintaining a separate OAuth integration per vendor. Verify each aggregator's current source list and normalized fields in its own docs.
Keep reading
Independent comparison, last reviewed July 24, 2026. Pricing, rate limits, and feature availability change often — confirm current details in each provider’s official documentation before you commit. Product and company names are trademarks of their respective owners; AIFitnessAPI is not affiliated with, endorsed by, or sponsored by any product listed here.
← All health data · by AIFitnessAPI