Open Wearables Open-source, self-hosted wearable data layer: one API and one schema for the devices your users already wear. Website · Documentation · Quickstart · Providers · Roadmap Open Wearables is an open-source platform that connects wearable devices and health apps, standardizes their data into one schema, and serves it through a single REST API. It runs inside your own cloud account, so data goes from each…
Open Wearables is an open-source platform that connects wearable devices and health apps, standardizes their data into one schema, and serves it through a single REST API. It runs inside your own cloud account, so data goes from each provider straight to your deployment without passing through a third party.
Instead of building and maintaining a separate integration for Garmin, Oura, Whoop, Polar, Apple Health, Samsung Health, Google Health Connect and the rest, you deploy one service. It handles provider OAuth, background sync, webhooks and mobile SDK uploads, and your product reads sleep, activity, workouts and heart rate the same way whatever device the data came from. A built-in MCP server lets LLMs and AI agents query the same data.
It is built for teams whose product runs on wearable data: digital health products and health data platforms, care programs, hospitals and telemedicine, remote patient monitoring, clinical research and more. See who runs Open Wearables in production.
Why self-hosted
Open Wearables runs on your own infrastructure. In practice that means:
You decide where the data lives. Deploy to whatever cloud and region your requirements call for (HIPAA, GDPR, internal policy) and control who has access.
Provider apps and tokens belong to you. You register the developer apps with Garmin, Oura, Whoop and others under your own account, and OAuth tokens are stored in your database.
Nobody sits between you and the provider. Data goes from the provider’s API straight to your deployment, without passing through any third-party service.
MIT licensed. Read the code, change it, fork it, run it in production. If you fix or build something others could use, we’d be happy to take it upstream. See the contributing guidelines to get started.
How it works
Connect. A user links a wearable account through a connection link, or syncs Apple Health, Samsung Health or Health Connect from the phone through a mobile SDK.
Sync. Open Wearables pulls data through provider webhooks and scheduled syncs, including a historical backfill on first connection.
Standardize. Every record is mapped into one unified data model in your PostgreSQL database. If you want the originals too, raw provider payloads can be captured to S3 before processing.
Notify. Your app receives an outgoing webhook when new data arrives.
Query. Your app reads the data through one REST API, in the same shape whichever provider it came from.
Supported providers
Cloud providers, connected server to server through OAuth:
Meals with energy and macronutrients, from the sources that provide them
Women’s health
Menstrual cycle records
Provider metrics
Values computed by the device provider itself, stored as reported and labeled with their source
Quickstart
Run Open Wearables locally with Docker in a few minutes.
git clone https://github.com/the-momentum/open-wearables.git
cd open-wearables
make init
docker compose up -d
make init creates both .env files from their examples and generates SECRET_KEY. Without make, copy them yourself and set SECRET_KEY to the output of openssl rand -hex 32 (at least 32 characters, or the backend does not start).
Developer portal:http://localhost:3000. Create API keys and add provider credentials here.
Sample data (optional):make seed creates test users with activity data.
Warning 警告
An admin account is created on first startup from the ADMIN_EMAIL and ADMIN_PASSWORD variables (defaults: [email protected] / your-secure-password). The seed runs only while no developer account exists, so changing ADMIN_PASSWORD later does not update it. Set your own ADMIN_PASSWORD before the first start, or change the default password in the developer portal right after your first login. With ENVIRONMENT=production the default password is refused: a fresh deployment does not start until ADMIN_PASSWORD is set, and an admin that still has the default cannot sign in until you set ADMIN_PASSWORD (with ADMIN_EMAIL matching that account’s email) and restart the backend, which then changes that account’s password to it.
Running in production
docker compose up builds from local source and is meant for development. On any server reachable from the internet set ENVIRONMENT=production, which refuses the default admin password. In production, run the official images pinned to a release tag, not nightly or a build of main:
One REST API with OpenAPI documentation, consistent regardless of the source device.
Daily summaries, time series and events (workouts, sleep sessions) in a unified data model.
Data priorities: decide which provider and device type wins when sources overlap.
Multi-account sync: one provider account can be linked to several user profiles.
Connections and sync
OAuth flow management through a connection link: the user picks their provider, authenticates, and data starts syncing.
Historical backfill on first connection, within each provider’s limits.
Live sync progress as a server-sent event stream, plus sync run history in the API and the portal.
Webhooks
Register HTTPS endpoints and get notified when new data arrives. Filter by event type or user, verify signatures, send test events and inspect every delivery attempt. Outgoing webhooks are off by default, see how to enable them in the webhooks guide.
Mobile SDKs and app
Apple Health, Samsung Health and Health Connect keep data on the phone, with no cloud API. The SDKs read it on the device and upload it to your deployment.
No app of your own yet? A simple demo app syncs on-device health data to your instance with an invitation code (setup guide). TestFlight (iOS) and APK (Android) builds are available on request in Discord.
For production use, Open Wearables Connect, a full-featured app, is coming soon to the App Store and Google Play. A white-label version, published in the stores under your own brand, will be available as well.
MCP server for AI agents
A built-in Model Context Protocol server gives Claude Desktop, Cursor and other MCP clients access to your users’ wearable data. Ask “How did John sleep last week?” and the model fetches the right records itself. Keep in mind that the records it fetches are sent to the model provider behind your MCP client.
A web dashboard with light and dark themes, usable on a phone:
Dashboard with users and data points at a glance.
Users: connected sources and data explorers for activity, sleep, workouts, body, meals and women’s health.
Coverage and syncs: which data types each provider delivers, and every sync run.
Webhooks: endpoints and delivery debugging.
Settings: API keys, provider credentials, data priorities, data lifecycle, team invitations and a seed data generator.
Data lifecycle and raw payloads
Configurable archival and retention of time series data.
Optional raw payload storage: capture provider payloads exactly as they were sent, to logs or an S3 bucket, and replay them against new parsing logic. Disabled by default.
Architecture
Layer
Technology
Backend API
FastAPI (Python)
Developer portal
SvelteKit and TypeScript (Bun, server-rendered)
Storage
PostgreSQL and Redis
Background jobs
Celery worker and Celery beat, for syncing and processing
Outgoing webhooks
Svix server (optional)
Object storage
S3-compatible bucket (optional): raw payloads, Apple Health XML imports, SDK payload offload
MCP server
FastMCP, run by your AI client over stdio; it calls the REST API with an API key
Monitoring
Flower (optional), OpenTelemetry and Sentry (optional)
Authentication
Self-contained, no external auth service
Each deployment serves a single organization, with no multi-tenancy. Read the system overview and the data flow for the full picture.
Roadmap
Current priorities are performance at scale, compliance features for regulated products, data model hardening and faster mobile sync. See the roadmap, and tell us what you need on Discord or in Discussions.
Telemetry
Open Wearables sends a small anonymous usage ping once a day, plus one on startup, to help us see which providers and features are used. It contains a random instance identifier generated locally on first run, the Open Wearables, Python and OS versions, and aggregate, bucketed counts and configuration flags. It never contains health data, user data or credentials. The API logs a notice at startup while telemetry is on.
To turn it off, set TELEMETRY_ENABLED=false (or DO_NOT_TRACK=1) on the backend containers. The telemetry docs list every field we collect and why.
Join the Discord
Talk to the maintainers and other teams building on Open Wearables, get help with your deployment, and hear about releases first.
Contributing
Contributions are welcome, from bug reports and small fixes to larger features. Before you write any code, please take five minutes to read CONTRIBUTING.md: it explains how to agree on a change with us first, how to set up the project, and what we expect in a pull request, which leads to better PRs and quicker reviews. AI-assisted contributions are welcome - just tell us which tools you used and make sure you understand what you are submitting.
Need a provider that isn’t supported yet? Open an issue or ask on Discord first so we can agree on scope.
MIT. Use it freely in commercial and open-source projects.
Pro and Enterprise
The open-source core is free and MIT licensed. For teams that want more on top of their deployment, Open Wearables also comes in Pro and Enterprise tiers:
Connect App: the ready-made iOS and Android app for Apple Health, Health Connect and wearable data, with no user limit and an option under your own brand.
Health scores: sleep, recovery and activity scores, designed and validated by our science team and consistent across devices.
AI Insights: an AI assistant that analyzes each user’s wearable data and answers their questions about it. It runs as an optional service next to your instance and is configured from the dashboard. Bring your own LLM key (OpenAI, Anthropic or Google), set the assistant’s tone and task, and add your own domain knowledge.
Medical-grade integrations: certified medical devices such as CGMs, blood pressure monitors, ECG devices and pulse oximeters, kept up to date by us.
Observability: sync health per provider and per user, so a broken connection is caught before your users notice.
Enterprise adds ongoing maintenance and SLA support, plus the security and compliance work regulated teams need: audit logging, infrastructure hardening, signed agreements, answers to security questionnaires and delivery under certified quality management. Compare the plans for everything each one includes, including deployment in your cloud.
Built with ❤️ by Momentum
Open Wearables is created and maintained by Momentum, a software and AI development agency that turns health data into intelligent products. The backend started from Momentum’s Python AI Kit.
![dependabot[bot]](https://avatars.githubusercontent.com/in/29110?v=4)
评论