Build personalized health products with one API for every wearable. Access wearable data, open health scoring algorithms, and structured context your AI can reason with. Self-hosted, open-source, MIT licensed.
Mine says 68 today. Green zone apparently. But 68 out of what? Compared to what baseline? Why 68 and not 71? Should I train hard or take it easy? The app doesn't say. It just shows me the number and a vague color.
Most wearables give you a score with zero explanation of how they got there. Black box. Proprietary algorithm, tuned for some average user that probably isn't you. You either trust it or you don't, but you have no way to verify it either way.
Every team building with wearable data rebuilds the same infrastructure. Oura, Garmin, Whoop, Apple Health: each with its own API, its own schema, its own quirks. Weeks of plumbing before you get to the product itself. And even once the data is flowing, you still have to turn it into something a user or a clinician can act on.
We've lived this at Momentum for years, shipping healthtech for digital health, wellness, and clinical teams. So we put the whole stack in the open.
Meet Open Wearables: the health intelligence platform for wearable data. One open-source layer to ingest from any wearable, standardize the signals, score them with transparent logic, and let AI reason over what's actually happening in a user's body.
Here's what Open Wearables gives you:
📡 Unified wearables API , ingest from Oura, Garmin, Whoop, Apple Health, Polar, Suunto, Samsung, Strava, Google Health Connect
🧬 Data standardization , one consistent schema across every device, so you stop writing per-vendor normalization code
🧮 Open health scoring logic, auditable, forkable, tuneable for your domain. No proprietary black boxes.
🎯 Coaching profiles, domain-specific intelligence layers for wellness, clinical, and performance use cases
🤖 MCP server, any LLM can reason over health trends and patterns, not just read raw numbers
🔒 Self-hosted by design, MIT license, HIPAA and GDPR friendly
💸 $0 per user at any scale, no per-seat pricing, no surprise bills at 10k users
Open Wearables is already running in production inside healthcare and wellness apps, including teams building AI coaching products on top of it.
What makes Open Wearables different?
Other wearable APIs stop at raw data delivery. Open Wearables is a full health intelligence layer: data in, meaningful signals and AI-ready context out. Open algorithms, zero per-user fees, and an AI-native architecture from day one. Built by Momentum, 130+ engineers with 10+ years of shipping healthtech in regulated industries.
🎁 Exclusive for Product Hunt: book a free 30-min architecture call with the Momentum team that actually built it. We'll walk through your stack and show where Open Wearables fits.
Would love your honest feedback, especially on what's missing for your use case.
Piotr, CEO & Founder @ Momentum
Report
The open-source, self-hosted approach is the right call for health data - it's one of those categories where developers and users both care deeply about where the data lives. I'm curious about something slightly different: have you thought about this beyond health apps? The idea of a unified API that aggregates personal data from multiple devices could be interesting for other contexts too. For example, we work with personal relationship data — contacts, interactions, communication patterns. The fragmentation problem is similar: everyone's data lives in 10 different places and nobody has a unified view. What was the decision to go deep on health vs building a broader personal data layer?
@ben_gend hey Ben, we specialize in healthcare so solving the wearable data fragmentation problem was the natural one to solve for us. This can be the use case one day when we extend the platform, but for now for the broader roadmap we aim to cover personal (health) data, biomarkers etc.
Report
Interesting concept. I’d be curious how you plan to handle Android wearable integrations when OEMs change health data schemas, limit background access, or tighten API permissions. Cross-device tracking usually becomes fragile once manufacturers start diverging from standard Android health frameworks or deprecating integrations.
@janusz_hain Good question, it's difficult to predict what possibly can change in the future, but our architecture was designed from day one to support many providers and make it easy to add or swap them out and this helps a lot in such situations. Every integration is a replaceable module, so when an API changes or gets deprecated, it's a bounded migration and the rest of the system stays stable.
For Android specifically, Google Health Connect acts as a standardized aggregator, so OEM-level schema changes are largely absorbed by Google. Our native Android/iOS SDKs (plus Flutter and ReactNative wrappers) use WorkManager for background sync, making them resilient to battery optimization and permission changes.
Report
The algorithm transparency thing is something I hadn't thought about before but now I can't stop thinking about it. I've been trusting a score for two years and have no idea what it's based on.
@pawel_glowczewski That reaction is exactly why we made every algorithm open source. All scoring models (sleep, HRV, recovery, strain, and more) live in the repo. You can read the logic, see the thresholds, and know precisely what shifts each number. No black boxes.
Report
The "you can audit and customize the algorithms" part is doing a lot of work in that description. Can a non-developer actually read and understand the scoring logic, or is it really aimed at engineers?
@kamil_zadlo1 Honestly, reading it yes: it's thresholds and formulas, not a neural net. Editing still takes a developer, so it's collaboration between domain expertise and code.
Report
Nutritionist here. Half of my clients track sleep and HRV obsessively but we're all working off screenshots and verbal summaries. Something that could aggregate this and let me run my own analysis would save hours per week. Do the scoring algorithms work without a developer integration or is this purely for engineering teams?
@adrian_bocianowski You can deploy the whole platform on Railway in about 5 minutes with one click, no specific server knowledge is needed. Once it's up, the MCP server lets you query all client data and run scoring analysis through Claude or another AI assistant without writing any code. The practitioner-facing layer that removes even that setup step is what we're building next, targeting Q2 2026.
Report
Congrats on the launch 😊 I run on a Garmin and track everything. Always assumed the body battery score was proprietary and untouchable. How much of Garmin's data does this actually expose?
@kamila_kuc Garmin exposes quite a bit through their API: sleep stages, HRV, body battery score, stress, SpO2, workouts, and heart rate time series all flow through. The body battery value itself is Garmin's proprietary calculation, so you get the score but not the formula behind it. That's why we also ship our own open recovery algorithm: same inputs, visible math, adjustable thresholds.
Open Wearables
Hey Product Hunt 👋
Every team building with wearable data rebuilds the same infrastructure. Oura, Garmin, Whoop, Apple Health: each with its own API, its own schema, its own quirks. Weeks of plumbing before you get to the product itself. And even once the data is flowing, you still have to turn it into something a user or a clinician can act on.
We've lived this at Momentum for years, shipping healthtech for digital health, wellness, and clinical teams. So we put the whole stack in the open.
Meet Open Wearables: the health intelligence platform for wearable data. One open-source layer to ingest from any wearable, standardize the signals, score them with transparent logic, and let AI reason over what's actually happening in a user's body.
Here's what Open Wearables gives you:
📡 Unified wearables API , ingest from Oura, Garmin, Whoop, Apple Health, Polar, Suunto, Samsung, Strava, Google Health Connect
🧬 Data standardization , one consistent schema across every device, so you stop writing per-vendor normalization code
🧮 Open health scoring logic, auditable, forkable, tuneable for your domain. No proprietary black boxes.
🎯 Coaching profiles, domain-specific intelligence layers for wellness, clinical, and performance use cases
🤖 MCP server, any LLM can reason over health trends and patterns, not just read raw numbers
🔒 Self-hosted by design, MIT license, HIPAA and GDPR friendly
💸 $0 per user at any scale, no per-seat pricing, no surprise bills at 10k users
Open Wearables is already running in production inside healthcare and wellness apps, including teams building AI coaching products on top of it.
What makes Open Wearables different?
Other wearable APIs stop at raw data delivery. Open Wearables is a full health intelligence layer: data in, meaningful signals and AI-ready context out. Open algorithms, zero per-user fees, and an AI-native architecture from day one. Built by Momentum, 130+ engineers with 10+ years of shipping healthtech in regulated industries.
🎁 Exclusive for Product Hunt: book a free 30-min architecture call with the Momentum team that actually built it. We'll walk through your stack and show where Open Wearables fits.
👉 https://www.cal.eu/openwearables...
Try it now: openwearables.io
Would love your honest feedback, especially on what's missing for your use case.
Piotr, CEO & Founder @ Momentum
The open-source, self-hosted approach is the right call for health data - it's one of those categories where developers and users both care deeply about where the data lives. I'm curious about something slightly different: have you thought about this beyond health apps? The idea of a unified API that aggregates personal data from multiple devices could be interesting for other contexts too. For example, we work with personal relationship data — contacts, interactions, communication patterns. The fragmentation problem is similar: everyone's data lives in 10 different places and nobody has a unified view. What was the decision to go deep on health vs building a broader personal data layer?
Open Wearables
@ben_gend hey Ben, we specialize in healthcare so solving the wearable data fragmentation problem was the natural one to solve for us. This can be the use case one day when we extend the platform, but for now for the broader roadmap we aim to cover personal (health) data, biomarkers etc.
Interesting concept. I’d be curious how you plan to handle Android wearable integrations when OEMs change health data schemas, limit background access, or tighten API permissions. Cross-device tracking usually becomes fragile once manufacturers start diverging from standard Android health frameworks or deprecating integrations.
Open Wearables
@janusz_hain Good question, it's difficult to predict what possibly can change in the future, but our architecture was designed from day one to support many providers and make it easy to add or swap them out and this helps a lot in such situations. Every integration is a replaceable module, so when an API changes or gets deprecated, it's a bounded migration and the rest of the system stays stable.
For Android specifically, Google Health Connect acts as a standardized aggregator, so OEM-level schema changes are largely absorbed by Google. Our native Android/iOS SDKs (plus Flutter and ReactNative wrappers) use WorkManager for background sync, making them resilient to battery optimization and permission changes.
The algorithm transparency thing is something I hadn't thought about before but now I can't stop thinking about it. I've been trusting a score for two years and have no idea what it's based on.
Open Wearables
@pawel_glowczewski That reaction is exactly why we made every algorithm open source. All scoring models (sleep, HRV, recovery, strain, and more) live in the repo. You can read the logic, see the thresholds, and know precisely what shifts each number. No black boxes.
The "you can audit and customize the algorithms" part is doing a lot of work in that description. Can a non-developer actually read and understand the scoring logic, or is it really aimed at engineers?
Open Wearables
@kamil_zadlo1 Honestly, reading it yes: it's thresholds and formulas, not a neural net. Editing still takes a developer, so it's collaboration between domain expertise and code.
Nutritionist here. Half of my clients track sleep and HRV obsessively but we're all working off screenshots and verbal summaries. Something that could aggregate this and let me run my own analysis would save hours per week. Do the scoring algorithms work without a developer integration or is this purely for engineering teams?
Open Wearables
@adrian_bocianowski You can deploy the whole platform on Railway in about 5 minutes with one click, no specific server knowledge is needed. Once it's up, the MCP server lets you query all client data and run scoring analysis through Claude or another AI assistant without writing any code. The practitioner-facing layer that removes even that setup step is what we're building next, targeting Q2 2026.
Congrats on the launch 😊 I run on a Garmin and track everything. Always assumed the body battery score was proprietary and untouchable. How much of Garmin's data does this actually expose?
Open Wearables
@kamila_kuc Garmin exposes quite a bit through their API: sleep stages, HRV, body battery score, stress, SpO2, workouts, and heart rate time series all flow through. The body battery value itself is Garmin's proprietary calculation, so you get the score but not the formula behind it. That's why we also ship our own open recovery algorithm: same inputs, visible math, adjustable thresholds.