The wearable data layer you own
One wearable API across the devices your users already own, deployed in a cloud account you control, in a region you choose. No data lands in a vendor tenant.
Built on Open Wearables
What you get
Open Wearables sits between the devices your users wear and the product you are building. It handles the integrations, standardises what comes back, and keeps all of it in infrastructure you own.
One standard schema
Query a user, not a provider. Activity, sleep, heart rate and body measurements come back in one shape, in your own database.
- Raw payloads kept
- Time series
- Webhooks
Connection flows, maintained
Each source has its own authorisation model and its own quirks. All of them are implemented and kept working behind a single endpoint.
- Wearable integrations
- OAuth flows
- Delivery history
Custom health scores
Health scores designed and validated by our science team, computed inside your deployment. Part of Pro, with custom scores built on request.
- Health scores
- Science team
Data off the device
On-device sources have no server-to-server API. Native SDKs for iOS, Android, Flutter and React Native handle background sync.
- HealthKit
- Health Connect
Shared accounts, no wasted quota
One provider account can sit behind several of your user profiles. The payload arrives once and fans out, and a lock stops duplicate calls.
- Fan-out
- Dedup lock
- Quota-safe
MCP server
Point Claude Desktop or Cursor at your own deployment and ask about your data in plain language.
- Claude Desktop
- Cursor
How it works
From clone to production
- 01
Run it
Clone the repository and bring it up with Docker Compose. The API and the developer portal start on your machine, with no third-party services, and the first API call takes five minutes.
Terminal
git clone https://github.com/the-momentum/open-wearables.git cd open-wearables && docker compose up -d curl localhost:8000/api/v1/health - 02
Connect the providers
You register applications in your own name, so the data relationship sits between you and the provider. Approval timelines vary, so this is the step worth starting first. Garmin is the slowest of them: Garmin API integration.
Terminal
curl -X GET "http://localhost:8000/api/v1/oauth/garmin/authorize\ ?user_id=$USER_ID&redirect_uri=https://yourapp.com/connected" \ -H "X-API-Key: $API_KEY" - 03
Query the user, not the provider
One call returns that person's data across every source they have connected. Workouts and sleep sit behind the same pattern, at /events/workouts and /events/sleep. Connect another device tomorrow and the call does not change.
Terminal
curl -X GET "http://localhost:8000/api/v1/users/$USER_ID/timeseries\ ?start_time=2026-09-01T00:00:00Z&end_time=2026-09-04T00:00:00Z\ &types=heart_rate&types=steps" \ -H "X-API-Key: $API_KEY" - 04
Deploy it where it belongs
Production and staging in your own cloud account, in your region, defined as infrastructure code in your repository. Either your team stands it up, or you buy a deployment and we do it.
Self-host it
Docker Compose to start, infrastructure as code for production. MIT license, full source.
We stand it up in your cloud
Same architecture, same account, your credentials. We deploy it, harden it and hand it over to your engineers.
The honest comparison
Hosted SaaS API, in-house build, or self-hosted
Where each one actually wins. If a hosted API fits your situation, use one.
| Hosted SaaS API | Build in-house | Open Wearables, self-hosted | |
|---|---|---|---|
| [01] First API call | Hours | Months | Minutes, with Docker Compose |
| [02] Where the data sits | Their cloud, their regions | Yours | Your cloud account, 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] Raw provider payload | Varies by vendor | Whatever you keep | Your own storage, when you turn it on |
| [05] Provider credentials | Theirs, handled for you | Yours to obtain | Yours, in your own name |
| [06] Certifications | Theirs | Yours to earn | Yours, in your certified environment |
| [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, and each of these teams arrives at that from a different direction.
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 what you build on it stay in your account, whoever runs it. What that means in practice.
Sovereignty
Your regulator, board or own policy keeps health data out of third-party clouds. The deployment meets that by architecture, not by contract.
Residency
The data stays in the region you chose, and you prove it by pointing at an account, not at a trust page.
Control
What you build on top of Open Wearables is yours, on a data model and pipeline in your own account. Nobody can reprice it, change it or be acquired out from under you.
Your own reasons
No regulator forcing it and no security review coming. You want the data in your own account anyway.
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 providers connected and validated on real accounts.
FAQ
Do you have more questions?
Is it really free?
Yes. The core is MIT licensed, with the full source. We charge for Pro, Enterprise, the Deployment and Integration services and custom development.
What does it cost compared with a hosted API?
Running it costs your own cloud bill, which we size with you before you commit and never mark up. Deployment and Integration are one-off services, and health scores and the other licensed modules come with Pro. A hosted API usually prices per monthly active user. Pricing has the figures.
Which devices are supported?
The wearables your users are most likely to own, across cloud OAuth providers and on-device sources. The coverage matrix in the docs lists what each one returns.
Can we use this for a HIPAA workload?
The deployment runs on your infrastructure, so access, encryption, retention and audit logging are yours to control and to evidence. A BAA depends on your cloud provider and your scope.
Do you hold SOC 2 or ISO 27001?
No. The deployment runs inside your certified environment, which is how most teams answer this in their own audit.
Do you keep the raw provider data?
Only if you switch it on. Raw payload capture writes the exact JSON a provider sent to your own log or S3 bucket before any processing. It is off by default and adds no overhead when off.
What happens if we stop working with you?
Nothing stops. The deployment sits in your cloud account, under your credentials, built from infrastructure code in your repository, under an MIT license.
We already use a hosted aggregator. How hard is moving?
Usually a re-integration rather than a data migration. What changes is where new data lands from then on, which is your own database. It starts with an architecture audit.
Who maintains Open Wearables?
Momentum, a healthcare software development company. The project is MIT licensed and developed in the open, with a public roadmap and public issues, so the source does not depend on us continuing to fund it.
Who runs it?
The deployment lives in your cloud account either way. Either your team operates it, or you buy a deployment and we stand it up. Ongoing maintenance comes with Enterprise and is a separate decision. Pricing has the tiers.