Open Wearables - Open infrastructure for wearable-powered health products.

@adrian_bocianowski You can deploy the whole platform on Railway in about 5 minutes with one click, no specific server knowledge is needed. Once it's up, the MCP server lets you query all client data and run scoring analysis through Claude or another AI assistant without writing any code. The practitioner-facing layer that removes even that setup step is what we're building next, targeting Q2 2026.

@adrian_bocianowski screenshots and verbal summaries - that's the current state of health data collaboration and it's painful

honest answer: right now it does require a developer to set up. it's not a no-code tool yet

but what you're describing is exactly the use case we're building toward - a practitioner who can pull a client's real data, run analysis, ask the AI layer questions. not guess based on a screenshot

if you have a developer on hand or know one, happy to help get something working: https://discord.gg/openwearables

@adrian_bocianowski same pain, different angle. I'm coaching runners and you're advising on nutrition, but we're both stuck interpreting screenshots instead of actual data. Curious: when you see HRV trend dropping over a training block, do you adjust nutrition recommendations proactively, or do you wait for the athlete to flag fatigue themselves? Wondering how much the data actually drives your decisions vs just confirms what they're already telling you.

@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.

@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.

@michal_stochmal That exact problem is what the normalization layer is for. Raw HRV readings will still vary by sensor hardware (optical vs chest strap vs ECG), but OW runs the same scoring formula on top of normalized data regardless of device. Two athletes, same algorithm, comparable output. And since the thresholds are open, you can tune them for endurance training specifically rather than relying on defaults built for a general population.

@michal_stochmal They are, because we share scores from all providers and calculate our own score, using custom algorithm. It will be improvedover time of course, but right now it's already comparable to the whoop scores.

@michal_stochmal Anyway, may I ask about your experience with your clients? Which devices are a top tier choices among runners? Are they all using Garmin or do you track usage of Suunto, Polar or Coros?

@michal_stochmal That’s a very real issue in practice — even small differences in sensors and smoothing can cascade into pretty different recovery/readiness outputs.

Thanks @mikhail_prasolov ! That's actually quite tricky as the data coming from different providers is surprisingly quite different even though these are often the same pieces of information. As you mentioned these are often in different formats, sometimes aggregated or processed in some way. We've come up with what we called Unified Health Data Model and you can also see Data Types and Coverage Matrix to check what data types we support and how they are normalized across providers.

@piotr_ratkowski  @bartmichalak  @piotr_sobusiak  @mikhail_prasolov 
haha Piotr representation is strong on this team, can confirm

normalization is the boring core of the whole thing - every provider has different field names, different units, different nulls, different timestamps. we map everything to a unified schema at ingestion so whatever's above it (scoring, AI, your app) never has to care where the data came from

it's unglamorous work but it's what makes everything else possible

@piotr_ratkowski  @bartmichalak  @piotr_sobusiak  @mikhail_prasolov Our unified data model assumes that we create a Strategy class for each provider. By inheriting from an abstract base strategy, this class enforces a consistent structure. This means we have predefined areas (e.g. workouts, continuous data (sleep, HR, etc.), provider authorisation, or the method of data retrieval) and in each there are either certain gaps to be filled (e.g. workouts and continuous data require the definition of a function to normalise the data to our model, which requires knowledge of the payload coming from the provider’s API – the rest of the functions that process this normalised data are already inherited from the base strategy) or several defined paths to choose from (e.g. authorisation requires specifying the authorisation method imposed by the provider’s API, and the data retrieval method determines whether we need to query the API periodically ourselves, or whether it is sufficient to connect once and receive data almost in real time). Finally, the normalised data is sent to the database, and from there it is retrieved, for example, by our webhooks, which will send notifications to clients’ backends whenever any data becomes available.

@farce1 That Garmin badge took longer to earn than we'd like to admit. 😅 You put it well: the data was never really the problem, getting it into a shape any app can reliably build on is. Thanks for the kind words to the whole team.

@farce1 haha, agree - worth it!

@farce1 "surviving Garmin's API" is going on the team wall

and yeah - the standardization layer is the unglamorous part nobody wants to build twice. that's exactly why it should be shared infrastructure

thanks for the kind words

@jakub_burdajewicz Golf training app on sports watches is a solid fit. Strain, recovery, and HRV scoring are built in, and if your athletes are on Garmin, Polar, or Suunto, all three are supported out of the box. Drop by our Discord if you want to talk through the integration before your team digs in.

@jakub_burdajewicz Tbh there is still not so much of an AI. But it will be!

Btw which devices do you use for golf? I heard about special garmin models, are they worth it?

@jakub_burdajewicz Jakub - golf is one of the cleanest cases for a unified layer. Most serious players already stack a golf-specific watch (Garmin Approach line) with a recovery wearable (Whoop/Oura) — two devices,

two ecosystems, zero conversation between them. That's exactly the gap this fills. Drop into Discord, would love to see what you're building.

@jakub_burdajewicz golf training + wearable data is a great fit - recovery, strain, sleep before a round. a lot of signal there that most apps ignore

we'd love to see what you build. drop by Discord and let's talk: https://discord.gg/openwearables

@iwan1212 "Stops the screenshot chase" might be the best one-line description of the problem we've heard. Coaches managing 20 athletes across 5 different apps is a real workflow nightmare and it's invisible until you sit with them.

Thanks for shipping with it Patryk. If you ever want to write up the deployment as a case study (or just a thread), happy to help, that story would land with a lot of teams.

@iwan1212 That’s actually the most compelling version of this story — not the aggregation itself, but removing the “screenshot + interpretation by hand” workflow from coaching entirely.

@iwan1212 Forgive me for being curios, but what type of the club is it?

@iwan1212 this is exactly the use case we had in mind - coaches seeing real data across the whole roster, not chasing screenshots

love hearing it's working in the wild

@iwan1212 "Stops the screenshot chase" this is so real. I've spent more time texting athletes "send me your HRV from last night" than actually coaching. Having readiness and load in one place, regardless of device, is the difference between reactive and proactive training decisions.

Hi @iamanantgupta We already integrate with Apple Health and Google Health and provide SDKs for SDK-based providers - you can see providers we support and full coverage matrix in the documentation: https://openwearables.io/docs/providers/supported

@iamanantgupta Is Google Fit the same thing as Google Health? If so, we already have it.

@krzysztof_szyszkiewicz thank you!

honest answer: today it requires some technical setup - you need to run the platform and connect the MCP server to your AI client. not rocket science but not one-click either

the vision is exactly what you described though - ask Claude or ChatGPT "why did I sleep badly this week" and get an actual reasoned answer based on your real data, not generic advice

that's where we're going. docs here if you want to try: https://docs.openwearables.io

@krzysztof_szyszkiewicz MCPs are not that complex, but processing such big amounts of data given limited context of LLMs usually is. We already have very first version of Open Wearables MCP server (it's in the repo so everyone can use it) but it needs some polishing to call it production grade and work flawlessly with big data sets.

@krzysztof_szyszkiewicz It shold be easy to setup, but I don't think it's really that useful. Simple chat with AI agent will do a better job. And that's also going to be avilable.

@wszubryt that means a lot, thank you

the pricing thing is something we felt strongly about from day one. per-user fees at scale just punish success - you build something that works, your costs explode. doesn't make sense for health apps especially

open algorithms matter too because health scoring has been a black box for too long. sleep score of 73 - why? what changed? you deserve to know

star appreciated, hope it earns it as we keep building

@wszubryt Thank you so much! We all love github stars!