Launched this week
Open Wearables
Open infrastructure for wearable-powered health products.
1.4K followers
Open infrastructure for wearable-powered health products.
1.4K followers
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.
Does this require running your own server infrastructure to be useful, or is there a path for someone who just wants to connect their Garmin and start pulling data without a DevOps background?
Open Wearables
@gosia_boryn The easiest option would be to use one-click Railway deployment to set up your own instance in the cloud. Then you can start pulling your data from there via API 🙂
@piotr_sobusiak Let's do it togather and record it :) to show if it as easy as said.
Open Wearables
@gosia_boryn In the documentation link I've sent there is actually a walk through on YT of the whole process of one-click deployment to Railway. There is an official template for that you can find on Railway marketplace. If you run into any problems during the setup, please reach out to us and will do our best to help 🙂
@gosia_boryn But it's important to be aware of - you can't use Garmin API as a private person. It's restriction of most API based providers. But if you want to use cloud based, like Apple, Google and Samsung - you are free to go! :)
Launch OS
Am I seeing this right? Its opensource?
Where would I be paying?
Open Wearables
@worklab It's self-hosted, so you pay for infrastructure usage. As Momentum we also support custom deployment and build services around Open Wearables whenever you need building your product with our tool.
@worklab You don't pay, thats the trick ;) Its license is MIT.
Open Wearables
@worklab it is completely free under MIT license. But if you ever build something with Open Wearables we'd love to hear about it - come share it on our Discord!
The gallery screenshot showing the API response for sleep stages actually made me stop scrolling. I've been pulling this data manually from Apple Health exports for two years. Why does this not exist as a consumer product yet?
Open Wearables
@paulina_kowalczyk Two years of manual Apple Health exports is exactly the pain that shouldn't exist in 2026. Open Wearables is the infrastructure layer for that consumer product, if anyone (you?) feels like building it, we'd happily help.
@paulina_kowalczyk It's because most of the providers don't want the products like this to be available for consumer. Sadly, but this is the truth. Just look at the Garmin for example - there is no way to get API access if you are not a company.
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
From a user POV - that's the thing I've been looking for! How did you put on top the domain knowledge? It is so interesting!
Open Wearables
@matt_kopiec We kept rebuilding the same wearable integrations from scratch for every client. After enough of that, you develop strong opinions about what the scoring should actually look like. We codified those into the algorithms and opened them up.
@matt_kopiec We have started with MCP servers, then we moved to the project called "healthion", which was baically jus ta simple FastAPI with frontend with an access to the MCP.
Open Wearables
@matt_kopiec Glad it resonates! It's a mix of things, but definitely deep work with wearables and health data over the years helped a lot. We also have a PhD in Neuroscience on the team 🙌
Congratulations on the launch! Your unified health data model is what interests me the most, but I'm worried about datatype proliferation/complexity if I build something downstream of OpenWearables (e.g. your wide table for WorkoutDetails). I really appreciate that I would have the same problem if any given wearable provider made changes to their schema, but what are your plans for keeping your data model in sync with providers without causing other developers headaches?
@hex_miller_bakewell Thanks Hex - exactly the right question. Schema drift here is unavoidable, but we're trying to make it bounded. Our approach: stable versioned core for the common path treated as a contract; provider-specific quirks accessible but separate; additive changes by default; explicit deprecation windows for actual breaking changes. WorkoutDetails specifically is one of the messier surfaces - we know, we're treating it as evolving. Schema is in the repo - happy to go deeper via DM or GitHub issues, can loop in our engineering lead for a proper versioning rabbit-hole. Thanks for the kind words on the launch 🙏
@hex_miller_bakewell I don't think it's possible to avoid that issue anyway.
Documentation.AI
Good launch!! Any plans for real-time streaming data support or is it batch-based right now?
Open Wearables
@roopreddy Batch-based right now, which reflects the underlying provider APIs: most wearables sync to their cloud on a schedule rather than streaming continuously. Some providers like Whoop expose webhooks, and we're looking at event-driven support for those. True real-time would require lower-level device access that most providers don't offer yet.
Open Wearables
@roopreddy Thanks! This depends also on the providers how often they push data but as soon as these data reaches Open Wearables, there are webhooks you can use to push data to your backend real-time - here is more info about it: https://openwearables.io/docs/api-reference/guides/webhooks#outgoing-webhooks-open-wearables
@roopreddy To not repeat afer other, I can tell that FIT files supports is also planned, so it can changed how we fetch data to Open Wearables.