How to integrate Apple Health data into your app

Key Takeaways

• Apple Health does not expose a server-side REST API. The only way to read HealthKit data is on-device, which means your integration requires a mobile SDK.
• Open Wearables provides native iOS (Swift), Flutter (Dart), and React Native (TypeScript) SDKs that handle HealthKit permissions, observer queries, and background sync automatically.
• Authentication follows a secure token flow: your backend calls POST /api/v1/users/{user_id}/token with app credentials and returns the resulting access and refresh tokens to the mobile app. App credentials must never be embedded in client code.
• The SDK stores tokens in Keychain (iOS) or EncryptedSharedPreferences (Android) and handles token refresh automatically.
• Background sync uses iOS BGTaskScheduler and HealthKit observer queries, persists sync state across app restarts, and posts data to POST {host}/api/v1/sdk/users/{userId}/sync.
• For users with existing Apple Health exports (XML files), you can import them via REST API without any mobile SDK.
• Open Wearables is MIT-licensed, self-hosted, and free per user. Run the full stack locally with docker compose up -d.

Apple Health integration gives you access to some of the richest health data available on any consumer platform. Heart rate, steps, workouts, body composition, blood oxygen: it is all there, recorded continuously on hundreds of millions of devices. The challenge is getting that data into your application.

Most health data providers expose a cloud API. Your backend calls an endpoint, receives a JSON response, and you are done. Apple Health does not work that way.

Why Apple Health integration requires a mobile SDK

HealthKit data lives on the device and is not accessible from the cloud. There is no Apple-provided REST API you can call from your backend. Any integration with Apple Health data requires code running on the user's iPhone that reads from HealthKit and then pushes data to your systems. This is not a limitation of any particular library or approach. It is how HealthKit is designed.

As the Open Wearables documentation states directly: "Apple Health requires the Open Wearables mobile SDK. Cloud sync is not available for Apple Health."

Two integration paths

Open Wearables gives you two ways to complete your Apple Health integration and get data into your backend.

SDK-based real-time sync is the primary path for live applications. The mobile SDK runs on the user's device, requests HealthKit permissions, and continuously syncs new data to your backend.

Apple Health XML Import is the secondary path for historical data or migration scenarios. Apple lets users export their entire Health history as an XML file (Settings > Health > Export All Health Data). Records with the same external_id are not created twice.

Running the backend

            git clone https://github.com/the-momentum/open-wearables.git
docker compose up -d
          

The API is available at http://localhost:8000. All requests authenticate using the X-Open-Wearables-API-Key header. You can get an access token via POST /api/v1/auth/login.

The token flow

1. Your mobile app authenticates the user against your own backend.
2. Your backend calls POST /api/v1/users/{user_id}/token with your app credentials.
3. Your backend returns the resulting access_token and refresh_token to the mobile app.
4. The mobile app passes these tokens to the SDK.

The SDK stores tokens in Keychain on iOS and handles automatic refresh when they expire. App credentials stay server-side only.

Flutter integration

            await OpenWearablesHealthSdk.configure(
  host: 'https://api.openwearables.io',
);

final user = await OpenWearablesHealthSdk.signIn(
  userId: credentials['userId'],
  accessToken: credentials['accessToken'],
  refreshToken: credentials['refreshToken'],
);

await OpenWearablesHealthSdk.startBackgroundSync(syncDaysBack: 90);
          

iOS (Swift) integration

            sdk.configure(host: "https://api.openwearables.io")

sdk.signIn(
    userId: credentials.userId,
    accessToken: credentials.accessToken,
    refreshToken: credentials.refreshToken
)

sdk.startBackgroundSync(syncDaysBack: 90)
          

The SDK uses BGTaskScheduler for background execution and HealthKit observer queries to detect new data. Sync state persists across app restarts. Synced data is sent to POST {host}/api/v1/sdk/users/{userId}/sync.

Available data types

The SDK exposes via the HealthDataType enum: steps, heart rate, resting heart rate, sleep, workout, active energy, body mass.

XML import for historical data

For files under 10 MB:

            POST /api/v1/users/{user_id}/import/apple/xml/direct
          

For larger files:

            POST /api/v1/users/{user_id}/import/apple/xml/s3
          

The S3 endpoint accepts: filename (max 200 chars), expiration_seconds (60-3600), max_file_size (default 50 MB). Processing is asynchronous: "Import processing is asynchronous. Don't expect immediate data availability."

The XML importer supports workout metadata (activity types, duration, distance, calories, elevation), heart rate, steps, blood oxygen, and 100+ other metrics.

See Related Articles

• Building a health app with Whoop API data
• How to access Google Health Connect data in your backend
• How to use Oura ring data in your app
• Wearable API integration: comparing SaaS, custom build, and open source
• Getting Apple Health data into your backend

FAQ

Does Apple Health have a REST API for server-side access?

No. Apple Health data is stored on the user's device, not in Apple's cloud infrastructure. There is no server-to-server API. The only supported way to access HealthKit data programmatically is through a mobile SDK running on the device with the user's permission.

Which mobile platforms does the Open Wearables Apple Health SDK support?

iOS (Swift), Flutter (Dart), and React Native (TypeScript). All three connect to the same backend and produce the same normalized data format.

What is the difference between the Mobile SDK path and the XML Import path?

The Mobile SDK is for continuous background sync. The XML Import is for historical exports. For most production applications, you will use both: XML Import for onboarding historical data and the SDK for ongoing sync.

How does Open Wearables handle large Apple Health XML exports?

Files below 10 MB can be uploaded directly. For larger files, request a presigned S3 URL and upload to S3. Processing happens asynchronously on the backend.

Can the same Apple Health data be imported twice?

No. Open Wearables uses external_id deduplication. Records with the same external_id will not be duplicated.

What does it cost?

MIT licensed, self-hosted, no per-user fee.