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.
Forum Threads
How much can a wearable actually tell you about your sleep? webinar
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.
The Wearables Integration Playbook 2.0 is out
Quick update for anyone who followed the Open Wearables launch.
We just published the second edition of our Wearables Integration Playbook. It's the written version of what we learned building the platform and seeing it run in production.
Why does your recovery score say 58% today?
I wear a WHOOP. I've coached people on movement and sleep for many years and I still can't answer that question for myself. The algorithm is locked. You get a number, you trust it, you stop there.
When we built Open Wearables, we decided the scoring layer should work differently. Sleep Score and Resilience Score shipped in v0.5 - every coefficient, every threshold, every weighting is in the repo and you can fork them, tune for endurance athletes or elder care or clinical populations. Moreover, you run them on your own infrastructure and the same algorithms feed the MCP layer so AI coaching can cite the actual data behind a recommendation instead of approximating.
Three people in my Slack have tagged me in this today. The health data fragmentation problem is real and annoying, and the open-source angle means it might actually last longer than a VC-funded API startup.
@sebastian_krol Thanks Sebastian, that's a good signal. The durability point is exactly why we went MIT. Even if Momentum disappeared tomorrow, the code keeps working: you fork it, maintain it, extend it. Different risk profile than betting your product on a Series A startup's runway and pricing strategy. Plenty of healthtech teams have been burned by aggregators getting acquired, pivoting, or hiking prices once dependency lock-in kicks in. Open source isn't a magic shield, but it removes that specific failure mode.
@sebastian_krol Three people? Those are still rookie numbers ;)
@sebastian_krol That kind of organic Slack/word-of-mouth signal is usually more telling than any launch post.
@sebastian_krol three tags is a good sign
open source compounds - community keeps it alive, extends it, catches breaks. that's the whole advantage
Free, self-hosted, MIT license. Those three together in a health data tool is rare enough that I had to double-check the page. What's the long-term monetization plan, just curious?
@dawid_stajszczyk Ha, fair reaction. The model is intentionally boring: Open Wearables stays free and MIT, Momentum sells services on top (enterprise deployment, custom scoring algorithms, AI/coaching layers, HIPAA support, SLA-backed maintenance).
@dawid_stajszczyk This campaing is one of the monetization plans ;)
@dawid_stajszczyk The "AI/coaching layers" part caught my eye as a running coach. The infrastructure being free and open is what makes it trustworthy and trustworthy infrastructure is exactly what premium coaching tools need to be built on.
Showed this to a founder friend building a longevity tracking app. She said the API coverage alone would have saved them six months of backend work. Congrats Momentum, timing on this feels right.
@jakub_mikolajczyk1 Thanks Jakub, that's exactly the use case we built it for. Six months of OAuth flows, schema mapping, and provider edge cases is real time most teams don't have. If your friend wants to compare notes (or just complain about Garmin's docs), send her our way: Discord is the fastest path, or DM works too.
@jakub_mikolajczyk1 High five! And thanks!
@jakub_mikolajczyk1 six months is honestly conservative for some teams - the provider integrations alone are brutal to maintain
tell her we're here if she wants to talk through the use case: https://discord.gg/openwearables
@sourav_sanyal Three-device cross-talk is exactly where the unified model earns its keep. Quickstart is 5 minutes via Docker, would love to hear how it goes once you've plugged it in. One heads-up: CGM coverage is still in progress (Dexcom is on the roadmap, no committed date yet). Which CGM are you working with? If it's a high-demand one, that's useful signal for prioritization.
@sourav_sanyal haha, yeah that's amazing setup. Let us know on Discord, how it worked! :D
@sourav_sanyal CGMs are already on our roadmap, the problem is they mostly don't provide real-time data via API (most have few minutes delay) but we will get there 😎
Slightly skeptical question: how stable is the Garmin and Oura API access? Those platforms have changed or restricted third-party access before. What happens to a self-hosted deployment if an upstream provider breaks the connection?
@anton_zaporozhets1 Fair question. Both have official OAuth-based developer programs, and we've been shipping against them long enough to know the quirks (Garmin especially took real engineering time). If a provider changes something breaking: we patch, you pull the update. That's the OSS advantage. With a SaaS aggregator you wait for the vendor's roadmap and keep paying while you wait. No third-party integration is fully immune. The difference is how fast the fix lands and whether you can read the diff yourself.
@anton_zaporozhets1 Of course Open Wearables will propagate error (I suggest to use something like sentry to catch such exceptions), but you will still be able to connect with other providers, even if you will have broken connection with Garmin.
And I understand your concenr. In 2024 (or event 2025, don't remember) Garmin switched from OAuth v1 to Oauth v2 for example. It's a big change, but they didn't remove old endpoints which based on old OAuth standsrd. Of course it wasn't documented after the update to not tempt new users to use this.
@joanna_samek Thanks Joanna! Honest answer: closer to "low maintenance" than "set and forget."
Once it's running, the main things are pulling updates when we ship a release, watching logs for errors, and occasional database housekeeping. Provider APIs change sometimes (Garmin tweaks something, Oura updates a field), we patch it, you pull the update. Security patches are mostly automated via Dependabot.
Realistically, a small team spends a few hours a month on it. If that sounds like more than you want to take on, Momentum offers managed deployments where we handle all of that for you.
@joanna_samek the easiest option is to use one-click deployment on Railway so you don't have to worry about infrastructure so much. At least with relatively low scale this might be the best solution but once your user base grows it might become a bit pricey
This could help a lot of indie health apps that never get built because of infra friction. Good stuff.
@itsluo That's the exact problem we keep seeing. Six to twelve months of OAuth integrations before you can ship anything meaningful kills most indie health projects before they start. Railway deploy in five minutes was a deliberate choice.
@itsluo Does the `indie health app` label fits to you company? :)