---
title: "Respiratory Rate API: How to Get Breathing-Rate Data"
canonical: "https://aifitnessapi.com/data/respiratory-rate-api"
cluster: "Health Data"
primary_query: "respiratory rate api"
last_reviewed: "2026-08-12"
description: "Read respiratory rate from HealthKit, Health Connect, and wearable APIs. The schemas hold a number and a timestamp, and never say how it was derived."
publisher: "AIFitnessAPI — independent, not sponsored"
cite_as: "\"Respiratory Rate API: How to Get Breathing-Rate Data\", AIFitnessAPI, https://aifitnessapi.com/data/respiratory-rate-api"
---

# Respiratory Rate API: How to Get Breathing-Rate Data

> Respiratory rate is exposed as a bare number on both mobile platforms. Apple HealthKit defines HKQuantityTypeIdentifier.respiratoryRate as discrete samples in count over time units, and states that the system records them automatically on Apple Watch. Android Health Connect defines RespiratoryRateRecord in the Vitals category with only rate, time, and metadata, where rate is breaths per minute with a valid range of 0 to 1000. Neither type carries a method or provenance field, so the store cannot tell you whether a value came from a wearable algorithm, a medical device, or someone typing. On our pages, Oura returns respiratory rate inside its sleep payload and Fitbit documents a respiratory_rate OAuth scope; other vendors are not documented here, so verify them.

- Canonical: https://aifitnessapi.com/data/respiratory-rate-api
- Last reviewed: 2026-08-12
- Publisher: AIFitnessAPI (https://aifitnessapi.com) — independent, not sponsored
- Cite as: "Respiratory Rate API: How to Get Breathing-Rate Data", AIFitnessAPI, https://aifitnessapi.com/data/respiratory-rate-api

---

Respiratory rate is one of the quietest fields in a health store. It arrives without the user asking for it, it is a single small number, and both platforms define it in about three lines. That brevity is the problem: the schemas are so thin that they tell you almost nothing about where the number came from, and a breathing-rate chart is very easy to build and very easy to build wrong.

## What the two platform stores actually define

Apple documents `HKQuantityTypeIdentifier.respiratoryRate` as "A quantity sample type that measures the user's respiratory rate," available from iOS 8.0 and watchOS 2.0. The discussion is short and worth reading literally: these samples use count/time units, they measure discrete values, and "The system automatically records samples on Apple Watch."

Two things follow. First, the unit is not fixed for you — count over time means you choose the `HKUnit` when you read and when you write, and reading in counts per second when you expected counts per minute is a factor-of-sixty bug that looks plausible enough to survive review. Second, on Apple Watch the samples appear on their own. Your app does not trigger a measurement and cannot ask for one; you request read authorization and see whatever the system has already recorded.

Health Connect's `RespiratoryRateRecord` is thinner still. It sits in the Vitals category as an instantaneous record type, with `metadata`, `rate`, and `time` as its mandatory fields, gated on `android.permission.health.READ_RESPIRATORY_RATE` and `android.permission.health.WRITE_RESPIRATORY_RATE`. The Kotlin reference describes it as capturing "the user's respiratory rate," where "Each record represents a single instantaneous measurement," and pins the unit down explicitly: `rate` is a `Double`, "Respiratory rate in breaths per minute. Required field. Valid range: 0-1000." The constructor takes only `time`, `zoneOffset`, `rate`, and `metadata`.

A valid range topping out at 1000 breaths per minute is not a sanity check. The store will happily hold physiologically impossible values, so range filtering is your job, not the platform's.

## Where you can get it

| Source | What it gives you | How you access it | Verified from |
|---|---|---|---|
| Apple HealthKit | `HKQuantityTypeIdentifier.respiratoryRate` — discrete samples in count/time units; recorded automatically on Apple Watch | On-device read with per-type authorization; no cloud pull | Apple HealthKit developer documentation for the identifier, fetched 2026-08-12 |
| Android Health Connect | `RespiratoryRateRecord` — a single instantaneous `rate` in breaths per minute | On-device read/write via the Health Connect client and the respiratory-rate permissions | Health Connect data types page and the `RespiratoryRateRecord` Kotlin reference, fetched 2026-08-12 |
| Oura API v2 | Respiratory rate as part of the sleep payload, alongside sleep stages and HRV | Cloud OAuth 2.0, after the ring syncs | Documented on our [Oura vs WHOOP](/compare/oura-vs-whoop) comparison |
| Fitbit Web API | A `respiratory_rate` OAuth scope appears in the documented scope list | Cloud OAuth 2.0 | Documented on our [Fitbit API integration guide](/integrate/fitbit-api) — verify the current scope list and endpoints |
| WHOOP, Garmin, Strava | Not documented on our pages — verify in each vendor's live data dictionary | Cloud OAuth where a field exists at all | Not documented on our pages |
| Aggregators (Terra, Junction, Rook) | Whatever the underlying source supplies, under one normalized schema | One cloud API plus webhooks | Not documented on our pages — verify |

Note what the Oura row implies. Where a vendor does expose respiratory rate, it can arrive inside a sleep object rather than as a standalone time series — which means the metric's availability is tied to whether the user slept with the device on, not to whether they wore it that day.

## Nobody tells you where the number came from

This is the part to get right before you draw anything. Neither platform type carries a method or source field. Health Connect's record has `rate`, `time`, and `metadata` — nothing else. Apple's is a bare quantity sample. Compare that with `Vo2MaxRecord`, which carries a `measurementMethod` field precisely so a consumer can tell an estimate from a metabolic-cart reading (see [VO2 max API](/data/vo2-max-api) for how that plays out). Respiratory rate has no equivalent.

So the same `RespiratoryRateRecord` could hold a value produced by a wearable's algorithm overnight, a value from a dedicated medical device, or a value a clinician's app or the user themselves typed in. Both platforms expose a write permission, so anything in the store may have been written by another app entirely. The only provenance you get is `metadata`, and the only honest UI is one that names the source rather than presenting "your breathing rate" as a platform fact.

Nor do the platform docs state how any given wearable derives the number. Apple's page says the system records samples on Apple Watch; it does not say from what signal. That gap is the whole story for accuracy claims. A wrist device has no spirometer and no chest band, so whatever it reports has been worked out from other sensor data by a method the vendor has not published in the platform docs — and none of the sources checked here document that method. Do not tell users what their breathing rate "means," and do not compare a value from one brand against a value from another as though they were the same measurement. Treat it the way our [heart rate API](/data/heart-rate-api) page treats derived aggregates: a within-person trend, framed as a wellness signal.

Questions worth asking a vendor before you display their numbers:

- Over what window is the value computed — a whole night, a sleep stage, a spot check?
- Is it produced only during sleep, or also while awake?
- What sensor signal is it derived from, and has that derivation been validated against anything?
- Does the API return one value per night, or a series?
- Which devices in their lineup produce it at all?

## The traps

- **No built-in aggregates.** Health Connect lists aggregate metrics for plenty of vitals — blood pressure has systolic and diastolic averages, minima, and maxima; resting heart rate has BPM averages — but the data types page lists none for `RespiratoryRateRecord`. If you want a nightly average, compute it yourself from the records you read.
- **Instantaneous, so there is no nightly value.** Both stores hold point-in-time samples. "Last night's respiratory rate" is a definition you invent, and you should be able to say which samples went into it.
- **The unit trap on iOS versus Android.** Health Connect fixes breaths per minute. HealthKit gives you count over time and lets you pick. Normalizing across the two without pinning the unit on the iOS side is a silent data-corruption path.
- **Time zones.** Health Connect records carry `time` plus a nullable `zoneOffset` describing the user's experienced offset; when it is absent, queries assume the current system offset. For an overnight metric that already straddles midnight, getting this wrong shifts readings onto the wrong day — the same day-boundary problem that bites sleep data.
- **Background and history need their own permissions.** Reading while your app is in the background requires `android.permission.health.READ_HEALTH_DATA_IN_BACKGROUND`, and reading data older than 30 days requires `android.permission.health.READ_HEALTH_DATA_HISTORY`, declared separately from the data-type permission.
- **Sparse by nature.** If the value is generated during sleep, a user who naps, travels, or charges their device overnight simply has no record for that day. Design the empty state first.

## Keep the claims small

Breathing rate is a vital sign, and a feature that flags it, sets thresholds on it, or hints at what a change might indicate is a different product from one that shows a trend line. Which side of that line you land on depends on what your app claims, not which API returned the number. Our [FDA fitness app regulation](/compliance/fda-fitness-app-regulation) page sets out how the general-wellness versus medical-device framing is usually drawn — use it as vocabulary for a conversation with counsel, not as a substitute for one. Nothing here is medical or legal advice, and your UI copy should not read like either.

## Before you ship

Re-verify the identifiers, mandatory fields, permission strings, and valid ranges against the live Apple and Google references — these move. Pin the HealthKit unit explicitly. Filter implausible values yourself, because the store will not. Record and display the source of every value, since the schema will not tell you. And for any vendor field, confirm the measurement window and device coverage in that vendor's own data dictionary rather than inferring it from the fact that a number showed up.

## FAQ

### What unit does respiratory rate use on HealthKit versus Health Connect?

Health Connect fixes it: RespiratoryRateRecord exposes rate as a Double documented as respiratory rate in breaths per minute, with a valid range of 0 to 1000. Apple leaves it open: HKQuantityTypeIdentifier.respiratoryRate uses count over time units, so you choose the HKUnit on read and on write. Normalizing between the two platforms without pinning the unit on the iOS side is a quiet factor-of-sixty bug, so store the unit alongside every value.

[Permalink](https://aifitnessapi.com/data/respiratory-rate-api#faq-1)

### Does the API tell me how a breathing-rate value was produced?

No. Neither platform type carries a method or source field. Health Connect's record holds only rate, time, and metadata, and Apple's is a bare quantity sample, so the same record could hold a wearable's derived value, a reading from a dedicated device, or a number a person typed. Compare Vo2MaxRecord, which does carry a measurementMethod field. The only provenance available is the record metadata, so name the source in your UI rather than presenting the figure as a platform fact.

[Permalink](https://aifitnessapi.com/data/respiratory-rate-api#faq-2)

### Can Health Connect compute a nightly average respiratory rate?

Not for you. The Health Connect data types page lists aggregate metrics for several vitals, such as systolic and diastolic averages for blood pressure and BPM averages for resting heart rate, but lists none for RespiratoryRateRecord. The record is also an instantaneous type, so there is no built-in nightly value at all. If you want an overnight average, read the individual records and compute it yourself, and be able to say which samples went into it.

[Permalink](https://aifitnessapi.com/data/respiratory-rate-api#faq-3)

### Which wearable APIs return a breathing rate field?

On our pages, Oura API v2 returns respiratory rate as part of its sleep payload alongside sleep stages and HRV, and Fitbit's documented OAuth scope list includes respiratory_rate. Apple HealthKit covers the metric among its data types. WHOOP, Garmin, and Strava are not documented on our pages for this metric, so verify them in each vendor's live data dictionary. Where the value lives in a sleep object, availability depends on the user sleeping with the device on.

[Permalink](https://aifitnessapi.com/data/respiratory-rate-api#faq-4)

### Does an Apple Watch record breathing rate on its own?

Apple's documentation for the respiratory rate quantity type states that the system automatically records samples on Apple Watch. Your app does not trigger a measurement and cannot request one; you ask for read authorization and see whatever has already been recorded. The docs do not state which sensor signal the value is derived from, so treat it as a within-person wellness trend and avoid comparing values across brands as if they were the same measurement.

[Permalink](https://aifitnessapi.com/data/respiratory-rate-api#faq-5)