Open Wearables - Open infrastructure for wearable-powered health products.
by•
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.
Replies
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
@piotreksedzik 130+ engineers and 10 years of healthtech experience shows in the schema. It’s clear this wasn't just built in a weekend it’s battle-tested. How do you guys handle data backfilling for new users can we pull the last 90 days of history from Health Connect or Suunto automatically?
@piotreksedzik - This is great. I have done POC with ow in my app and is much more economical as compared to the alternatives. Just waiting for the full fitbit integration available on openwearables. Thank you!
@piotreksedzik @pramod_sayanekar Fitbit integration should be 100% ready in May or June probably.
Open Wearables
@pramod_sayanekar amazing!!! would love to hear more about what you're building with OW!
@kaliszs Thank you!
@piotreksedzik - App is already live - https://zzorph.ai
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.
@ben_gend Interesting take. Maybe it's worth to give a shot as a forked project for now? idk, would be interesting to start a discussion on Github Discussions also.
@ben_gend Ben - fragmentation is the universal pattern, you're right. We picked
health because that's where Momentum lives every day, and going deep
on one domain beats going wide on five. But the architecture isn't health-specific - it's "unify messy
provider APIs into one schema." Same engine could absolutely sit under personal/relationship data.
Open Wearables
@ben_gend the parallel is real - fragmentation + privacy sensitivity + no unified view. same problem, different domain
the health focus was a deliberate bet. health data is time-series, physiological, needs domain-specific reasoning
to mean anything. going broad too early usually means going shallow
what are you working on exactly? curious
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.
Open Wearables
@janusz_hain it's a real concern and we won't pretend otherwise
our approach is to abstract at the provider level - when Samsung or Google changes something, the fix is in one place. but manufacturers do break things, we've seen it firsthand
the bet is that an open-source shared layer catches and patches these breaks faster than every team doing it in isolation. community maintenance vs. solo maintenance
Android (Samsung Health, Google Health Connect) is live, but it's not zero-maintenance. nothing in this space is
@janusz_hain Janusz - operator angle: across the Momentum portfolio we've watched teams burn 1-2 sprints per quarter on OEM-level breakage alone. The shared open-source layer doesn't remove that cost - it just makes it absorbed once, not n times.
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.
@pawel_glowczewski Fun fact, our algorithm makes the scores very similarto what whoop calculates.
@pawel_glowczewski same here
@pawel_glowczewski @kamil_zadlo1 exactly same here guys
Open Wearables
@pawel_glowczewski yeah once you see it you can't unsee it
a number between 0-100 with no explanation is just vibes with a UI. you change your behavior based on it and have no idea if the model even supports that conclusion
that's the whole reason open algorithms matter
@pawel_glowczewski I feel exactly the same - it’s one of those things you don’t question until someone points it out, and then you can’t unsee it.
I’ve also been relying on these kinds of scores (sleep, HRV, etc.) for quite a while without really knowing what’s behind them. It’s a bit strange when you think about the fact that decisions are often based on those numbers.
It would be great to at least have some basic visibility into how those scores are calculated - or a way to interpret them more consciously.
Hey, I've tried three different health data aggregators and the one thing they all had in common was a monthly bill. Bookmarking this to try properly over the weekend.
Open Wearables
@qtvinsky yeah that's the pattern - you pay to solve the data problem before you've even validated the product
let us know how it goes over the weekend, happy to help if you get stuck: https://discord.com/invite/qrcfFnNE6H
@qtvinsky And here Open Wearables go ;) Free and self hosted, great advantage.
Of course you still have to pay for you hosting, but I guess nothing is really free.
@qtvinsky 100% agree. Same here
@qtvinsky Jacek - those monthly bills usually start at $200-500/m before you've even shipped, then scale per user. Self-hosted you're paying $10-30/m for a small VPS until traction forces you up. That delta is why we did it this way. Ping us in Discord if Saturday gets weird.
@qtvinsky Same here!
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.
@kamil_zadlo1 Yeah I think so. It's thanks to our detailed documenation.
@kamil_zadlo1 yeah I think so too
@kamil_zadlo1 I’ve been wondering the same - it sounds great, but I’m curious how accessible it really is for a non-developer.
If it’s mostly code or complex logic, it’s probably hard to truly understand without a technical background.
Ideally, I’d love to see a simpler, more readable explanation of what drives the scoring, without needing to dig into code.
@kamil_zadlo1 As a running coach (not a developer), I can read the logic fine, thresholds, weights, conditions. It's closer to reading a training plan than reading code. What matters to me is being able to say to an athlete: "your recovery score is low because HRV dropped AND sleep was short AND yesterday's load was high", not just "the algorithm says so." When the logic is open, I can actually explain the number. That's the real value for coaches. What do you think?
Tech To The Rescue
This is the kind of infra that quietly unlocks entire categories.
Everyone talks about AI in health.
Almost nobody fixes the data layer first.
Unifying wearable data + adding a reasoning layer (not just dashboards) is the real game.
Feels like “Stripe for health signals”... but open!
Open Wearables
@tomik99 nobody fixes the data layer first because it's unglamorous. but you can't reason over garbage -sequence matters
the reasoning layer is honestly what we're most excited about. raw numbers mean nothing without context, that's the whole point of building this
and "but open" is what changes the Stripe analogy - you can audit, fork, run it yourself. that's a different relationship with infrastructure entirely
"Stripe for health signals but open" - we love that, might steal it
Open Wearables
@tomik99 Thanks Tomasz, the "AI in health without fixing the data layer first" frustration is exactly what pushed us to ship this. Most health AI demos break the second you put real, multi-device, multi-format data behind them.
@tomik99 Tomasz - "quietly unlocks entire categories" is exactly the read. From the ops side I kept seeing portfolio teams burn 3-6 months on the same Oura/Garmin/Whoop plumbing before they could even start the actual product. That's the tax we got tired of paying. Open part isn't a marketing flourish - it's the only way infra like this actually compounds across companies.
@tomik99 Exactly. The most interesting part is - after 6 months of work we are just starting with implementing AI. So much of old school software work has been done before.
The Garmin support stood out to me. Most integrations treat it as the afterthought behind Apple and Oura. Garmin users track seriously and the data depth is there, it just never gets used properly.
Open Wearables
@sylwia_kustrzycka Exactly the observation we built around. Garmin users generate some of the richest longitudinal data out there and most platforms surface maybe 20% of it. We pull the full range: sleep stages, HRV, body battery, stress, workouts, SpO2, and more.
@kamil_maksymowicz Exactly! Having access to specific metrics like Body Battery, detailed HRV, and SpO2 is a total game-changer. It's great to finally see someone extracting 100% of Garmin's capabilities instead of just settling for surface-level stats. Awesome job!
@sylwia_kustrzycka But Garmin is still among 1st classers tbh. Check out Suunto for example, that's a hidden gem ;)
@kaliszs Totally agree, Suunto is definitely a hidden gem, especially for hardcore outdoor enthusiasts! Who knows, maybe after taming Garmin, their API will be next on the Open Wearables roadmap. 😉
@sylwia_kustrzycka That’s a fair observation — Garmin users are often the “serious end” of tracking, but a lot of apps still optimize around Apple Health and Oura first.
Garmin’s data depth is definitely there, but it tends to be fragmented across metrics, so the value often gets lost unless something actually consolidates and interprets it well. If an integration can do that cleanly, it’s probably a big unlock for endurance athletes and coaches in particular.
The real gap has always been less about access and more about making the data usable in a consistent way across different contexts.
@kamil_zadlo1 Spot on! The sheer depth of Garmin's data doesn't mean much if it stays fragmented. The real value (and the hardest part) is consistently consolidating and normalizing these metrics. If this solution lets coaches and athletes draw actionable insights without fighting data chaos, that's a massive step forward ;)
Open Wearables
@sylwia_kustrzycka Garmin users are seriously data-rich and somehow always the afterthought
the API is painful but the data depth is real. glad we got it right
@piotr_pasierbek The pain of dealing with the Garmin API is pretty well-known in the industry, so massive kudos to you guys for doing the heavy lifting and getting it right! You're definitely going to save developers countless hours of headache. Congrats!
@sylwia_kustrzycka Noticed the same - Garmin often gets overlooked, even though the depth and quality of data is actually really solid. It just rarely gets used properly.
@adrian_bocianowski Definitely! Glad to hear I'm not the only one feeling this way. Fingers crossed that with the groundwork laid by Open Wearables, these powerful Garmin datasets will finally start being fully utilized by other platforms.
Not a developer but I understand the problem well. I switched from Whoop to Oura last year specifically because I wanted to own my data and then realized neither platform gives you anything meaningful on export. Upvoted.
Open Wearables
@krzysztof_kundys this is exactly why we built it
"own your data" is marketed everywhere but the export is usually a CSV with 12 columns and no context. that's not ownership, that's a file dump
the goal is that your health data actually does something - feeds AI, triggers automations, gets reasoned over. not just sits in a folder
glad you upvoted, means a lot on launch day
@krzysztof_kundys Exactly! Whoop charges me $30/month and won't let me export my data in any useful format. I didn't realize this was a solved problem. Congrats to the team on shipping this.
@krzysztof_kundys That’s a pretty common realization after switching — the “you own your data” message sounds straightforward, but in practice the export layer is often just raw logs without much structure or context.
Open Wearables
@krzysztof_kundys "own your data" as a feature that doesn't actually let you own your data - that's the whole problem in one sentence
glad you upvoted, means a lot today
The privacy angle here is the real story for me. Your health data sitting on your own infrastructure instead of someone else's cloud is a meaningful difference, especially for anything HRV or sleep related.
Open Wearables
@kuba_siwek Exactly! However, it doesn't mean your data doesn't sit on wearable providers' cloud - for cases like Polar, Suunto, Garmin etc. Open Wearables still pulls data from their cloud api. However, for Apple Health, Samsung, Google - Open Wearables pulls data from your local device and put it into your server. This is done by our SDKs.
@piotr_ratkowski Thanks for clarifying — that distinction really matters to me. Health data like HRV and sleep says a lot about a person, so knowing it goes straight from my phone to my own server (at least for Apple, Samsung, and Google) genuinely changes how I feel about it!
@kuba_siwek @piotr_ratkowski Yes, but they comes from that cloud, so it doesn't count ;)
@kuba_siwek I mean it's self-hosted, so what could go wrong here?
@kuba_siwek Yeah, that’s a fair point — the privacy angle is probably underrated in a lot of these discussions.
Open Wearables
@kuba_siwek yeah, this is the one we feel strongest about
HRV, sleep, recovery - this is genuinely sensitive data. it reflects stress, illness, mental state. it shouldn't live on someone else's servers by default
self-hosted by design, not as an afterthought
@kuba_siwek
Exactly my thoughts. Privacy by design is the only way forward in healthtech right now.