Apple HealthKit API: What Data You Can Access and How
Key Takeaways
- HealthKit is an on-device framework, not a remote API: health data lives on the user's iPhone and Apple Watch, not on Apple's servers
- There is no server-to-server Apple Health API; getting data to your backend requires an iOS app component that reads and uploads it
- Available data includes heart rate, HRV, sleep stages, workouts, steps, SpO2, VO2 max, respiratory rate, body measurements and blood glucose
- Permissions are granted per data type; users can revoke individual types without your app being notified
- Open Wearables provides an iOS SDK and backend pipeline that handles the full HealthKit-to-server flow
Introduction
Apple Health sits at the center of health data on iOS. It aggregates signals from Apple Watch, third-party apps, connected devices and manual entries into a single on-device store. With over a billion active iPhone users and a large Apple Watch install base, it is often the only structured health data source available for a significant segment of any health app's user base.
But HealthKit works fundamentally differently from every other wearable API. There is no REST endpoint to call. There is no OAuth flow to redirect users through. There is no server-side token to manage. Data lives on the user's device and cannot leave it without your iOS application explicitly reading it and uploading it.
This has profound implications for how you architect an Apple Health integration. Everything that other providers handle server-side, including authentication, data access, and delivery, you have to build into an iOS app. For developers with strong backend experience and limited iOS experience, this is the largest conceptual hurdle in the Apple Health integration.
What HealthKit Provides
HealthKit covers a broad range of health metrics organized into three categories: quantity types (numerical measurements), category types (enumerated values like sleep stages), and correlation types (grouped measurements like blood pressure).
Heart and circulatory metrics include continuous heart rate from Apple Watch, resting heart rate (daily estimate based on overnight readings), walking heart rate average, and heart rate variability using the SDNN methodology. HRV from HealthKit is measured during the Breathe and Mindfulness exercises rather than during sleep passively, which distinguishes it from Whoop's or Oura's sleep-based HRV measurements.
Sleep data requires some nuance. Basic sleep analysis, the coarse in-bed versus asleep categorization, is available from HealthKit without Apple Watch. Detailed sleep staging (awake, REM, core sleep and deep sleep) requires watchOS 9 or later and an Apple Watch Series 3 or newer worn during sleep. The staging quality is generally considered adequate for wellness applications though not clinical grade.
Activity and workouts include step count, distance walked or run, floors climbed, active energy burned, basal energy burned, exercise minutes, stand hours and stand minutes. All Apple Watch workout types are available with associated metrics including heart rate throughout the workout, active calories, GPS data where the workout type supports it, and duration. VO2 max estimates are available from outdoor walk and run workouts.
Respiratory metrics include respiratory rate measured during sleep and SpO2 (blood oxygen saturation) from Apple Watch Series 6 and later. SpO2 is measured periodically during sleep and reported as a range or point value depending on the reading type.
Body measurements and metabolic data include body weight, height, BMI and body fat percentage (from compatible smart scales or manual entry), and blood glucose from continuous glucose monitors or manual entries.
The HealthKit Architecture Constraint
The most important thing to understand about HealthKit is that it is sandboxed to the device. Apple does not run a cloud service that aggregates HealthKit data. There is no server you can call with a user token to get their health data.
The only path from HealthKit to your backend is: your iOS application reads from HealthKit on the device and uploads the data to your backend. This requires building and maintaining an iOS application with the HealthKit entitlement, implementing the permission request flow, writing query logic for each data type you need, building background sync that works even when the app is not in the foreground, and handling the upload to your backend reliably.
This is meaningful engineering investment. If your product is primarily web-based or Android-first, adding Apple Health support requires an iOS app you may not otherwise need. Teams that skip iOS for initial launch often find Apple Health integration is the feature that forces them to build one.
Permissions and Privacy
HealthKit's permission model is granular and user-controlled. Permissions are granted per data type, not as a blanket consent. Users see exactly which types your app wants to read in the system permission sheet. They can grant all, some, or none. They can return to Settings later and revoke individual types.
Your application cannot detect which specific permissions a user has granted. HealthKit returns empty data rather than an authorization error for denied types. This prevents apps from using permission status as a proxy for health information. It also means you must build your app to handle partial permissions gracefully: never assume all requested permissions are granted, and always treat empty data for a type as potentially a permission issue rather than just an absence of data.
The request itself must be initiated from a user-visible context, typically in response to a user action rather than automatically at app launch. Requesting permissions at an appropriate moment in the user flow with a clear explanation of why each data type is needed significantly improves authorization rates.
Background Sync
For your app to sync HealthKit data when it is not in the foreground, you need to configure background delivery using HKObserverQuery. This registers your app to be woken by iOS when new data of a specified type arrives in HealthKit. Your app then has a limited window to process the new data before iOS suspends it again.
Background delivery frequency can be configured as immediate, hourly or daily depending on the data type and how fresh you need the data to be. For most health apps, hourly or daily delivery for most types with immediate delivery only for workout events is a reasonable balance.
The background wake window is short. Upload logic should be efficient: read only data newer than the last sync timestamp, serialize it, and make a single upload request to your backend. Do not attempt complex processing in the background wake handler.
Open Wearables and Apple Health
Open Wearables provides an iOS SDK that handles HealthKit permission requests, data querying, background delivery configuration and upload to your Open Wearables backend instance. On the server side, incoming Apple Health data is normalized to the same schema as Garmin, Whoop and Oura data.
For multi-provider apps, this means your product code works with one data model regardless of whether the user has an Apple Watch, a Garmin watch or a Whoop band.
FAQ
Can I access HealthKit data without building an iOS app?
No. HealthKit requires an iOS app with the HealthKit entitlement. There is no web or server-side API. If your product does not have an iOS app, you cannot integrate Apple Health.
What happens if a user revokes a HealthKit permission after granting it?
HealthKit will return empty data for that type rather than an error. You will not be notified of the revocation. Build your app to detect data gaps and surface a prompt to check permissions when a user's data has been unexpectedly absent for longer than expected.
What sleep staging quality can I expect from Apple Watch?
Apple's sleep staging (awake, REM, core and deep sleep) is available from watchOS 9+ and is considered adequate for wellness applications. It is not equivalent to polysomnography and should not be represented as clinical sleep analysis.
Does HealthKit work on iPad?
HealthKit is available on iPhone only. It requires a pairing between an iPhone and an Apple Watch for the richer biometric data types. iPad does not support HealthKit.
How do I backfill historical data when a user first connects?
Query HealthKit with a start date in the past. There is no API rate limit since queries run locally on the device. For very long histories with high-frequency data types like heart rate, chunk the queries by time window to manage memory usage.
Apple Health Integration
View the full Apple Health integration documentation on Open Wearables.
See Related Articles
Getting Apple Health Data Into Your Backend
Google Health Connect Integration: Android Health Data for Developers