--- title: "Wearable API you self-host in your cloud" description: "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." canonical_url: "https://openwearables.io/platform/wearable-api" --- # The wearable data layer you own Wearable API 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. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=pro) Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo 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](https://openwearables.io/integrations/garmin). 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. [Get started](https://openwearables.io/docs/quickstart) #### 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. [See pricing](https://openwearables.io/pricing) 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 more](https://openwearables.io/for/digital-health) ### Health data platforms Wearable data next to the clinical record you hold, running in your own cloud under your own credentials. [Learn more](https://openwearables.io/for/health-data-platforms) ### Remote patient monitoring Readings from the patient's own device, in the record their clinician reads, in the country the data must stay. [Learn more](https://openwearables.io/for/remote-patient-monitoring) ### Clinical and research builders Endpoints that survive review, for teams heading for DiGA, CE or FDA and for research under ethics approval. [Learn more](https://openwearables.io/for/clinical-research) ### Care providers Remote monitoring for care programmes, clinics, senior care and virtual wards, with a patient app and a care view for your team. [Learn more](https://openwearables.io/for/care-providers) ### Hospitals and telemedicine Wearable data written into your EHR, with a source for every reading that clinicians and auditors can trust. [Learn more](https://openwearables.io/for/hospitals-telemedicine) 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. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=pro) [See pricing](https://openwearables.io/pricing) 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](https://openwearables.io/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](https://openwearables.io/docs/providers/supported) 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](https://openwearables.io/pricing) has the tiers.