The phone syncs to your cloud, not ours.
Apple Health, Health Connect and Samsung Health have no cloud API. These SDKs read them from inside your app and sync in the background to your own deployment.
Built on Open Wearables
What you get
What the SDK handles for you.
On-device sources have no webhook and no server to call, so the work moves into the app: permissions, background sync, incremental reads and credential storage.
Background sync that survives the app being closed.
Data keeps arriving with the app closed. An interrupted sync resumes where it stopped, even after a reboot.
- Background sync
- Resumable sessions
Only what changed since last time.
Anchored queries read only the delta, so battery and network cost stay flat. A failed sync never loses data or sends it twice.
- Anchored queries
- Incremental
- No duplicates
Four platforms, one integration.
The Apple Health SDK is native Swift, the Health Connect SDK native Kotlin, with Flutter and React Native wrapping the same core.
- Swift
- Kotlin
- Flutter
- React Native
Credentials that never reach the device.
Your backend mints a short-lived token per user. The app secret stays on your server, tokens in the secure keystore.
- Short-lived tokens
- Secure storage
The same schema as everything else.
Phone data lands in the same shape as cloud providers, so a watch and an iPhone come back in one query.
- One schema
- Steps
- Sleep
- Workouts
Your backend, not ours.
The sync endpoint is your deployment. Data goes from the phone to your infrastructure, with nothing in between.
- Your endpoint
- Your account
How it works
From install to first sync.
Swift, Kotlin, Dart and TypeScript packages. Setup per platform, including permissions and background configuration, is in the docs.
- 01
Point it at your deployment.
One call at app start tells the SDK where your backend is. There is no Open Wearables account, no dashboard and no key of ours, because the host is yours.
Terminal
configure(host: "https://api.yourcompany.com") - 02
Sign the user in with a token from your backend.
Your server mints a short-lived token scoped to one user and hands it to the app over your own authenticated API. The SDK takes it from there and refreshes it when it expires. Your app secret never leaves your server.
Terminal
signIn(userId: "user-id", accessToken: "...", refreshToken: "...") - 03
Ask for permission once.
The user grants access to their health store through the system dialog, inside your app and under your brand. You name the types you need, and the SDK handles what each platform considers a permission, which is not the same list on iOS and Android.
Terminal
requestAuthorization(types: [steps, heartRate, sleep, workout]) - 04
Data arrives in the background.
One call starts it. From then on the SDK reads incrementally and pushes to your deployment, and nobody has to open the app for a night of sleep to show up the next morning.
Mobile SDK guides in the docsTerminal
startBackgroundSync()
What your users see
Your app asks, their phone decides.
The SDK has no screens of its own. The request starts in your app and the consent is the phone's own permission screen, so there is no Open Wearables step to explain.
- 01
Your app starts it.
A Connect button wherever you put it, in your onboarding or your settings, under your brand and behind your existing login.
- 02
They pick the store.
Apple Health on an iPhone. On Android, Health Connect or Samsung Health, whichever the phone has, and the SDK connects to the one they pick.
- 03
The phone asks, in its own words.
Apple Health, Health Connect or Samsung Health shows its own permission screen for the data types you named. The request is read only: the SDK never asks to write.
- 04
They share what they choose.
The user can allow every type or only some, and the SDK reads only what was granted.
The honest comparison
Hosted API, in-house, or self-hosted.
Where each one wins. If a hosted API fits your situation, use one.
| Hosted SaaS API | Build in-house | Open Wearables, self-hosted | |
|---|---|---|---|
| [01] On-device sources | Their SDK in your app | Yours to build, per platform | Our SDK in your app, source included |
| [02] Where the phone uploads to | Their servers | Yours | Your deployment, your region |
| [03] Who can reach the data | The vendor and its sub-processors | Your team | Your team, and us under a DPA you sign when we work on it |
| [04] Platform changes | They absorb them | Your team tracks every OS release | Fixed in a release you pull |
| [05] Cross-platform | Depends on their wrappers | Two codebases, or a wrapper you maintain | Swift, Kotlin, Flutter and React Native |
| [06] Reading the sync code | Closed | Yours | MIT source you can fork |
| [07] Cost shape | Scales with monthly active users | Salaries and infrastructure | Fixed. Flattens as you grow |
Who is it for
Different industries, one constraint: the data cannot sit in somebody else's cloud.
Digital health products
Coaching, scoring and analytics on the devices your users already wear, with a security review somewhere ahead.
Learn moreHealth data platforms
Wearable data next to the clinical record you hold, running in your own cloud under your own credentials.
Learn moreRemote patient monitoring
Readings from the patient's own device, in the record their clinician reads, in the country the data must stay.
Learn moreClinical and research builders
Endpoints that survive review, for teams heading for DiGA, CE or FDA and for research under ethics approval.
Learn moreCare providers
Remote monitoring for care programmes, clinics, senior care and virtual wards, with a patient app and a care view for your team.
Learn moreHospitals and telemedicine
Wearable data written into your EHR, with a source for every reading that clinicians and auditors can trust.
Learn more
What you own
What you actually own at the end.
The deployment, the data and the algorithms stay in your account, whoever runs it. What that means in practice.
Sovereignty
Health data does not sit in a third party's cloud. Where that is your regulator's rule, your board's policy or your own, the deployment satisfies it by architecture rather than by contract.
Residency
The data stays in the region you chose, and you can prove where it is by pointing at an account rather than at a trust page.
Control
You run it under your own credentials and decide who gets access. What you build on top of Open Wearables is yours.
Your own reasons
No regulator forcing it. You want the data in your own account anyway, and that is a sufficient reason.
The three SDKs, and what each one reads.
Cloud providers connect server to server and need no app. These three live on the phone, so each one needs an SDK inside your app.
Apple Health SDK
Health Connect SDK
Samsung Health SDK
Deploy Open Wearables in your own cloud.
The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account with the SDK live in your app.
FAQ
Do you have more questions?
Do we need the SDK at all?
Only for on-device sources. Garmin, Polar, Whoop, Oura and the other cloud providers connect server to server and work without an app. Apple Health, Health Connect and Samsung Health have no cloud API, so the only way to reach them is from inside an app the user has installed. No app yet? The Connect App is a ready one, built on these SDKs.
Does the user have to keep the app open?
No. Each platform has its own way of waking an app to do work, and the SDK uses it rather than asking the user to open anything. A sync interrupted by a restart or a reboot resumes rather than starting again. What the operating system guarantees about timing is its decision rather than ours, so treat background sync as reliable rather than instant.
Where does the data go?
From the phone to your deployment, over an endpoint that belongs to you. There is no intermediate service holding a copy, which is what makes this different from a hosted SDK writing to a vendor's backend.
Is our app secret on the device?
No, and that is deliberate. Your backend mints a short-lived token scoped to a single user and forwards it to the app over your own authenticated API. The token refreshes itself and is held in the platform's own secure keystore, not in ordinary app storage.
We use Flutter. Is it a second-class integration?
No. Flutter wraps the same native Swift and Kotlin cores, so the sync behaviour is identical code doing the work. What differs is the API you call, not what happens underneath. React Native works the same way, and the package is not on npm yet, so ask us where it stands if that is your stack.
What does the SDK need from the platforms?
The Apple Health SDK needs an Apple Developer account, the HealthKit capability switched on, a reasonably current iOS version, and a physical device, because HealthKit does not run in the simulator. The Health Connect SDK needs a recent Android API level and nothing else. The Samsung Health SDK additionally needs a current version of the Samsung Health app on the device. The docs have exact versions, which move with each release.
How much data does the first sync pull?
As much history as the user's health store holds and your permissions allow, which can be years on a phone somebody has had for a while. After that, anchored queries read only what changed, so the ongoing cost is small.
What happens when Apple or Google changes something?
The fix ships in an SDK release, and you pick it up when you update. That is the part teams underestimate when they build this themselves: it is not the initial integration that costs, it is every OS release afterwards.
Can we see what the SDK actually does?
Yes, it is MIT licensed like the rest of the project. If your security review wants to know what an SDK in your app reads and where it sends it, the answer is code they can read rather than a document from us.