Common questions about
Open Wearables.

Open Wearables is an open-source platform for health intelligence. It connects wearable devices (Garmin, Whoop, Apple Health, Oura, Polar, Suunto, Samsung, Strava, Fitbit, Ultrahuman, Google Health Connect), computes health scores (sleep, recovery, strain, HRV, VO2 max), and includes an AI engine that can reason over that data.

You can build coaching systems, wellness programs, clinical monitoring tools, or AI health assistants on it. Self-hosted. MIT licensed. Zero per-user fees.

Five minutes to your first API call. Clone the repo, run Docker Compose, connect a provider. Railway offers one-click deployment if you want something faster.

Full quickstart guide: openwearables.io/docs/quickstart

Self-hosted. You deploy it on your own infrastructure using Docker Compose. Your users' health data stays on your servers, not ours. A production docker-compose config ships with the repo.

A managed cloud version is not currently available. If you need managed infrastructure with enterprise SLAs, Momentum can deploy and manage it for you. See custom deployment for details.

Yes. The wearable data layer is production-ready. The backend is built on FastAPI with PostgreSQL, Redis, and Celery for background processing. The architecture is stateless and designed for horizontal scaling. A production docker-compose config ships with the repo, and configurable archive and retention policies help manage database growth as usage scales.

Multiple companies run Open Wearables in production. APIs may change before v1.0, so pin your version and test updates before upgrading. For enterprise-scale deployments, Momentum offers infrastructure setup, monitoring, and ongoing support. See custom deployment for details.

Yes. Deploy locally using Docker, run make init to seed sample data (admin account, test users, sample activity data). You can test the full API and developer portal with synthetic data before connecting real wearables.

Yes. All four are supported. The full provider list includes both cloud-based and SDK-based providers:

Cloud-based (via provider APIs): Garmin, Whoop, Oura Ring, Polar, Suunto, Strava, Fitbit, Ultrahuman.

SDK-based (on-device): Apple HealthKit, Samsung Health, Google Health Connect.

The provider list grows with each release. Check openwearables.io/docs for the current list.

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 was introduced in v0.4.1, 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. You deploy Open Wearables. Your database. Your servers. Health data never passes through Momentum's systems unless you explicitly request enterprise support. You can also optionally store raw incoming payloads to S3 for debugging and auditing.

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.

Yes. Open Wearables has zero per-user fees. You pay only for infrastructure. Typical costs:

• Side project or prototype: $5 to $50/month
• Production startup: $200 to $500/month
• 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 computed metric derived from raw wearable data. Instead of showing "your HRV was 42ms last night," a health score tells you "your recovery is 68% today: above your 30-day average, below your peak."

Open Wearables includes open algorithms for sleep quality, recovery, training strain, HRV baseline, VO2 max, stress index, and more. Every algorithm is open source. Read every line, fork them, tune thresholds for your specific user population.

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 reasons: cost, control, and intelligence. Open Wearables eliminates per-user fees entirely. Self-hosting means you own the data pipeline and are not dependent on a vendor's infrastructure, roadmap, or pricing changes. And the health scores and AI engine give you capabilities Terra does not offer. This applies whether you're on Terra, Junction, Thryve, Spike, or any other per-user SaaS aggregator.

If you want the speed of a managed service combined with full data ownership, Momentum's wearables integration team can deploy and manage Open Wearables for you, giving you enterprise-grade support without the per-user fees or vendor lock-in.

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

Open Wearables advantages: Zero per-user fees, 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, 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: Zero per-user fees, 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 per-user fees 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.

Current limitations (check GitHub for the latest):

• Outbound webhooks: in development. Incoming webhook streaming architecture landed in v0.4.1.
• Real-time BLE streaming: not supported. Data comes from provider cloud APIs.
• Some providers still in development: Withings, Coros, Dexcom CGM.
• Health scores: algorithms in development, not fully released.
• HIPAA: architecture supports it, no certification.
• SOC2: not pursued.

These are actively being worked on. The project ships frequent releases. If any of these limitations are blockers for your timeline, talk to Momentum about custom development to accelerate what you need.

Recent highlights (v0.4 and v0.4.1):

• 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, 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.