Common questions about
Open Wearables.

Open Wearables is an open-source health intelligence platform that connects wearable devices, computes health scores from their data, and lets an AI reason over the result. It integrates all major wearable providers through one unified REST API, normalizing and deduplicating every reading into a single schema, so your application uses the same endpoints regardless of which device a user wears. Two documented scores ship with the platform: Sleep Score, a nightly 0-100 value built from duration, stages, consistency, and interruptions, and Resilience Score, a weekly 0-100 measure of autonomic nervous system stability derived from heart rate variability. An MCP server exposes scores, trends, and baselines to any LLM. Teams build AI coaching systems, corporate wellness programs, clinical monitoring tools, longevity platforms, and personal health dashboards on it. The platform is self-hosted and MIT licensed, so health data stays on your own infrastructure.

Five minutes to your first API call. Clone the repository, run docker compose up -d, and the full stack starts locally: the FastAPI backend, PostgreSQL, Redis, and Celery workers. A single request to localhost:8000 confirms the API is live, and make seed populates synthetic users, workouts, sleep records, and time series so you can exercise every endpoint before touching a real device. Railway offers one-click deployment if you would rather skip local setup entirely. The part that takes longer is provider credentials: each wearable platform runs its own developer program, and approval ranges from immediate to several weeks depending on the provider. That step is identical whether you use Open Wearables or build the integrations yourself, and it is a one-time cost per provider. Everything else, including the developer portal, health score computation, and webhook handling, is running locally the moment the containers start.

Full walkthrough: openwearables.io/docs/quickstart

Self-hosted. You deploy Open Wearables on your own infrastructure with Docker Compose, and your users' health data stays on your servers rather than passing through a vendor. That is the core architectural difference from managed aggregators: there is no third party holding your users' health records, and no data processing agreement needed with us because we never receive the data. A production Docker Compose configuration ships with the repository, and the stack runs on any cloud or on-premises environment that can run containers. Deployment targets include AWS, GCP, Azure, and bare metal. Because the whole stack is containerized, moving between those environments is a configuration change rather than a rewrite. A managed cloud version is not currently available. If you need managed infrastructure with enterprise SLAs, compliance coverage, and a named engineering team, Momentum can deploy and operate it for you. See custom deployment for what that includes.

Yes. The wearable data layer is production-ready and runs in production today. The backend is FastAPI on Python 3.13, with PostgreSQL 18 as the primary database, Redis 8 as task broker and cache, and Celery for background processing, plus Celery Beat for scheduled jobs and Flower for queue monitoring. The architecture is stateless, so it scales horizontally behind a load balancer, and a production Docker Compose configuration ships with the repository. Configurable archive and retention policies keep database growth manageable as data volume rises, and raw provider payloads can optionally be stored to S3 for debugging and audit trails. APIs may still change before the first stable release, so pin your deployment and test upgrades before rolling them forward. For enterprise-scale deployments, Momentum offers infrastructure setup, monitoring, and ongoing support. See custom deployment for details.

Yes. Deploy locally with Docker Compose and run make seed to generate synthetic data: users, workouts, sleep records, and time series metrics. The seed generator is reproducible, embedding a random seed in the generated user name so you can recreate an identical dataset when reproducing a bug. This lets you exercise the full REST API, the developer portal, health score computation, and webhook delivery before applying for a single provider credential. Because provider approval can take weeks, this matters for planning: your team can build and test the entire integration against realistic data while credential applications are still pending, then swap in live providers without changing application code. Synthetic records use the same unified schema as real device data, so nothing about your integration changes when you switch over, and the same seeded dataset can be regenerated on any machine for consistent test runs.

Yes, all four are supported, alongside every other major wearable platform. Providers fall into two integration categories. Cloud-based providers connect through OAuth and their own APIs: Garmin, Whoop, Oura Ring, Polar, Suunto, Strava, Fitbit, Ultrahuman, and Google Health. SDK-based providers read data on the device itself and sync it up: Apple HealthKit, Samsung Health, and Google Health Connect, each covered by native mobile SDKs for iOS, Android, Flutter, and React Native. The practical difference matters for architecture. Cloud providers require you to register with each developer program and obtain credentials, then Open Wearables handles the OAuth flow, token refresh, and webhook ingestion. SDK providers require shipping a mobile SDK in your app, because Apple and Samsung only expose that data on-device. Both paths normalize into the same unified schema, so your application code never branches on which provider a reading came from.

Current provider list and per-provider data coverage: coverage matrix

Four SDKs covering all major platforms:

• iOS SDK (Swift) for Apple HealthKit
• Android SDK (Kotlin) for Samsung Health & Google Health Connect
• Flutter SDK (Dart) cross-platform wrapper
• React Native SDK (TypeScript) cross-platform wrapper

Choose the one that matches your stack. All handle Apple Health and Google Health Connect through a single integration.

Apple Health uses HealthKit, which requires on-device SDK access (not a cloud API like Garmin or Whoop). Open Wearables wraps the Apple Health API through the Flutter, React Native, or native iOS SDK so you don't need to build HealthKit integration yourself.

The SDK manages OAuth-free authorization, background sync, incremental updates, and sleep stage timestamps. Users authorize once in your app, and data flows automatically.

Yes. Open Wearables connects to Oura's cloud API directly via OAuth. Data comes from Oura's API with full granularity, including sleep stages. Apple Health is a separate integration that captures whatever data Apple stores locally on the device.

Dexcom CGM integration is on the roadmap. No committed release date. Check the GitHub issues for the current status and timeline updates.

Yes. The codebase includes a contribution guide for adding new providers. Oura Ring, Fitbit, and Ultrahuman were all added this way by community contributors.

For proprietary devices or urgent timelines, Momentum offers custom integration services.

No. Open Wearables is read-only. It pulls data from wearable providers but does not write back to them. If your application needs to push training plans or goals to a device, you would integrate with that provider's API directly alongside Open Wearables.

Open Wearables includes a native Strava API integration. It handles OAuth, activity sync, and normalizes Strava data into the same unified schema as every other provider. You get running, cycling, and other activity data without building the Strava API layer yourself. Full setup guide: Strava API integration.

Yes. Once Strava activity data flows into Open Wearables, it is normalized and available to the MCP server. Your AI models can reason over training load, recovery patterns, and activity trends alongside data from other providers like Garmin or Whoop. See the Strava integration page.

Open Wearables supports Google Health Connect via the Android SDK. The SDK reads data from Health Connect on-device and syncs it to your backend. It covers steps, heart rate, sleep, and workouts. Details: Google Health Connect integration.

Yes. Google Fit API is deprecated and replaced by Google Health Connect. Open Wearables supports Health Connect via the Android SDK, so you get the same fitness and health data through the current API. See the Google Health Connect integration page.

Samsung Health data is accessible through Google Health Connect on Android. The Open Wearables Android SDK reads from Health Connect, so Samsung Health data is included automatically for users who have it enabled. See the Samsung Health API integration page.

Yes, via Google Health Connect. Samsung Health syncs data to Health Connect on Android, and the Open Wearables SDK reads it from there. No separate Samsung Health API integration is needed. Details: Samsung Health integration.

Yes. Open Wearables includes a Polar API integration for activity, sleep, and training load data. It handles OAuth and data normalization so you do not need to build the Polar API layer yourself. See the Polar integration page.

Yes. Polar training sessions, nightly recharge, and heart rate data are pulled via the Polar API and normalized into the Open Wearables schema alongside data from other providers. Full details: Polar API integration.

Yes. Open Wearables supports the Suunto API for workout and biometric data. The integration handles authentication and data normalization, so Suunto data lands in the same unified schema as every other provider. Setup guide: Suunto API integration.

Yes. Suunto activity sessions, heart rate, and GPS data are supported via the Suunto API integration. See the Suunto integration page.

• Backend: FastAPI (Python)
• Database: PostgreSQL + Redis
• Task processing: Celery
• Frontend (developer portal): React + TypeScript + TanStack Router, built with Vite
• Deployment: Docker Compose

Full source: github.com/the-momentum/open-wearables

Yes. The MCP (Model Context Protocol) server allows Claude, ChatGPT, and other LLMs to query a user's health data. Instead of passing raw numbers to an LLM, the MCP server provides pre-computed health scores, context (trends, anomalies, baselines), and a reasoning framework for health interpretation.

You can also query the Open Wearables REST API directly from your own AI pipeline and feed structured health data into whatever system you have.

Open Wearables does not natively output FHIR resources. It provides a unified REST API with its own data model. Mapping Open Wearables data to FHIR Observations is a well-scoped transform, not a ground-up integration. Momentum has built FHIR integrations for multiple clients and maintains a separate open-source FHIR MCP Server.

If your architecture requires FHIR or Open mHealth IEEE 1752 output, that can be built as a mapping layer on top of the Open Wearables API.

An incoming webhook streaming architecture is in place, laying the groundwork for real-time data processing pipelines. Outbound webhooks (pushing events to your backend when new data arrives) are in active development.

In the meantime, you can poll the Open Wearables API or use the Celery task queue for scheduled processing.

No. Open Wearables fetches data from provider cloud APIs (webhook or polling). It does not connect to devices via Bluetooth directly. This is the same constraint every third-party aggregator faces, including Terra. The near-instant data you see in Garmin's or Whoop's own apps comes from firmware-level access that third parties do not have.

For most health app use cases (post-workout analysis, daily recovery scores, sleep tracking), cloud-synced data with minimal delay is sufficient. If you need raw BLE signals during a live session, you would integrate with the device SDK directly for that specific flow.

Open Wearables normalizes all wearable data into a unified model. Same API call whether the data came from Garmin, Whoop, or Apple Health. Units, timestamps, and data types are standardized. You do not need provider-specific handling in your application code.

Data types include: workouts, sleep summaries (with granular sleep stages for Garmin and Oura), daily activity, body measurements, heart rate series, HRV, and more. Full data model: openwearables.io/docs.

When multiple providers send overlapping data (e.g., Apple Health and Garmin both recording steps for the same time window), Open Wearables uses configurable priority rules to resolve conflicts. You set priority at two levels: device type (smartwatch over phone) and provider (Garmin over Apple Health, or vice versa).

For cloud-based providers (Garmin, Oura, Whoop, Polar, Suunto, Strava, Fitbit, Ultrahuman), web-based OAuth works. For Apple Health, Samsung Health, and Google Health Connect, you need a mobile app because those platforms require on-device SDK access.

The iOS, Android, Flutter, and React Native SDKs handle this. If your app is web-only and you need Apple Health data, you would need a companion mobile app.

On your infrastructure, in a PostgreSQL database you run and control. Open Wearables is self-hosted, so health data flows from the provider directly into your deployment and never passes through Momentum's servers. This has concrete consequences for compliance work: there is no third-party processor to add to your data map, no vendor breach exposing your users, and no business associate agreement needed with us because we never handle the data. Raw incoming provider payloads can optionally be written to S3 for debugging and audit trails, which is useful when reconstructing what a provider actually sent. The architecture supports HIPAA-eligible deployments: encryption at rest and in transit, audit logging, role-based access controls, and configurable retention and archival policies. Where the data physically lives is determined entirely by which region you deploy into, which is what makes data residency requirements straightforward to satisfy.

The architecture is HIPAA-ready: encryption at rest and in transit, audit logging, role-based access controls, configurable data retention and archival. But HIPAA compliance is not just software. It requires proper infrastructure configuration, organizational policies, and procedures.

Open Wearables is not HIPAA-certified as a product. Self-hosting means compliance is your responsibility, and Open Wearables gives you the building blocks to achieve it. Momentum offers HIPAA implementation support and BAAs for enterprises. See enterprise support for details.

Self-hosted architecture means you control where data lives. Deploy on Canadian infrastructure, set your own retention policies, and manage consent according to PIPEDA requirements. Open Wearables does not introduce third-party data processors or cross-border data flows.

SOC2 certification is not currently pursued for Open Wearables as an open-source project. SOC2 applies to the organization operating the service, not the software itself. If you self-host Open Wearables, SOC2 compliance depends on your infrastructure and operational controls. If you engage Momentum for a managed deployment, that conversation is part of the enterprise agreement.

Security issues are handled through GitHub's responsible disclosure process. Dependabot is configured for automated dependency updates. The Open Wearables codebase is actively maintained by Momentum's engineering team plus community contributors. Critical patches are prioritized. Because the code is open, you can also audit it yourself and apply fixes independently.

Yes. Self-hosted means data stays on your infrastructure. You control the data, the storage location, and the retention policies. Open Wearables does not introduce third-party data processors. With SaaS aggregators, user health data flows through their servers, which adds a data processor to your GDPR chain.

Open Wearables is MIT licensed, so you pay only for infrastructure. Typical costs:

• Side project or prototype: minimal, a single small instance is enough
• Production startup: scales with data volume and redundancy needs
• Enterprise scale: depends on volume and redundancy

At 10,000 users, your cost per user is fractions of a cent for infrastructure, compared to $0.50 to $2.00/user/month with SaaS aggregators.

All commercial wearable aggregators (Terra API, Rook, Sahha, Thryve, Junction, Spike) follow a per-user SaaS pricing model. Open Wearables eliminates that cost entirely.

Momentum built wearable integrations for client after client. The same providers, the same normalization logic, the same compliance requirements. Making it open source solved that problem for everyone.

Momentum's business model: paid services on top. Enterprise deployment, custom scoring algorithms, AI coaching implementation, compliance support. The platform is free. The expertise is not.

Yes. The Docker Compose setup is designed for small teams. A production docker-compose config ships with the repo. If your team can run a PostgreSQL database and deploy Docker containers, you can run Open Wearables. Community support via Discord is available for questions.

Yes. Open Wearables is MIT-licensed. You can deploy it as part of your own platform, offer wearable data features to your clients, and build a product layer on top. No licensing restrictions.

A health score is a single interpretable number computed from raw wearable signals, designed so a person or an AI can act on it without reading the underlying time series. Open Wearables ships two documented scores. Sleep Score is a nightly 0-100 value built from four pillars: sleep duration, sleep stages, consistency of sleep timing, and interruptions during the night. Resilience Score is a weekly 0-100 value measuring autonomic nervous system stability through the coefficient of variation of heart rate variability, which captures how steady a person's recovery capacity is over time rather than on any single day. Both use a scale where higher is better, and both were developed by a team of scientists and ML engineers with every threshold documented. Because the algorithms are open source, you can audit the logic and tune thresholds for your own population.

Full methodology: health scores documentation

Yes. The MCP server gives any LLM (Claude, GPT, etc.) structured access to a user's health data with context. Instead of dumping raw numbers into a prompt, it provides scored health metrics, trend analysis, and anomaly detection.

The result: an AI assistant that can reason "Your recovery is below baseline and your strain was high yesterday. Consider a lighter session today."

Open Wearables stores all user data in your PostgreSQL database with a unified schema. You can query across users with standard SQL: average recovery by cohort, sleep quality trends by demographics, strain distribution across a team. The data model is designed for both per-user and aggregate queries.

Yes. The platform is MIT licensed. Build proprietary scoring, prediction models, or recommendation engines on top of Open Wearables' normalized data. These remain your intellectual property. The open algorithms are a starting point. Your domain expertise makes them valuable for your specific use case.

The MCP server works with any LLM that supports the Model Context Protocol: Claude, ChatGPT, and others. You can also use local models via Ollama. The system is model-agnostic by design.

Terra and Rook do not offer an AI reasoning layer. They provide data aggregation and, in some cases, pre-computed scores (black box). Open Wearables provides open algorithms you can audit and tune, plus an MCP server that lets any LLM reason over health data with full context. No other wearable aggregator offers this.

Three differences matter in practice: cost structure, algorithm transparency, and data custody. Terra prices per connected user and per API call, so the bill grows with your user base, and health scoring is a paid add-on. With Open Wearables the platform is MIT licensed and self-hosted, so your cost tracks the infrastructure you run rather than how many people use your product. Terra's scoring logic is proprietary, meaning you cannot audit how a number was derived or adjust thresholds for your population; Open Wearables publishes its algorithms, so both are possible. Terra stores your users' health data on its servers, while a self-hosted deployment keeps that data inside your own perimeter. The tradeoff is real: you take on running infrastructure that Terra otherwise manages for you. If your team has no appetite for that, a managed service remains a reasonable choice.

Detailed comparison: Open Wearables vs Terra API

Terra/Rook advantages: Managed service, no infrastructure to maintain, faster initial setup, established enterprise support.

Open Wearables advantages: full source code access, self-hosted data sovereignty, open health score algorithms, AI reasoning layer (MCP server), no vendor lock-in (MIT license), growing community with frequent releases.

The same comparison applies to other commercial aggregators like Thryve, Junction, and Spike.

You do not have to choose between speed and ownership. With Momentum's custom deployment, you can launch on Open Wearables from day one with a managed setup: Momentum handles infrastructure, provider onboarding, and production hardening so your team focuses on your product.

If you've already started with a SaaS aggregator (Terra, Rook, Thryve, Junction, Spike, or similar), you can run Open Wearables in parallel and migrate when ready. The migration requires users to re-authorize cloud-based providers (OAuth tokens belong to the original app). Apple Health is SDK-based, so it does not require re-authorization.

The wearable data layer is production-stable with frequent releases. The version number reflects the breadth of the platform (4 layers and many features planned), not the stability of what exists today.

Risk mitigation: the code is MIT-licensed, so you can fork and maintain it independently. Momentum (130+ engineers, 10+ years in healthtech) actively maintains the project and offers enterprise support contracts with SLAs. You are not depending on a volunteer community.

MIT license means you own the code. You can continue running, maintaining, and extending your deployment indefinitely. This is the fundamental advantage over SaaS: if a commercial aggregator shuts down, changes pricing, or gets acquired, you rebuild. With Open Wearables, you still have a working codebase.

Sahha focuses on behavioral sensing via a managed black-box API. Open Wearables is self-hosted and MIT-licensed: you run the full pipeline on your own infrastructure, your data never leaves your servers, and the health scoring algorithms are open source. Full comparison: Open Wearables vs Sahha.

Sahha advantages: Managed service, no infrastructure to run, faster initial setup.

Open Wearables advantages: self-hosted data sovereignty, open health score algorithms, native MCP server for AI reasoning, no vendor lock-in. See Sahha Health vs Open Wearables for the full breakdown.

Yes. Open Wearables is a fully open-source Spike API alternative. It supports the same device providers, self-hosts on your infrastructure, and costs nothing per user. See Open Wearables vs Spike.

Both aggregate wearable data from multiple providers. Spike is a closed SaaS product with per-user pricing. Open Wearables is self-hosted, MIT-licensed, and includes a built-in health scoring and AI layer. Full breakdown: Spike Health API vs Open Wearables.

Junction Health is a managed API with SaaS pricing. Open Wearables is a free, self-hosted alternative: the same multi-provider wearable data access without usage-based pricing or vendor dependency. See Open Wearables vs Junction.

Junction operates as a managed API, so your data flows through their infrastructure and costs scale with your user base. Open Wearables is open source and self-hosted: your data never leaves your infrastructure and costs stay flat regardless of user count. Detailed comparison: Junction Health API vs Open Wearables.

Yes. OAuth tokens belong to the application that requested them. Switching from Terra, Junction, Thryve, Spike, or any other SaaS aggregator to Open Wearables means each user re-authorizes through the Open Wearables OAuth flow. This is a one-time step per user, but it needs to be factored into your migration plan and communicated to end users.

Apple Health is SDK-based (not OAuth), so re-authorization works differently and may be smoother depending on your implementation.

Yes. Deploy Open Wearables alongside your existing integration. New users connect through Open Wearables, existing users stay on the current provider until you migrate them. This reduces risk and lets you validate Open Wearables in production before a full cutover.

Momentum has handled migrations from Terra and other aggregators for multiple clients and can manage the transition to minimize user disruption.

Yes, if you want: additional providers (Oura, Whoop, Polar, Samsung, Strava, Fitbit, Ultrahuman) without building each integration from scratch; a unified data model and deduplication across all providers; health scores and AI features; or a migration path away from managing multiple direct integrations.

Several, worth knowing before you commit. Outbound webhooks are still in development, so if your architecture depends on Open Wearables pushing events to your systems, that is not ready yet; incoming webhook streaming from providers is in place. Real-time BLE streaming directly from a device is not supported, because data arrives through provider APIs and mobile SDKs rather than a live sensor connection, which rules out use cases needing sub-minute latency during a workout. The API surface may still change before the first stable release, so pin your version and test upgrades rather than tracking the latest build in production. Two health scores ship today, sleep and resilience, so anything beyond those you build yourself on the normalized data. Provider credential approval remains outside our control and can take weeks. Check the GitHub releases for current status.

Recent highlights:

• Oura Ring integration (community contributed)
• React Native SDK
• Fitbit integration (community contributed)
• Ultrahuman integration (community contributed)
• Granular sleep stage tracking for Garmin and Oura
• Raw payload storage and replay for debugging
• Incoming webhook stream architecture
• Production docker-compose config

Full changelog: GitHub releases.

Open a GitHub issue or join the Discord. The roadmap is driven by community demand and design partner needs. Community contributions are actively encouraged: Fitbit, Ultrahuman, and Oura were all contributed by external developers.

Expanding into broader health data: CGM devices, nutrition data, laboratory results, EHR/EMR integration, and blood test data. The goal is an open-source infrastructure layer for health intelligence, not just wearable aggregation.

Self-deploy (free): Clone the repo, follow the docs, deploy with Docker Compose or Railway. Community support through Discord. No SLA, no guaranteed response times. You own and operate everything.

Custom deployment with Momentum: Momentum deploys Open Wearables on your cloud (AWS, GCP, or Azure) and handles everything production requires. Infrastructure setup, security hardening, HIPAA-eligible architecture, and custom integrations for providers not yet supported.

On the support side: SLA-backed response times, a dedicated Slack channel with named engineers, priority patches and escalation paths. If you need a BAA for HIPAA compliance, we sign it directly.

Most teams start self-hosted and bring in Momentum when they need production guarantees. See custom deployment and enterprise support for the full scope.

Momentum is a healthtech software studio. 130+ engineers, 220+ health projects since 2013. We built Open Wearables because the same wearable integration problem appeared in every health tech project we worked on. We solved it once and open-sourced it.

What we bring to custom deployments: mobile development across iOS, Android, Flutter, and React Native. Cloud infrastructure on AWS, GCP, or Azure. Security hardening and compliance configuration for HIPAA and GDPR. Custom provider integrations for devices we don't support yet. AI coaching layers and health scoring algorithms tuned to your population.

The platform is free and MIT licensed. Momentum sells the engineering expertise to deploy it at production scale, keep it running, and extend it for your use case.

Learn more at themomentum.ai.

Discord is the fastest channel for self-hosted users. The core team and community are active there.

Teams on enterprise support get a dedicated Slack channel with named engineers, SLA-backed response times, and proactive release management.

For bugs or feature requests, open an issue on GitHub. For enterprise discussions, schedule a call.

The project has an active and growing community on GitHub and Discord. Community-built provider integrations (Fitbit, Ultrahuman, Oura, Whoop) demonstrate real contributor engagement. The project ships frequent releases with contributions from both Momentum engineers and external developers.

Check the GitHub repo for current star count, contributor count, and activity.