Open Wearables in Production: How Heart Monitor Self-Hosts Its Wearable Data

If you are building a health, fitness, or coaching product, wearable data is the part that quietly eats your roadmap. Users arrive with their history spread across Garmin, Polar, Apple Health, Samsung Health, and a handful of others. Each provider has its own OAuth server, its own token rules, and its own way of describing a night of sleep or a workout. Supporting a few of them well is a real project. Supporting them as they change is a standing tax on your team.

There are three ways through this, and most teams have already weighed them by the time they read a page like this. Build every integration yourself and carry the maintenance forever. Rent a closed API that charges per user and routes your users' biometric data through someone else's cloud. Or run an open, self-hosted layer that you own outright.

This is the story of the third option working in production, told through the team that runs it.

Read the full case study: How Heart Monitor gives 90,000 users a complete picture of their health

What Open Wearables Actually Is

Open Wearables is an open-source platform for wearable data integration. You self-host it, point it at the providers you care about, and your application talks to one normalized API instead of a dozen vendor APIs.

It does the unglamorous work that every wearable integration needs:

• Provider connections. Per-provider OAuth and SDK strategies for cloud sources like Garmin, Polar, Oura, Whoop, and Strava, plus on-device APIs through Apple Health, Google Health Connect, and Samsung Health.
• A shared data model. Steps, sleep, workouts, heart rate, energy, and body measurements from every source are normalized, deduplicated, and mapped into one consistent schema.
• One way in. A unified REST and GraphQL API, a native mobile SDK for background sync, and an MCP server so an LLM like Claude or ChatGPT can read structured health context directly.
• Open health scores. Auditable scoring algorithms you can read and tune for your population, rather than a black box you have to trust. The set is live and growing, with more on the roadmap.

The whole thing runs on FastAPI, PostgreSQL, Redis, and Celery, deployed with Docker Compose. It is MIT licensed, so you can read it, fork it, and extend it. The current provider list and roadmap live in the repository at github.com/the-momentum/open-wearables.

The point of the project is ownership. You get the integration layer without renting it, and you keep your users' data on infrastructure you control.

The Architecture

Open Wearables sits at the data ingestion layer, between the device or provider cloud and your own backend. It is not your app database and it is not your UI. It is dedicated wearable-data middleware with one job: take messy, per-provider data and hand your product a clean, unified stream.

Wearable sources come in over two paths. Cloud providers connect through OAuth. On-device sources connect through the mobile SDKs. Inside the platform, data is normalized, deduplicated, and mapped into a unified data model, then exposed through the unified API, the MCP server, and a developer portal. From there it feeds whatever you are building, including any LLM you want to reason over the data.

How Heart Monitor Runs It

Heart Monitor is a health monitoring app with 90,000 monthly active users. Their users kept asking the same thing: why isn't my Garmin data in the app? The team knew what to build. What they did not want was to spend months on provider plumbing, or to hand every user's biometric data to a third-party platform.

They adopted Open Wearables, with Momentum consulting on the integration. The result is a real production deployment at scale, which is the most useful kind of proof that the platform works.

The integration went live in about a week, running on Heart Monitor's own infrastructure. Here is how the data moves once a user connects a device:

1. Connect. The user links a provider, routed through the app's state machine for either the SDK or the cloud OAuth path, with deep-links handled on return to the app.
2. Provision. On first connect, Open Wearables creates a linked user account, and the app stores that id on the user's profile so it happens only once.
3. Sync and ingest. Background workers pull a recent window of data and the app kicks off ingestion, retrying with backoff when a provider is slow to respond.
4. Fetch. The pipeline reads timeseries, sleep summaries, and activity summaries from the Open Wearables API, paginated and fetched in parallel.
5. Deduplicate and store. Each record gets a deterministic id derived from the user, metric, provider, and timestamp, so repeated syncs upsert cleanly into the app's backend instead of piling up duplicates.

A clean-architecture wrapper hides Open Wearables behind domain interfaces, so the underlying data layer can be swapped without touching the app's UI. That is the quiet benefit of an open, self-hosted layer: it is a part of your system, not a vendor you are wedged against.

Inside the Heart Monitor App

Open Wearables runs underneath the part of Heart Monitor the user actually touches: connecting a device and getting their data in. The whole connection flow lives inside the app, so a user never leaves to link a provider or export a file.

A user picks their provider and authorizes it: an OAuth handoff for cloud providers like Garmin and Polar, or the on-device permission prompt for Apple Health, Google Health Connect, and Samsung Health. Control returns to the app, background sync pulls their recent history, and it stays current from then on without any manual upload.

Behind that flow, every provider lands in the same normalized schema in Heart Monitor's backend. The team works against one shape of data instead of a different parser for each provider, which is what makes adding the next device cheap rather than another project.

Why Teams Choose Open and Self-Hosted

Heart Monitor's reasons are the reasons this comes up in most evaluations.

Data ownership. Every record, including OAuth tokens and synced activity, sleep, and heart-rate data, stays in your own database on your own infrastructure. Nothing routes through a third-party cloud. For a product handling personal health data, that keeps data residency, HIPAA, and GDPR handling under your own control instead of a vendor's terms.

No per-user lock-in. A self-hosted layer does not bill per connected user, so the cost of supporting wearables does not scale with the size of your user base the way a closed per-user API does. You run your own infrastructure and own the economics.

Open algorithms. The health scores are readable and tunable. You can audit how a score is computed and adjust it for your population rather than accepting whatever a closed platform decides.

Integrate once, benefit as it grows. New providers and features the community adds become available to everyone running the platform. Your single integration keeps getting more capable without more work from you.

Why It Matters That Momentum Built It

Open Wearables is built and maintained by Momentum, a healthcare software company. That matters for two reasons.

The code is production-grade because it is the foundation Momentum builds real healthcare products on, with a HIPAA-ready architecture, deduplication, background sync, and observability built in rather than bolted on. Heart Monitor running it at 90,000 users is evidence of that.

And you are not on your own with it. You can clone the repo and deploy it today for free. If you would rather have it stood up properly, integrated into an existing backend, or extended with custom scoring for your domain, that is wearables development work Momentum does directly, the same work that helped Heart Monitor get to production. The open-source project and the option of expert help are the same story from two angles.

Get Started With Open Wearables

If you are a developer, the fastest path is the code. Clone the repository, run docker compose up, and make your first API call. Everything is at github.com/the-momentum/open-wearables and the docs at openwearables.io.

If you are weighing wearable integration for a product and want it done right the first time, talk to the team that built the platform and ships health software on top of it. Momentum can scope your integration, deploy Open Wearables on your infrastructure, and connect the providers your users actually carry.

Book a wearables integration call with Momentum