--- title: "Heart Rate API: How to Get Heart-Rate Data Into Your App" canonical: "https://aifitnessapi.com/data/heart-rate-api" cluster: "Health Data" primary_query: "heart rate api" last_reviewed: "2026-07-24" description: "Get heart-rate data via HealthKit, Health Connect, and wearable cloud APIs. HR is measured and wellness-grade. Compare sources and pick the right one." publisher: "AIFitnessAPI — independent, not sponsored" cite_as: "\"Heart Rate API: How to Get Heart-Rate Data Into Your App\", AIFitnessAPI, https://aifitnessapi.com/data/heart-rate-api" --- # Heart Rate API: How to Get Heart-Rate Data Into Your App > Heart rate is a measured signal, read on consumer devices from a PPG optical sensor (chest straps use electrical ECG-style sensing). You get it into an app from on-device stores (Apple HealthKit `HKQuantityTypeIdentifierHeartRate`, Android Health Connect `HeartRateRecord`), from nearly every wearable cloud API (Fitbit, Garmin, Oura, WHOOP, Strava), or from an aggregator that normalizes all of them. HR itself is measured and wellness-grade, not an ECG or diagnostic; resting and walking-average HR are derived aggregates. Best pick: on-device or a chest strap for live in-workout HR, and cloud OAuth or an aggregator for all-day and resting HR across many devices. - Canonical: https://aifitnessapi.com/data/heart-rate-api - Last reviewed: 2026-07-24 - Publisher: AIFitnessAPI (https://aifitnessapi.com) — independent, not sponsored - Cite as: "Heart Rate API: How to Get Heart-Rate Data Into Your App", AIFitnessAPI, https://aifitnessapi.com/data/heart-rate-api --- ## 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](/integrate/healthkit). | | 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](/learn/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](/fitness-apis/health-data-aggregator-apis). | For the per-vendor cloud route and how the wearable APIs compare, see [wearable data APIs](/fitness-apis/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. ## FAQ ### 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. [Permalink](https://aifitnessapi.com/data/heart-rate-api#faq-1) ### 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. [Permalink](https://aifitnessapi.com/data/heart-rate-api#faq-2) ### 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. [Permalink](https://aifitnessapi.com/data/heart-rate-api#faq-3) ### 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. [Permalink](https://aifitnessapi.com/data/heart-rate-api#faq-4) ### 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. [Permalink](https://aifitnessapi.com/data/heart-rate-api#faq-5)