Open Wearables

Open Wearables is an MIT-licensed, self-hosted health-data platform built by Momentum. Its core job is to normalize data from multiple wearable ecosystems behind one REST API instead of forcing an application to maintain a separate data model and integration layer for every vendor.¹² The current provider surface includes Garmin, Whoop, Oura, Strava, Polar, Suunto, Apple Health, Samsung Health, Google Health Connect, Google Health API and Ultrahuman, with provider-by-provider coverage documented rather than implied to be uniform.³

The self-hosted architecture is the main differentiator. The documented runtime uses FastAPI, PostgreSQL, Redis and Celery, with a React frontend and Docker Compose for ordinary deployment.⁴⁵ Health data is stored in the operator's own database; cloud-provider data flows from the wearable provider into that deployment rather than through a Momentum-hosted aggregation service.⁶ This removes a separate SaaS data custodian from the ordinary data path, but it also makes the customer responsible for running and securing the stack.

The API surface is broad enough for a real application rather than a demo wrapper. It exposes users, provider connections, daily summaries, timeseries, workouts, sleep sessions and other health events, plus webhooks and developer credentials.⁷ Mobile-device data is handled through SDKs for iOS, Android, Flutter and React Native; the documented production model keeps application secrets on the customer's backend and uses user-scoped tokens in the mobile client.⁸

Provider normalization is useful but cannot erase upstream differences. Garmin, Oura, Whoop, Apple Health and other systems expose different metrics, histories, webhook behavior, permissions and approval processes. Open Wearables documents provider coverage and quirks explicitly, which is preferable to a lowest-common-denominator claim.³ Teams still need to verify that the exact fields and historical depth required by their product are supported for each target provider.

Health scores add a second layer above raw aggregation. Open Wearables currently documents native Sleep Score and Resilience Score methodologies on a 0-100 scale; Sleep Score combines duration, stages, consistency and interruptions, while Resilience Score uses variation in overnight HRV.⁹ These algorithms are open and can be audited or modified. The documentation also states that the scores are intended to surface habits/trends and should not be treated as clinical tools.⁹

That distinction matters because the marketing surface increasingly describes a broader health-intelligence platform. Open algorithms are materially more inspectable than opaque vendor readiness scores, but openness does not by itself establish medical validity for a particular population. A clinical or regulated product should validate score behavior against its own intended use, population and evidence standard rather than treating the repository's formulas as a regulatory or diagnostic endorsement.

The AI layer is implemented through a separate MCP server that calls the Open Wearables REST API using an API key. Current tools allow compatible assistants such as Claude Desktop and Cursor to discover users and query activity, sleep and workout data through natural-language interactions.¹⁰ The architecture documentation still labels the MCP server beta.⁴ This is useful as an AI-facing query surface, but it should not be confused with a validated medical reasoning engine: an LLM connected through MCP remains subject to model hallucination, interpretation and safety limitations.

The public repository is active and substantial. The latest public release located for this review is v0.6.3, released July 15, 2026, following rapid additions around data integrity, observability, women's health, FIT-file ingestion and webhooks.¹¹ The repository also explicitly warns that Open Wearables is an early-stage project, APIs may change before 1.0 and production users should pin versions and follow the changelog.¹² That warning should carry more weight than generic “production-ready” marketing language.

Open issues are useful evidence of engineering maturity because they expose unresolved failure modes rather than hiding them. Current issues include sync-lock recovery, duplicate insert behavior and logging/validation gaps in SDK synchronization.¹³ None of these proves the platform is unreliable overall, but they reinforce the need for pinned releases, observability and regression testing in production.

The software itself is free under the MIT license, including commercial use. The current pricing page states there are no Open Wearables license fees, per-API-call charges or per-user usage tiers for the self-hosted edition.¹⁴ A team can clone the repository, deploy it with Docker Compose and use the API/provider integrations with community support.⁵

“Free” therefore means free software, not zero total cost. The operator pays for its own compute, PostgreSQL, Redis, storage, backups, monitoring, network traffic and engineering time. Higher-frequency wearable data can materially increase infrastructure load: the v0.6.0 release notes, for example, warn that optional second-by-second Garmin workout ingestion increased database memory/storage demand in the maintainers' tests.¹¹ The cost advantage versus per-user SaaS aggregators will depend on scale and internal operations capability.

Provider-side costs and access restrictions are also separate from the Open Wearables license. Some wearable APIs require developer registration, approval, production access reviews or commercial agreements. Provider policies can change independently of the project. Open Wearables already documents a migration path from Fitbit's legacy Web API toward Google's newer health infrastructure as that ecosystem changes.³ Buyers should model those dependencies separately from the $0 Open Wearables license.

Enterprise support is custom-priced. Momentum offers deployment on the customer's infrastructure, SLA-backed support, custom provider integrations, custom health-score work, security questionnaires and compliance-oriented documentation/configuration.¹⁴¹⁵ The current enterprise surface also advertises BAA availability and HIPAA-eligible architecture support.¹⁵ No public enterprise price list is provided, so procurement requires a proposal.

The pricing structure is attractive for teams with many end users because infrastructure cost scales with data volume and redundancy rather than a vendor-imposed active-user fee.¹⁴ It is less obviously advantageous for a small team that does not want to operate databases, queues, provider OAuth credentials and upgrades; a managed per-user API may cost more in license fees but less in internal engineering.

There is no paid requirement to use the MCP server or basic health scores in the open-source stack. They ship with the repository, subject to the maturity limitations documented elsewhere.¹⁰¹² If an application calls a commercial LLM through that MCP workflow, the LLM/provider cost and data-processing terms remain separate from Open Wearables.

Open Wearables is unusually auditable because the source code, release history, issue tracker and score logic are public. The repository has roughly 2,000+ GitHub stars and hundreds of forks in the current public surface, plus hundreds of commits and frequent releases.¹²¹¹ Stars and forks are adoption/interest signals rather than quality scores, but they provide more inspectable project activity than an opaque early-stage SaaS landing page.

Independent exact-product evaluation remains thin. Current Apple App Store release notes for Best Life explicitly added “Support for Open Wearables” on July 27, 2026.¹⁶ This is useful corroboration that the platform is being integrated into a live third-party product, but it does not benchmark Open Wearables reliability, latency, data fidelity or security.

Product Hunt adds limited direct practitioner evidence. The launch page includes a commenter who said they had completed a proof of concept with Open Wearables and found it more economical than alternatives while waiting for fuller Fitbit support.¹⁷ This is useful qualitative evidence because it describes actual use, but it is a tiny self-selected sample and cannot support a numeric product rating.

The strongest first-party trust claim is the data-custody model. The FAQ states that ordinary self-hosted health data is stored in a PostgreSQL database controlled by the deployer and does not pass through Momentum's servers.⁶ This can simplify a compliance data map relative to a hosted aggregator, but “self-hosted” does not automatically mean compliant: the customer still controls cloud region, database security, backups, logs, retention, access control, provider credentials and incident response.

Enterprise language should also be read carefully. Momentum offers HIPAA-eligible architecture, BAA support, GDPR documentation and security review.¹⁵ Those are meaningful enterprise services, but they are not the same as a blanket statement that any default Docker Compose deployment is HIPAA-compliant. Compliance depends on the full deployment, organizational controls, contracts and use case.

Security design is reasonably documented at the application level. The mobile SDK guidance keeps app credentials off-device, uses short-lived user-scoped access tokens and stores credentials in platform secure stores; backend API access uses generated API keys.⁸⁷ This is a sound baseline, but current external evidence does not provide an independent penetration test, SOC 2 report or broad security audit of the exact platform.

The project is candid about maturity in its repository: APIs may change before 1.0.¹² That is important because the main site simultaneously describes the API as production-ready.¹ Both can be true in the sense that teams are running it in production while interfaces still evolve, but production adopters should pin versions and budget for migrations.

The issue tracker is another trust-positive signal precisely because it exposes problems. Current open issues show edge cases around synchronization locks, duplicate data and error logging.¹³ A closed platform may have similar problems without public visibility. Open source improves inspectability; it does not eliminate operational risk.

Health-score evidence is the area that requires the most discipline. The formulas are public and described as science-backed, but the official documentation explicitly says they are not clinical tools.⁹ Current external evidence does not provide an independent validation study establishing clinical accuracy, outcomes or equivalence across device populations. The scores are best treated as customizable wellness/product signals unless a customer independently validates a stronger intended use.

Open Wearables is best for technical teams building health, wellness, sports or quantified-self products that need data from several wearable ecosystems and want control over storage and infrastructure.² The value proposition is strongest when per-user SaaS aggregation fees would become large or when data-residency/compliance architecture makes third-party custody undesirable.

It is particularly compelling for teams that need a normalized backend plus mobile-device ingestion. The combination of REST API, provider OAuth flows and iOS/Android/cross-platform SDKs can cover both cloud wearables and HealthKit/Health Connect-style local stores.⁸³ That reduces the number of custom integration layers a product team must maintain.

AI-health product teams can also benefit from the MCP server as a structured way to expose wearable data to an assistant.¹⁰ The safer pattern is to treat MCP as a query/tool interface and keep medical or high-impact decision logic outside unconstrained LLM output unless the application has its own validation and guardrails.

Organizations that need auditable health scoring may prefer Open Wearables to proprietary readiness/recovery scores because the algorithms can be inspected and changed.⁹ Research and specialized populations can fork thresholds, but doing so transfers methodological responsibility to the organization.

Enterprise customers that want self-hosting without owning every operational detail are a target for Momentum's custom deployment/SLA offering.¹⁵ This may be a useful middle ground between a pure community deployment and a hosted wearable API.

The platform is less suitable for nontechnical individuals who simply want a polished consumer health dashboard. Although self-hosting is possible, Docker, provider credentials, database operations and upgrades create friction that consumer apps hide.⁵

It is also less suitable for teams that want a stable, contractually frozen API with minimal maintenance. The repository remains pre-1.0 and explicitly warns that APIs may change.¹² A managed commercial aggregator may be operationally simpler even if it is more expensive per user.

Clinical teams should not adopt the native scores as diagnostic outputs solely because they are open and transparent. The score documentation itself says they are non-clinical trend tools.⁹ Clinical use requires separate validation, governance and regulatory analysis.