Hi makers,
Most wearables are good at telling when you're asleep. They're much worse at telling when you're awake: if you lie still, many devices count it as sleep. Sleep stages land somewhere in between. And Apple, Oura, Garmin, Whoop and Fitbit all build their scores differently, so the same night can get very different numbers.
Anna D. Zych, PhD, a neuroscientist and Health Science Lead at Momentum, goes through all of this in a webinar that premieres Wednesday, 7 October at 16:00 CET. It covers what good sleep actually looks like, how wearables compare to a sleep lab across ten devices, and how to approach building sleep scoring models.
If you're building anything with sleep or recovery data, it should be a useful hour. Everyone who signs up gets the recording too.
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.
@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?
@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.
@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
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.
@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?
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.
@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
@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.
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.
@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.
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.
@kamila_kuc I would say, garmin (next to Apple) expose the greates volume of different statistics.
@kaliszs i agree :)
@kamila_kuc Good question — I’ve always had the same assumption about Garmin’s metrics being pretty locked down.
@kamila_kuc Body Battery is Garmin's proprietary score, they keep the inputs closed so we can't touch it
but everything Garmin shares via API - HRV, sleep stages, stress, SpO2, activities, heart rate - we expose. and our own open scoring algorithms compute recovery, sleep quality and strain on top of that
so you lose Body Battery, gain full visibility into what's underneath it
@kamila_kuc Congrats 😊 I’m in a very similar situation - also using Garmin and always assumed Body Battery was a complete black box.
From what I understand, Garmin exposes quite a lot of data like sleep, heart rate, stress, and even the Body Battery score itself. But the actual logic behind it is still hidden.
So you get the numbers, but not really the “why” behind them, which is the most frustrating part as a user.
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.
@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.
@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.