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
Best
Trivia - the project origin was... standalone MCP server. It's funny, because now MCP server is a part of the Open Wearables, but it's still not 100% production ready. It's a long journey for that technology and in my opinion it's not that awesome as it seemed to be at the beginning.
@kaliszs Fair take Sebastian, and honest. MCP was hyped as the universal answer and it's clearly not, the spec is still moving, the tooling is uneven, and "agent reads your data" is harder in practice than the demos suggest. That said, for a narrow use case like structured health context for an LLM, it's still the cleanest pattern we've found. Worth shipping, not worth overselling.
Report
@kaliszs Yeah, that tracks with how a lot of infrastructure-first ideas evolve in practice.
@kaliszs haha yeah the origin story is a bit ironic
MCP had a lot of hype and reality is more nuanced. the protocol is useful but it's not magic - the hard part is still the context you feed it, which is exactly why the data and scoring layers matter
the server will get there. the foundation is what makes it worth building on
Report
great idea. I am missing easy way to get data from my garmin watch!
@gregory80pl Garmin is fully supported. Deploy on Railway in about 5 minutes and your watch data starts flowing through the API. GitHub link is in the description if you want to dig in.
Report
@gregory80pl We too xd Garmin is a tough one, but we handled it!
I share screenshots of my Whoop app with claude currently and ask it to analyse it based on the screenshot. Let me try using the MCP and ask it, feels like that could be a much smoother experience
@eva_kuttichova2 Btw, you find source code of both on our Github. Invitation links to try them are located in one of the Discord's channels ;)
Report
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.
congrats on shipping 🎉 quick question from someone who knows nothing about self hosting: does this require ongoing maintenance or is it more of a 'set it & forget it' situation once it's running?
@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
@priyankamandal Thanks Priyanka. Self-hosted + MIT removes two of the hardest conversations with compliance teams: where does the data live, and what happens if the vendor disappears. The architecture is HIPAA-ready out of the box (encryption, audit logging, RBAC), though the cert itself sits with whoever operates the deployment, not the software.
Report
@priyankamandal Open source community is a real strength! We have 40+ contributors.
Report
As I’m not a developer, is there an easy way for me to test this tool?
@imtiaj_ahmad Very scalable: FastAPI + PostgreSQL + Redis + Celery scales horizontally, and multiple companies run it in production today. The real advantage at scale is the cost model: zero per-user fees, so where SaaS aggregators charge $0.50-2.00 per user per month, you only pay for your own infrastructure. The bigger you get, the better the math works.
Report
This is great! Next thing we need is standardized API that the vendors commit to adopting. The Bluetooth heartrate profile and Generic Health Sensor profiles were a promising start but haven't lived up to their potential.
@richieoh Agreed Richie, the Bluetooth SIG profiles (HRP, GHS) had the right idea on paper but vendors have zero incentive to converge, differentiation and lock-in are part of the business model, so a pragmatic abstraction layer is the only thing that ships in our lifetime.
Replies
Trivia - the project origin was... standalone MCP server. It's funny, because now MCP server is a part of the Open Wearables, but it's still not 100% production ready. It's a long journey for that technology and in my opinion it's not that awesome as it seemed to be at the beginning.
Open Wearables
@kaliszs Fair take Sebastian, and honest. MCP was hyped as the universal answer and it's clearly not, the spec is still moving, the tooling is uneven, and "agent reads your data" is harder in practice than the demos suggest. That said, for a narrow use case like structured health context for an LLM, it's still the cleanest pattern we've found. Worth shipping, not worth overselling.
@kaliszs Yeah, that tracks with how a lot of infrastructure-first ideas evolve in practice.
Open Wearables
@kaliszs haha yeah the origin story is a bit ironic
MCP had a lot of hype and reality is more nuanced. the protocol is useful but it's not magic - the hard part is still the context you feed it, which is exactly why the data and scoring layers matter
the server will get there. the foundation is what makes it worth building on
great idea. I am missing easy way to get data from my garmin watch!
Open Wearables
@gregory80pl Garmin is fully supported. Deploy on Railway in about 5 minutes and your watch data starts flowing through the API. GitHub link is in the description if you want to dig in.
@gregory80pl We too xd Garmin is a tough one, but we handled it!
Velo
I share screenshots of my Whoop app with claude currently and ask it to analyse it based on the screenshot. Let me try using the MCP and ask it, feels like that could be a much smoother experience
Open Wearables
@ajaykumar1018 You can run the repo locally and setup the MCP server. Let us know your thoughts!
@ajaykumar1018 Feel free to use our MCP, but remember - it's still not 100% production ready.
Hello, can this be used for react natives based on Expo?
Open Wearables
@eva_kuttichova2 Yes we have both Flutter and React Native SDK.
@eva_kuttichova2 Btw, you find source code of both on our Github. Invitation links to try them are located in one of the Discord's channels ;)
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.
Open Wearables
@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!
Open Wearables
@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
Open Wearables
@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.
Open Wearables
@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
Lancepilot
Open Wearables
@priyankamandal Thanks Priyanka. Self-hosted + MIT removes two of the hardest conversations with compliance teams: where does the data live, and what happens if the vendor disappears. The architecture is HIPAA-ready out of the box (encryption, audit logging, RBAC), though the cert itself sits with whoever operates the deployment, not the software.
@priyankamandal Open source community is a real strength! We have 40+ contributors.
As I’m not a developer, is there an easy way for me to test this tool?
Open Wearables
@michal_kukul sure, probably the easiest way to give it a try is using one-click deployment on Railway - you can check how it works in our docs: https://openwearables.io/docs/deployment/railway
Open Wearables
@imtiaj_ahmad Very scalable: FastAPI + PostgreSQL + Redis + Celery scales horizontally, and multiple companies run it in production today. The real advantage at scale is the cost model: zero per-user fees, so where SaaS aggregators charge $0.50-2.00 per user per month, you only pay for your own infrastructure. The bigger you get, the better the math works.
This is great! Next thing we need is standardized API that the vendors commit to adopting. The Bluetooth heartrate profile and Generic Health Sensor profiles were a promising start but haven't lived up to their potential.
Open Wearables
@richieoh Agreed Richie, the Bluetooth SIG profiles (HRP, GHS) had the right idea on paper but vendors have zero incentive to converge, differentiation and lock-in are part of the business model, so a pragmatic abstraction layer is the only thing that ships in our lifetime.