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
Hello, I’m from Iran. Here, we face many challenges with filtered and controlled internet—especially when it comes to collecting and transmitting data.
I wanted to ask how we could collaborate on a wearable gadget that we are currently launching.
@alireza_abbasi5 Hi Alireza, the self-hosted architecture fits your constraint well (no data leaves your infrastructure), but specifics depend on which wearable APIs are reachable from your network, drop into Discord and we can dig in.
Report
Quick one: can you use this with just Apple Health data from an iPhone, no additional wearable required?
@mikolaj_sedzik Yes. Apple Health works standalone, you'll get whatever's already in HealthKit (steps, heart rate, sleep, workouts, etc., depending on what apps and devices feed it). Just needs the iOS, Flutter, or React Native SDK to pull the data, since HealthKit is on-device only.
@mikolaj_sedzik worth to mention we already have an app to sync your Apple Health - most likely will be available soon on App Store
Report
Thanks for sharing, that'll definitely unlock the industry! I've been working on Heart Rate calculations based on raw ppg data. Does your open infrastructure include the data processing for this? I figured these are highly protected IPs by the health tech companies...
You're right that PPG-to-HR algorithms are guarded IP, and Open Wearables hits the same wall: we work at the cloud API layer, and almost no provider exposes raw PPG to third parties. Apple HealthKit ships derived metrics only (SensorKit needs research entitlements), Garmin's Health API gives HR and heartBeatIntervals at best.
The exception is Polar (Verity Sense, H10) via the Polar BLE SDK, raw PPG, ECG, and accelerometer stream over BLE. If you're processing raw signals in production, BLE-direct on Polar is the cleanest path today.
Report
self-hosted + MIT for wearable infra is the real gap — most teams glue oura/whoop/garmin together and end up maintaining a janky data lake nobody owns. on the open scoring side, are the algorithms research-grade (validated hrv, recovery, etc.) or more heuristic baselines? and for LLM context: do you ship structured schemas for sleep/strain/activity so an agent can reason directly, or is shaping the context still on the developer?
Report
Is there a non-developer way to use this, or is it strictly for people who can set up their own server? Asking as someone who trains endurance athletes and wants smarter recovery data without hiring an engineer.
@nicole67 today it's developer infrastructure, but the better fit for you is a coaching platform built on top of Open Wearables (a few teams are already shipping athlete-management apps on it), DM me what you'd ideally see and I can point you in the right direction.
@therealkaczor Ha, love the energy Michal, small clarification though: the data is still in Oura's cloud, we just give you programmatic access to it via their OAuth API in a unified format. Not quite "freeing" it, but at least you can pipe it into anything you want without rebuilding the integration.
Report
@piotr_ratkowski Yes, much better than me going trough the faff of requesting data and then analyzing on the side. Good enough for me. Hope to meet you in person soon. Good luck 🙌
Report
I have checked alternatives tab here and as far as I could agree on Terra, most of those products don't seem to be in the same category. Do you know any other alternatives to Open Wearables?
@kaliszs Fair observation. The closest direct comparisons (cloud-to-cloud aggregators with unified API) are:
Terra
Rook
Sahha
Junction
Spike API
Validic (enterprise/clinical, older)
All SaaS, all closed-source, all per-user pricing. That's the category. Open-source alternatives in the same lane: honestly, none we know of at production quality. Wearipedia exists but it's research-oriented (data scraping for academic work, not a production aggregator). That gap is part of why Open Wearables exists in the first place. If you've found something we missed, would genuinely like to hear about it.
Report
Saw this shared in a Slack community I'm in and had to come check it out. The combination of open algorithms and self-hosted is a pretty specific bet on where health data is going.
Report
Open infrastructure here feels overdue— health-data integrations across Whoop/ Oura, apple health…have been such a fragmented mess for builders. What’s the long-term plan for keeping up with the constantly shifting Oauth scopes and rate-limit policies on the closed ecosystems you’re plugging into? Congrats on shipping this!
@jenson_chow1 Thanks, fair question. Honest answer: we've absorbed the maintenance burden rather than solved it. Provider changelogs, scope drift, rate-limit shifts all land on our team first, ship as patches, you pull the update. Three things make it sustainable: the team has been doing healthtech integrations for 10+ years (so we know each provider's quirks), enterprise contracts include SLA-backed commitment to maintain through breaking changes, and open source means contributors share the load (Fitbit, Ultrahuman, Oura were all community-contributed integrations). Won't pretend it's a permanent moat. It's ongoing work. The bet is that one well-maintained open layer beats every team rebuilding the same OAuth dance in isolation.
@pawel_soproniuk Technically yes: if HR or activity data is flowing, that's a proxy. The catch is latency. Most providers sync from device to cloud in batches, so you'd be looking at minutes delay, not real-time. Outbound webhooks (in development) plus the planned automation rules layer would make a "no signal in X hours, fire alert" pattern straightforward. For actual proof-of-life with strict timing guarantees, you'd want a device with continuous BLE streaming, that's a different architecture. Curious what you're building though, drop into Discord if you want to dig in.
Replies
Open Wearables
@alireza_abbasi5 Hi Alireza, the self-hosted architecture fits your constraint well (no data leaves your infrastructure), but specifics depend on which wearable APIs are reachable from your network, drop into Discord and we can dig in.
Quick one: can you use this with just Apple Health data from an iPhone, no additional wearable required?
Open Wearables
@mikolaj_sedzik Yes. Apple Health works standalone, you'll get whatever's already in HealthKit (steps, heart rate, sleep, workouts, etc., depending on what apps and devices feed it). Just needs the iOS, Flutter, or React Native SDK to pull the data, since HealthKit is on-device only.
Open Wearables
@mikolaj_sedzik worth to mention we already have an app to sync your Apple Health - most likely will be available soon on App Store
Thanks for sharing, that'll definitely unlock the industry!
I've been working on Heart Rate calculations based on raw ppg data. Does your open infrastructure include the data processing for this? I figured these are highly protected IPs by the health tech companies...
Open Wearables
You're right that PPG-to-HR algorithms are guarded IP, and Open Wearables hits the same wall: we work at the cloud API layer, and almost no provider exposes raw PPG to third parties. Apple HealthKit ships derived metrics only (SensorKit needs research entitlements), Garmin's Health API gives HR and heartBeatIntervals at best.
The exception is Polar (Verity Sense, H10) via the Polar BLE SDK, raw PPG, ECG, and accelerometer stream over BLE. If you're processing raw signals in production, BLE-direct on Polar is the cleanest path today.
self-hosted + MIT for wearable infra is the real gap — most teams glue oura/whoop/garmin together and end up maintaining a janky data lake nobody owns. on the open scoring side, are the algorithms research-grade (validated hrv, recovery, etc.) or more heuristic baselines? and for LLM context: do you ship structured schemas for sleep/strain/activity so an agent can reason directly, or is shaping the context still on the developer?
Is there a non-developer way to use this, or is it strictly for people who can set up their own server? Asking as someone who trains endurance athletes and wants smarter recovery data without hiring an engineer.
Open Wearables
@nicole67 today it's developer infrastructure, but the better fit for you is a coaching platform built on top of Open Wearables (a few teams are already shipping athlete-management apps on it), DM me what you'd ideally see and I can point you in the right direction.
YES - free my Oura data!
Open Wearables
@therealkaczor Ha, love the energy Michal, small clarification though: the data is still in Oura's cloud, we just give you programmatic access to it via their OAuth API in a unified format. Not quite "freeing" it, but at least you can pipe it into anything you want without rebuilding the integration.
@piotr_ratkowski Yes, much better than me going trough the faff of requesting data and then analyzing on the side. Good enough for me. Hope to meet you in person soon. Good luck 🙌
I have checked alternatives tab here and as far as I could agree on Terra, most of those products don't seem to be in the same category. Do you know any other alternatives to Open Wearables?
Open Wearables
@kaliszs Fair observation. The closest direct comparisons (cloud-to-cloud aggregators with unified API) are:
Terra
Rook
Sahha
Junction
Spike API
Validic (enterprise/clinical, older)
All SaaS, all closed-source, all per-user pricing. That's the category. Open-source alternatives in the same lane: honestly, none we know of at production quality. Wearipedia exists but it's research-oriented (data scraping for academic work, not a production aggregator). That gap is part of why Open Wearables exists in the first place. If you've found something we missed, would genuinely like to hear about it.
Saw this shared in a Slack community I'm in and had to come check it out. The combination of open algorithms and self-hosted is a pretty specific bet on where health data is going.
Open Wearables
@jenson_chow1 Thanks, fair question. Honest answer: we've absorbed the maintenance burden rather than solved it. Provider changelogs, scope drift, rate-limit shifts all land on our team first, ship as patches, you pull the update. Three things make it sustainable: the team has been doing healthtech integrations for 10+ years (so we know each provider's quirks), enterprise contracts include SLA-backed commitment to maintain through breaking changes, and open source means contributors share the load (Fitbit, Ultrahuman, Oura were all community-contributed integrations). Won't pretend it's a permanent moat. It's ongoing work. The bet is that one well-maintained open layer beats every team rebuilding the same OAuth dance in isolation.
Can I use it as a proof of life?
Open Wearables
@pawel_soproniuk Technically yes: if HR or activity data is flowing, that's a proxy. The catch is latency. Most providers sync from device to cloud in batches, so you'd be looking at minutes delay, not real-time. Outbound webhooks (in development) plus the planned automation rules layer would make a "no signal in X hours, fire alert" pattern straightforward. For actual proof-of-life with strict timing guarantees, you'd want a device with continuous BLE streaming, that's a different architecture. Curious what you're building though, drop into Discord if you want to dig in.