the-momentum/open-wearables: Self-Hosted Wearable Data Unification

If you've ever tried building a health application that pulls data from multiple wearable devices, you know the integration maze: OAuth flows for Garmin, disparate APIs for Whoop, custom parsers for Apple HealthKit, and endless maintenance as providers change their schemas. Each new wearable provider means weeks of development time, diverting resources from your actual product. The the-momentum/open-wearables project addresses this fragmentation directly—a self-hosted platform that normalizes wearable health data into a single, AI-ready API. With 2,153 GitHub stars and active development as of July 2026, it's gaining traction among developers who need data sovereignty without sacrificing integration speed.

What is the-momentum/open-wearables?

the-momentum/open-wearables is an open-source, self-hosted platform built by Momentum that unifies wearable device data through a unified REST API. Licensed under MIT and primarily written in Python^{↗ Bright Coding Blog}, it sits at the intersection of health data infrastructure, developer tooling, and privacy-preserving self-hosting. The project emerged from the broader Python AI Kit ecosystem, reflecting a design philosophy that prioritizes local deployment and minimal external dependencies.

The platform serves two distinct audiences: developers building health applications who need normalized data across multiple providers, and privacy-conscious individuals who want to own their health data without routing it through third-party cloud services. This dual positioning is deliberate—the same infrastructure that powers a fitness coaching app's backend can run on a personal server for individual health tracking.

What distinguishes it from typical SaaS health data platforms is the self-hosting requirement. Each deployment serves a single organization; there's no multi-tenancy complexity, no per-seat pricing, and no vendor lock-in. The trade-off is operational responsibility—you manage the infrastructure, but you retain complete data control. This architecture resonates particularly in healthcare-adjacent applications where data residency requirements are non-negotiable.

Key Features

Unified API with Normalized Data Models

The core value proposition: access heart rate, sleep, activity, steps, and workout data through consistent REST endpoints regardless of whether the source is a Garmin watch, Oura ring, or Apple HealthKit. The platform handles provider-specific OAuth flows, data mapping, and unit normalization internally.

Developer Portal Dashboard

A React-based web interface for managing integrations without writing code. Features include general statistics (user counts, data points), user management with connected data source visualization, and API key generation in a dedicated Credentials tab.

Provider Coverage

Cloud-based integrations: Garmin, Oura, Whoop, Suunto, Polar, Ultrahuman, Strava, Fitbit. SDK-based integrations for on-device stores: Apple HealthKit, Samsung Health, Google Health Connect. OAuth flows are currently implemented for Garmin, Polar, and Suunto, with workout data sync active for these three providers.

Mobile Sync SDKs

Native SDKs enable push-based sync from device health stores: iOS SDK (Swift), Android SDK (Kotlin), Flutter SDK (Dart), and React Native SDK (TypeScript).

Background Processing

Celery task queues handle data syncing and processing asynchronously, with Redis as the broker and PostgreSQL^{↗ Bright Coding Blog} for persistent storage.

Upcoming Capabilities

Health Insights & Automations (natural language condition definitions, webhook notifications, human-in-the-loop feedback), AI Health Assistant (embeddable chat widget with swappable models), and Connection/Assistant widgets for drop-in integration.

Use Cases

Fitness Coaching Platforms

Running coaches or personal training apps can onboard users by generating connection links—shared via WhatsApp or email—without building custom OAuth flows. The normalized data enables personalized training recommendations based on recovery metrics, sleep quality, and workout history. Non-technical product owners can validate concepts by sharing these links directly, bypassing app development entirely for pilot testing.

Healthcare Data Aggregation

Remote patient monitoring platforms can aggregate standardized health data from patient-owned devices. The self-hosted model satisfies HIPAA-adjacent data residency requirements that cloud-native alternatives struggle with. Webhook-configurable automations (when shipped) will enable real-time alerts for anomalous metrics.

Research Data Collection

Academic studies requiring multi-device health data benefit from the normalized schema. Rather than building custom pipelines for each wearable used by study participants, researchers deploy open-wearables once and receive consistent data formats regardless of device heterogeneity.

Personal Health Infrastructure

Privacy-focused individuals self-host to consolidate their own wearable data, query it via API, and (pending release) interact with an AI Health Assistant without sending health data to external AI services. This use case explicitly motivated the project's design—complete data control on owned infrastructure.

Wellness Application Backend

Corporate wellness platforms or consumer health apps reduce time-to-market by eliminating per-provider integration work. The embeddable widgets (upcoming) further reduce frontend development^{↗ Bright Coding Blog} for connection flows and health data exploration.

Installation & Setup

The project provides Docker Compose as the recommended path, with local development setup documented separately.

1. Clone the repository:

git clone https://github.com/the-momentum/open-wearables.git
cd open-wearables

2. Configure environment variables:

Backend configuration:

cp ./backend/config/.env.example ./backend/config/.env

Frontend configuration:

cp ./frontend/.env.example ./frontend/.env

Edit these files to set required values. The admin account credentials default to admin@admin.com / your-secure-password via ADMIN_EMAIL and ADMIN_PASSWORD—change these before production deployment.

3. Start with Docker Compose:

docker compose up -d

This brings up the full stack^{↗ Bright Coding Blog}: FastAPI backend, React frontend, PostgreSQL, Redis, and Celery workers. No external authentication services or third-party dependencies are required for core functionality.

4. Access the developer portal:

Navigate to http://localhost:3000 and log in with the admin credentials configured above. Create API keys in the Credentials tab for programmatic access.

5. (Optional) Seed sample data:

make seed

This creates test users with sample activity data for exploration without connecting real devices.

6. Explore API documentation:

Open http://localhost:8000/docs for interactive Swagger UI documentation generated from FastAPI's OpenAPI schema.

For non-Docker local development, refer to the official documentation.

Real Code Examples

The README does not contain extensive inline code samples for API usage. The following examples reflect the documented setup commands and architectural patterns; developers should consult the live Swagger UI at /docs for complete endpoint specifications.

Docker Compose startup (reproduced from README):

# Clone and enter the project
git clone https://github.com/the-momentum/open-wearables.git
cd open-wearables

# Copy environment templates
cp ./backend/config/.env.example ./backend/config/.env
cp ./frontend/.env.example ./frontend/.env

# Launch all services
docker compose up -d

This single command orchestrates the multi-service deployment. The -d flag detaches containers; omit it to view logs directly. Services communicate internally via Docker networking—no manual port configuration is needed beyond the exposed 3000 (frontend) and 8000 (backend/API) ports.

Seeding test data:

make seed

The Makefile target populates PostgreSQL with synthetic users and activity records. This is particularly useful for frontend development or API exploration before obtaining OAuth credentials from wearable providers. The seed data follows the same normalized schema as production data, ensuring representative query behavior.

Environment configuration pattern:

# Backend: API keys, database URLs, Celery broker settings
cp ./backend/config/.env.example ./backend/config/.env
# Edit: DATABASE_URL, REDIS_URL, SECRET_KEY, ADMIN_EMAIL, ADMIN_PASSWORD

# Frontend: API base URL, feature flags
cp ./frontend/.env.example ./frontend/.env
# Edit: VITE_API_URL (typically http://localhost:8000)

The split configuration reflects the decoupled architecture: backend handles data persistence, authentication, and provider integrations; frontend serves the developer portal and (eventually) widget embeds. Both use Vite-style environment variable conventions.

The current documentation emphasizes setup over extensive API examples. For integration code—creating users, generating connection links, querying normalized data—developers should reference the interactive Swagger documentation and the official docs rather than relying on static examples that may lag behind the pre-1.0 API evolution.

Advanced Usage & Best Practices

Version Pinning for Production

The README explicitly warns that APIs may change before version 1.0. Pin to specific Git tags or commit SHAs in production deployments, and monitor the changelog for breaking changes. The July 2026 last commit indicates active development—stability commitments should not be assumed.

Provider OAuth Management

Each wearable provider requires independent OAuth application registration. Store provider-specific client credentials in the backend .env file; rotate these regularly. The platform handles token refresh internally, but initial setup requires navigating each provider's developer console.

Data Retention Policies

With self-hosting comes responsibility for data lifecycle management. Implement PostgreSQL partitioning or archival strategies for high-frequency data (e.g., second-by-second heart rate) to prevent unbounded storage growth. The normalized schema facilitates this but does not automate it.

SDK Integration Order

For mobile applications requiring on-device sync, evaluate the Flutter or React Native SDKs before building native integrations—the cross-platform wrappers reduce maintenance burden if your stack supports them. The native iOS/Android SDKs offer maximum control for performance-critical applications.

Security Hardening

Change default admin credentials before any external exposure. The self-contained authentication avoids external dependencies but places burden on deployment security. Consider reverse proxying with TLS termination and IP restrictions for the developer portal.

Comparison with Alternatives

open-wearables occupies a specific niche: developers who require data sovereignty and are willing to trade managed-service convenience for infrastructure control. It is not yet competitive on provider breadth with established SaaS alternatives, but the gap is narrowing—11 providers with active SDK ecosystem development versus Terra's broader but proprietary offering. The planned AI features (swappable models, self-hosted inference compatibility) could differentiate further for privacy-sensitive applications.

FAQ

Is this production-ready?

Pre-1.0 with actively evolving APIs. Pin versions and test thoroughly before production deployment.

What wearable providers work today?

OAuth and workout sync: Garmin, Polar, Suunto. Connection support: Oura, Whoop, Ultrahuman, Strava, Fitbit. SDK sync: Apple HealthKit, Samsung Health, Google Health Connect.

Does it support multi-tenancy?

No. Single-organization deployment by design. Run separate instances for distinct organizations.

What are the hardware requirements?

Not explicitly documented. Docker Compose implies modest requirements; scale PostgreSQL and Celery workers based on user and sync frequency.

Can I use this without connecting real devices?

Yes. make seed generates synthetic data for development and testing.

Is there a managed/cloud version?

No. Self-hosted only, aligning with the project's data sovereignty goals.

What license applies?

MIT License—free for commercial and open-source use without restriction.

Conclusion

the-momentum/open-wearables offers a pragmatic path for developers and organizations that need unified wearable data without surrendering control to third-party platforms. Its self-hosted architecture, growing provider coverage, and emerging AI capabilities position it as infrastructure for privacy-sensitive health applications—particularly in regulated environments or for individuals exercising data autonomy.

The project is best suited for: teams with DevOps^{↗ Bright Coding Blog} capacity who prioritize data residency, developers building health products who want to defer integration complexity, and technically capable individuals seeking personal health data consolidation. It is less appropriate for teams needing immediate broad provider coverage without operational investment, or those requiring managed SLA guarantees.

With 2,153 stars, active development, and a clear roadmap toward AI-powered insights, the project merits evaluation for health data infrastructure needs. Explore the repository, join the Discord community, and assess whether its trade-offs align with your constraints.

Get started: https://github.com/the-momentum/open-wearables