# Open Wearables: the whole site > Open-source infrastructure for wearable data: one API for the devices your users already wear. Every page of https://openwearables.io, as Markdown, in the order https://openwearables.io/llms.txt lists them. Each page opens with its address; cite that, not this file. --- Source: https://openwearables.io/ # The wearable data layer, in your own cloud [Join our Discord community](https://discord.gg/qrcfFnNE6H) Open Wearables is open-source infrastructure for wearable data. Connect the devices your users already own, keep the raw payloads, and build scores, insights and coaching on top, all inside your own cloud account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) Built by [2.6k](https://github.com/the-momentum/open-wearables) - Open source - Self-hosted - MIT license Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo What you get ## Every part of the wearable layer, complete and handled A product on wearable data needs the same groundwork: integrations, one schema, sync from the phone and the raw data underneath. Open Wearables ships it as one open-source project. [See the whole platform](https://openwearables.io/platform) ### Wearable API One standard schema across the wearables your users own. Authorisation flows, webhooks, delivery history for debugging, an admin panel for keys and connection status. [Learn more](https://openwearables.io/platform/wearable-api) ### Mobile SDKs iOS, Android, Flutter and React Native, plus the Connect App for teams without an app of their own, so you can pull Apple Health and Google Health Connect data before you build one. [Learn more](https://openwearables.io/platform/mobile-sdks) ### Raw data access Original provider payloads kept underneath the standard schema, in your own database, for debugging and for whatever the schema does not cover yet. [Learn more](https://openwearables.io/platform/raw-data) ### Health scores Health scores built with our science team, computed in your deployment. Part of Pro. [Learn more](https://openwearables.io/platform/health-scores) ### AI insights Trends across weeks, anomalies worth a second look, and the context an assistant needs to say something useful. [Learn more](https://openwearables.io/platform/ai-insights) Why it runs in your cloud ## The layer has to be yours before what you build on it can be A hosted API keeps the data, and every score computed from it, in a vendor's account. Running the layer yourself keeps it where HIPAA, GDPR and your own policy say it belongs. ### Sovereignty Your regulator, your board or your own policy says health data does not sit in a third party's cloud. ### Residency The data has to stay in a country or region you choose, and you have to prove where it is. ### Control You run the deployment under your own credentials and decide who gets access. What you build on top of Open Wearables is yours. ### Your own reasons No regulator forcing it and no security review coming. You want the data in your own account anyway. The honest comparison ## Hosted SaaS API, in-house build, or self-hosted Where each one wins. Self-host for control, for data sovereignty, for a regulator or your own reasons, and Open Wearables saves you the in-house build. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) | | Hosted SaaS API | Build in-house | Open Wearables, self-hosted | | --- | --- | --- | --- | | [01] Where the data sits | Their cloud, their regions | Yours | Yours, your account, your region | | [02] Who can reach the data | The vendor and its sub-processors | Your team | Your team, and us under a DPA you sign when we work on it | | [03] Provider credentials | Theirs. Your users connect through the vendor's provider account | Yours to obtain from each provider | Yours to obtain. The relationship is between you and the provider | | [04] Cost shape | Scales with monthly active users | Salaries and infrastructure | You pay for the infrastructure it runs on, and that is flat as you grow | | [05] Where your team's time goes | Your product, within the vendor's limits | Keeping each integration working | The intelligence layer on top | | [06] Choose this when | Speed matters more than control, no regulator, no enterprise security review | Wearable integration is your core differentiator and you have the team | A rule, a contract or a customer review says the data stays with you, or owning it matters to you | What you build on it ## The foundation for intelligent health products Open Wearables gives you clean wearable data you own. What you build on top of it is yours, and Pro adds scores and insights inside your deployment. ### Scores your users check every morning Health scores from our science team, computed inside your deployment and validated before release. ### Intelligence on data you control The models and rules you build run on data in your own cloud, under your credentials. ### An insight worth reading Written from each user's own history, so it says what they could not see alone. A paid module. ### Coaching that sounds like you The same number reads differently for an athlete and for a patient. Your tone, your rules. A paid module. Who is it for ## One platform in your cloud, three ways to run it Each path runs the same open-source core in your own cloud account. What changes is what sits on top of it, and how you start. [See all solutions](https://openwearables.io/for) ### Digital health products Ship wearable features in your own product: scores your users check every morning, coaching from each user's own history, analytics across the devices they already wear. [Learn more](https://openwearables.io/#core) A member's wellness app: this week's activity, sleep and a challenge in progress. ### Care programmes Run a monitored programme without building the software: a patient app or SDK, a care view your team opens every morning, consent on every reading. [Learn more](https://openwearables.io/for/care-providers) A care team's week: which patients are syncing and which have gone quiet. ### Hospitals and telemedicine Wearable data in the record your clinicians already open: readings written into your EHR, with a source on every value. [Learn more](https://openwearables.io/for/hospitals-telemedicine) A patient's record with wearable readings beside visits, results and medication. Case studies ## Products running on Open Wearables [See all case studies](https://openwearables.io/case-studies) Heart Monitor Consumer heart health app ### How Heart Monitor shipped wearable integrations in a week One engineer connected six providers for around 90,000 users, and every reading stays in infrastructure Heart Monitor controls. [Read the case study](https://openwearables.io/case-study/heart-monitor) Lifelong Family health app ### How Lifelong is building an AI health companion for the whole family “It let us start building the family experience instead of rebuilding wearable ingestion.” Razi Syed, Founder, Lifelong [Read the case study](https://openwearables.io/case-study/lifelong) MoveTogether Social fitness app ### How MoveTogether runs on one wearable data layer “It let a small team ship a broad device lineup and keep it current.” Sam Pullen, Founder, MoveTogether [Read the case study](https://openwearables.io/case-study/movetogether) JustGains Social workout platform ### How JustGains puts every run, ride and rep in one feed “We read the code, added it to our fork, and shipped. That is the difference open source makes.” James Greene, Founder & Engineer, JustGains [Read the case study](https://openwearables.io/case-study/justgains) ## Whatever your users wear, one schema Cloud providers and on-device sources arrive in the same shape, so supporting another device later does not change your code. [Browse integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## Start free, then build on it Run the open-source core yourself for free. Pro puts our licensed modules and our team behind your production deployment; Enterprise adds the security, scale and SLA a company at scale needs. [See pricing](https://openwearables.io/pricing) ## Core Self-hosted For teams building their first wearable features. You run the open-source platform yourself. $0 Forever - One API across cloud and on-device sources - Unified data model, raw payloads in your bucket - SDKs for iOS, Android, Flutter and React Native - Sync, backfill and webhooks - Admin panel and MCP server - Connect App for up to 5 users - Open source, MIT license, Discord support [Get started](https://openwearables.io/docs/quickstart) ## Pro Subscription For products in production. Licensed modules, with our engineers behind your deployment. From $999 a month, per deployment Everything in Core, plus The Pro modules, in your deployment - [Health scores](https://openwearables.io/platform/health-scores) - [Health agent](https://openwearables.io/platform/ai-insights) - [Medical-grade integrations](https://openwearables.io/pricing#modules) - [Observability](https://openwearables.io/pricing#modules) - [Connect App, no user limit](https://openwearables.io/platform/connect-app) - Modules run in your own cloud - Onboarding session with our team - Slack channel with our engineers [Book a demo](https://openwearables.io/book?tier=pro) ## Enterprise Annual agreement For health organisations at scale, from digital health to hospital groups. We run and secure it in your cloud, under an SLA. Custom Everything in Pro, plus - SLA support - Updates verified on your data before you upgrade - Deployed and set up for your use case, such as remote patient monitoring, then maintained - Security reviews and questionnaires answered by us - SSO, roles and audit logging - Multi-tenant and multi-region - GDPR tooling, signed DPA and BAA - Roadmap input Delivered by The team behind Open Wearables. [Talk to us](https://openwearables.io/book?tier=enterprise) A care provider, hospital or telemedicine platform? See [care providers](https://openwearables.io/for/care-providers) or [hospitals and telemedicine](https://openwearables.io/for/hospitals-telemedicine). ## Add a self-hosted wearable layer to your product Clone the repository and connect your first provider in your own account today. Or book a demo and leave with a scoped plan for your deployment. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) FAQ ## What teams ask before they add the layer ### Is it really free? Yes. The core is MIT licensed, with the full source. We charge for Pro, an Enterprise agreement, the Deployment and Integration services and custom development. ### Can we use it for HIPAA and GDPR workloads? Yes. The data goes into your cloud account and nowhere else, so access, encryption and retention stay under the controls you already run. We do not run a hosted version. ### What is actually live today? The API, the SDKs, raw data retention, webhooks and the admin panel, all in the free core. Health scores, the health agent and medical-grade integrations come with Pro, and the live versus roadmap page lists which is which. ### How many users has this been tested on? It runs in production at consumer app scale. Load testing results and the methodology behind the scores are published rather than described on a call. ### Do you have SOC 2 or ISO 27001? No. The deployment runs inside your certified environment, which is how most teams answer this in their own audit. The security page states what we do have. ### Will you sign a DPA? Yes, whenever our people can reach your deployment: under Pro support, during a Deployment or Integration service, and for as long as Enterprise runs. Where you self-host on Core, there is no processing for us to agree to, because we never touch it. A BAA comes with Enterprise, where your cloud provider and your scope support it. ### Who gets provider credentials? You do, in your name. It is real work and approval is slow with some providers, so we start it on day one of a deployment. ### We use a hosted aggregator today. How hard is migration? Usually a re-integration rather than a data migration, because you own the raw payloads going forward. It is a scoping conversation, and it is the most common shape of deal we do. ### What if we outgrow the free version? Nothing changes technically. You are already running the thing we would deploy. You add Pro when your users need scores and insights, and an Enterprise agreement when you want somebody accountable. ### Do we need a regulator to justify self-hosting? No. Teams self-host for their IP, for data residency, for a regulator, or because they want the data and the model in their own account. When time to market is what counts, Open Wearables gives you the in-house plumbing ready from day one, and Pro adds what your users see on top, so owning the layer does not slow the launch. --- Source: https://openwearables.io/about # An open platform for wearable data, built by a healthcare company. About Open Wearables runs in your own cloud account and is maintained by Momentum, a company whose whole business is health software. [Get started](https://openwearables.io/docs/quickstart) [See platform](https://openwearables.io/platform) Where this came from ## We wrote it for our own client work. Every health product we built that touched a wearable needed the same integration layer underneath. A hosted aggregator stopped being an option when a client could not send patient data to a third party. So we built the layer to run inside the client's own account. It is the same code we deploy for clients today. [Explore Momentum](https://www.themomentum.ai/) How the project is run ## Maintained on a release cadence, in public. The question worth asking about any open source infrastructure is whether anyone is still working on it. Here is what that looks like for this one. [GitHub](https://github.com/the-momentum/open-wearables) [Roadmap](https://openwearables.io/docs/roadmap) GitHub stars 2,606 Forks 450+ Contributors 60+ Releases 20+ ### A release every few weeks, not every few quarters. Provider coverage, data integrity and platform work ship on a steady rhythm rather than in occasional bursts. Every release has public notes, so you can see what changed before you upgrade. [Release notes](https://github.com/the-momentum/open-wearables/releases) ### Built in the open, including the awkward parts. Issues are public, breaking changes are announced in the release that carries them, and the roadmap is a document anyone can read. Nothing is discussed in a private tracker and announced later. [View the roadmap](https://openwearables.io/docs/roadmap) ### Contributions from outside the company. Engineers who do not work at Momentum have shipped code into this repository. That is the difference between a repository the public can read and a project the public can join. [Read the quickstart](https://openwearables.io/docs/quickstart) Working with Momentum ## Three ways teams bring us in. The code is public, so none of this is about access. It is about who does the work and who is accountable when a provider changes something. [01] Deployment ### Deployment Your engineers get a working API instead of a sprint spent on infrastructure. The credentials part is the slow one, because some providers take weeks to approve an application, so we start it on day one. - Production and staging in your cloud, in your region - Provider credentials issued in your name, validated on real accounts [See pricing](https://openwearables.io/pricing) [02] Integration ### Integration Your users link their devices without leaving your product and without a second account to manage. Everything in Deployment is part of it, so this is the option when the deadline is a release date rather than a working endpoint. - Mobile SDK live in your app, syncing in the background - Connection and consent flow inside your own interface [See pricing](https://openwearables.io/pricing) [03] Custom development ### Custom development Our engineers and health science team work on your side of the API. This is where a score gets adapted to the people who actually use your product, rather than shipped as a general-purpose number. - Health scores built and tuned for your population - Provider integrations and product features on top of the platform [See pricing](https://openwearables.io/pricing) ### Ongoing maintenance Available alongside all three, with somebody accountable for provider drift and tested upgrades. Scope and starting figures are on the pricing page, based on your infrastructure and sources rather than a seat count. Who builds it ## Engineers and scientists, not a community team. The people who commit to the repository are the people who deploy it for clients and answer questions on Discord. There is no separate open source team, no community manager and no partner network in between. [GitHub](https://github.com/the-momentum/open-wearables) [Discord](https://discord.gg/qrcfFnNE6H) Bartosz Michalak ### Bartosz Michalak Director of Engineering Leads the platform architecture. From unified data model to production deployment. Sebastian Kalisz ### Sebastian Kalisz Software Engineer Backend engineer building the FastAPI services and multi-provider OAuth integrations. Filip Begiełło ### Filip Begiełło ML Lead Architecting the health scoring layer: the sleep, recovery and activity scores. Anna Zych ### Anna Zych Neuroscience PhD Building health scores and science-backed algorithms behind the platform. JC ### Jakub Czajka Software Engineer Infrastructure and security. HIPAA-ready architecture, encryption, audit logging. Grzegorz Sztuczyński ### Grzegorz Sztuczyński Frontend Engineer Building the developer portal. Dashboards, user management, API key generation. Kacper Gąsior ### Kacper Gąsior Frontend Engineer Developer portal interface. OAuth connection flows and sync status across devices. Kamil Piekarz ### Kamil Piekarz Mobile Engineer Flutter SDK for Apple Health. Background sync, incremental data fetching, iOS Keychain auth. The company behind it ## A healthcare software company, not a startup with one product. Momentum has been building health data software since 2016. Health is the whole business rather than one vertical among several: clinical applications, AI in healthcare, EHR and FHIR integration, and infrastructure that has to pass an audit. [Security](https://openwearables.io/security) [Momentum](https://www.themomentum.ai/) ### Wearable data is something we do repeatedly, not once. Every provider names its data differently, rate limits differently and breaks differently. Knowing which ones backfill, which ones need a pull rather than a webhook, and what a value actually means before you compare it across devices is the work. Open Wearables is where that knowledge lives. ### Certified for medical device software. Momentum holds ISO 13485, the quality management standard for medical device development, and delivers under HIPAA and GDPR. When a review asks who wrote the code and under what process, that is the answer. ### Enough history to check. Over 220 projects. Financial Times FT 1000, Forbes Diamonds, and Deloitte Technology Fast 50 in Central Europe three years running. Clutch rating 4.9 out of 5. Based in Wrocław, Poland. ## Start wherever makes sense. The quickstart gets you a running instance today. If you would rather talk first, a person reads every message and routes it to sales or to an engineer depending on what you ask. [Read the quickstart](https://openwearables.io/docs/quickstart) [Book a discovery](https://openwearables.io/book) FAQ ## About the project. ### Who owns Open Wearables? The code is MIT licensed, so in every practical sense you do once you deploy it. The project is maintained by Momentum, a healthcare software company that built it for client work and continues to use it that way. ### Why would a services company give away the platform? Because the integration layer was never the part clients paid us to invent, and maintaining it privately for each of them cost more than maintaining it once in public. The work we sell sits around the platform rather than inside it. ### What happens to my deployment if Momentum stops working on this? It keeps running. The platform sits in your cloud account, built from infrastructure code in your repository, under a licence nobody can revoke. That is the case whether we are involved for a month or for five years. ### Do I have to pay you to use it? No. Clone it, deploy it, ship it, and never contact us. The documentation is written for that path rather than as a teaser. [See pricing](https://openwearables.io/pricing) ### Who is actually using it? Teams building health products on their own infrastructure, from remote monitoring to fitness and wellbeing. Several have agreed to be named, and the [customers page](https://openwearables.io/case-studies) has the detail. ### Is Momentum certified? Momentum holds ISO 13485 for medical device software development, and delivers under HIPAA and GDPR. Those certifications cover how the software is built. Where it runs is your own certified environment, which is the part the [security page](https://openwearables.io/security) covers. [For regulated buyers](https://openwearables.io/enterprise) ### Where are you based? Wrocław, Poland. The team works with clients across Europe and North America, and support hours beyond European business hours are part of what an ongoing engagement can cover. --- Source: https://openwearables.io/blog # What shipped, and how to build with it. Blog Release notes every couple of weeks, guides to the provider APIs and their quirks, and the occasional longer piece on getting health data into a shape you can work with. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) ## Posts Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. Guides · Oct 26, 2026 · 9 min read ### Moving from a hosted wearable API to Open Wearables: a migration playbook Moving from a hosted wearable API to Open Wearables is usually a re-integration rather than a data migration. This playbook walks through the decisions, the steps in order, how your users reconnect and what to tell your security team. Guides · Oct 26, 2026 · 7 min read ### Why teams move from a hosted wearable API to Open Wearables A hosted wearable API is a sensible way to start. As a product grows, the questions change: whose provider apps, whose cloud, whose schema. Here is why teams move to Open Wearables, what they get after the move, and what it asks of them. Garmin · Oct 23, 2026 · 4 min read ### Garmin Connect Developer Program reopened: what changes for your integration Garmin reopened the Connect Developer Program with Personal, Starter and Enterprise tiers. Each company now holds its own app and credentials. Here is what that means for delivery, backfill, AI use and moving an existing integration. Releases · Sep 23, 2026 · 13 min read ### Open Wearables 0.9.0: Google split into two providers, energy renamed, and a long list of API corrections Open Wearables 0.9.0 splits Google into google_health and health_connect, renames energy to active_energy, disables the Google Health API rollup that wrote duplicated rows, and fixes date bounds, filters and pagination across the API. Contains breaking changes. Releases · Sep 15, 2026 · 10 min read ### Open Wearables 0.8.0: Withings, sync history, and faster ingestion Open Wearables 0.8.0 adds Withings, database-backed sync history with two new endpoints, a 3.7x faster bulk upsert path, 5 GiB Apple Health XML uploads with MinIO parity, and four account takeover fixes. Releases · Aug 13, 2026 · 7 min read ### Open Wearables 0.7.0: Google Health API, Sensor Bio, and a faster Admin UI Open Wearables 0.7.0 adds a Google Health API integration ahead of the Fitbit Web API sunset, a new Sensor Bio provider, finer Oura sleep granularity, and Admin UI and logging improvements. Google Health API · Aug 12, 2026 · 6 min read ### Google Health API: A Practical Guide to Getting Started A step-by-step walkthrough of setting up the Google Health API: Google Cloud project, OAuth client, environment variables, and verifying your first synced data. Google Health API · Aug 12, 2026 · 6 min read ### Google Health API and Google Health Connect: What's the Difference Google runs two separate products under the same name. Health Connect lives on the device and needs an SDK. The Google Health API is a cloud REST API and needs OAuth verification and CASA at scale. Fitbit · Aug 12, 2026 · 6 min read ### Fitbit Alternatives for Developers Fitbit is shutting down its Web API in September 2026. Here is how to think about replacement data sources as a developer, not as a consumer buying a new watch. Fitbit · Aug 12, 2026 · 7 min read ### Fitbit Web API Shutdown 2026: Migration Guide Google is turning down the legacy Fitbit Web API in September 2026. Here is what still works, what never did, and how the migration to the Google Health API actually looks. Google Health API · Aug 12, 2026 · 10 min read ### Google CASA and OAuth Verification for Health Apps Moving to the Google Health API means OAuth verification and an annual CASA security assessment. Here is what it costs, how long it takes, and why self-hosting does not move the responsibility off your organization. Guides · Jul 28, 2026 · 5 min read ### How Wearable Data Flows From Device to Your API: A Complete Architecture Guide Wearable data does not go directly from device to your API. It flows through the provider cloud, then Open Wearables, then PostgreSQL, then your application. Here is what each step looks like. The platform ## Looking for the product rather than the post? ### [Platform](https://openwearables.io/platform) ### [Integrations](https://openwearables.io/integrations) ### [Pricing](https://openwearables.io/pricing) --- Source: https://openwearables.io/blog/apple-healthkit-api-what-data-you-can-access-and-how # Apple HealthKit API: what data you can access and how [All posts](https://openwearables.io/blog) [Apple Health](https://openwearables.io/blog/category/apple-health) Open Wearables Team · May 4, 2026 · 7 min read ## Key takeaways - HealthKit is an on-device framework, not a remote API: health data lives on the user's iPhone and Apple Watch, not on Apple's servers - There is no server-to-server Apple Health API; getting data to your backend requires an iOS app component that reads and uploads it - Available data includes heart rate, HRV, sleep stages, workouts, steps, SpO2, VO2 max, respiratory rate, body measurements and blood glucose - Permissions are granted per data type; users can revoke individual types without your app being notified - Open Wearables provides an iOS SDK and backend pipeline that handles the full HealthKit-to-server flow ## Introduction Apple Health sits at the center of health data on iOS. It aggregates signals from Apple Watch, third-party apps, connected devices and manual entries into a single on-device store. With over a billion active iPhone users and a large Apple Watch install base, it is often the only structured health data source available for a significant segment of any health app's user base. But HealthKit works fundamentally differently from every other wearable API. There is no REST endpoint to call. There is no OAuth flow to redirect users through. There is no server-side token to manage. Data lives on the user's device and cannot leave it without your iOS application explicitly reading it and uploading it. This has profound implications for how you architect an Apple Health integration. Everything that other providers handle server-side, including authentication, data access, and delivery, you have to build into an iOS app. For developers with strong backend experience and limited iOS experience, this is the largest conceptual hurdle in the Apple Health integration. ## What HealthKit provides HealthKit covers a broad range of health metrics organized into three categories: quantity types (numerical measurements), category types (enumerated values like sleep stages), and correlation types (grouped measurements like blood pressure). Heart and circulatory metrics include continuous heart rate from Apple Watch, resting heart rate (daily estimate based on overnight readings), walking heart rate average, and heart rate variability using the SDNN methodology. HRV from HealthKit is measured during the Breathe and Mindfulness exercises rather than during sleep passively, which distinguishes it from Whoop's or Oura's sleep-based HRV measurements. Sleep data requires some nuance. Basic sleep analysis, the coarse in-bed versus asleep categorization, is available from HealthKit without Apple Watch. Detailed sleep staging (awake, REM, core sleep and deep sleep) requires watchOS 9 or later and an Apple Watch Series 3 or newer worn during sleep. The staging quality is generally considered adequate for wellness applications though not clinical grade. Activity and workouts include step count, distance walked or run, floors climbed, active energy burned, basal energy burned, exercise minutes, stand hours and stand minutes. All Apple Watch workout types are available with associated metrics including heart rate throughout the workout, active calories, GPS data where the workout type supports it, and duration. VO2 max estimates are available from outdoor walk and run workouts. Respiratory metrics include respiratory rate measured during sleep and SpO2 (blood oxygen saturation) from Apple Watch Series 6 and later. SpO2 is measured periodically during sleep and reported as a range or point value depending on the reading type. Body measurements and metabolic data include body weight, height, BMI and body fat percentage (from compatible smart scales or manual entry), and blood glucose from continuous glucose monitors or manual entries. ## The HealthKit architecture constraint The most important thing to understand about HealthKit is that it is sandboxed to the device. Apple does not run a cloud service that aggregates HealthKit data. There is no server you can call with a user token to get their health data. The only path from HealthKit to your backend is: your iOS application reads from HealthKit on the device and uploads the data to your backend. This requires building and maintaining an iOS application with the HealthKit entitlement, implementing the permission request flow, writing query logic for each data type you need, building background sync that works even when the app is not in the foreground, and handling the upload to your backend reliably. This is meaningful engineering investment. If your product is primarily web-based or Android-first, adding Apple Health support requires an iOS app you may not otherwise need. Teams that skip iOS for initial launch often find Apple Health integration is the feature that forces them to build one. ## Permissions and privacy HealthKit's permission model is granular and user-controlled. Permissions are granted per data type, not as a blanket consent. Users see exactly which types your app wants to read in the system permission sheet. They can grant all, some, or none. They can return to Settings later and revoke individual types. Your application cannot detect which specific permissions a user has granted. HealthKit returns empty data rather than an authorization error for denied types. This prevents apps from using permission status as a proxy for health information. It also means you must build your app to handle partial permissions gracefully: never assume all requested permissions are granted, and always treat empty data for a type as potentially a permission issue rather than just an absence of data. The request itself must be initiated from a user-visible context, typically in response to a user action rather than automatically at app launch. Requesting permissions at an appropriate moment in the user flow with a clear explanation of why each data type is needed significantly improves authorization rates. ## Background sync For your app to sync HealthKit data when it is not in the foreground, you need to configure background delivery using HKObserverQuery. This registers your app to be woken by iOS when new data of a specified type arrives in HealthKit. Your app then has a limited window to process the new data before iOS suspends it again. Background delivery frequency can be configured as immediate, hourly or daily depending on the data type and how fresh you need the data to be. For most health apps, hourly or daily delivery for most types with immediate delivery only for workout events is a reasonable balance. The background wake window is short. Upload logic should be efficient: read only data newer than the last sync timestamp, serialize it, and make a single upload request to your backend. Do not attempt complex processing in the background wake handler. ## Open Wearables and Apple Health Open Wearables provides an iOS SDK that handles HealthKit permission requests, data querying, background delivery configuration and upload to your Open Wearables backend instance. On the server side, incoming Apple Health data is normalized to the same schema as Garmin, Whoop and Oura data. For multi-provider apps, this means your product code works with one data model regardless of whether the user has an Apple Watch, a Garmin watch or a Whoop band. ## Faq ### Can i access HealthKit data without building an iOS app? No. HealthKit requires an iOS app with the HealthKit entitlement. There is no web or server-side API. If your product does not have an iOS app, you cannot integrate Apple Health. ### What happens if a user revokes a HealthKit permission after granting it? HealthKit will return empty data for that type rather than an error. You will not be notified of the revocation. Build your app to detect data gaps and surface a prompt to check permissions when a user's data has been unexpectedly absent for longer than expected. ### What sleep staging quality can i expect from Apple watch? Apple's sleep staging (awake, REM, core and deep sleep) is available from watchOS 9+ and is considered adequate for wellness applications. It is not equivalent to polysomnography and should not be represented as clinical sleep analysis. ### Does HealthKit work on ipad? HealthKit is available on iPhone only. It requires a pairing between an iPhone and an Apple Watch for the richer biometric data types. iPad does not support HealthKit. ### How do i backfill historical data when a user first connects? Query HealthKit with a start date in the past. There is no API rate limit since queries run locally on the device. For very long histories with high-frequency data types like heart rate, chunk the queries by time window to manage memory usage. ## Open Wearables Open Wearables is an open-source platform that connects your application to wearable and health data providers through a single API. One normalized data model, multi-provider support in a single self-hosted deployment, no per-user fees, MIT licensed, and health intelligence built in: normalized recovery, sleep, activity and biometric data ready for your product layer. We offer custom deployment and integration support through Momentum. If your team needs help getting to production faster, we can set up and configure Open Wearables as part of a managed engagement. [Let's talk](https://www.themomentum.ai/lets-talk). [Book a demo](https://openwearables.io/book) to see how Open Wearables fits your use case. ## Apple Health integration View the full [Apple Health integration documentation](https://openwearables.io/integrations/apple-health) on Open Wearables. ## See related articles [Getting Apple Health Data Into Your Backend](https://openwearables.io/blog/getting-apple-health-data-into-your-backend) [Google Health Connect Integration: Android Health Data for Developers](https://openwearables.io/blog/google-health-connect-integration-android-health-data-for-developers) [How to Access Google Health Connect Data in Your Backend](https://openwearables.io/blog/how-to-access-google-health-connect-data-in-your-backend) ## Keep reading Apple Health · Jun 5, 2026 · 4 min read ### How to integrate Apple Health API into your backend There is no Apple Health API in the traditional sense. Learn how Open Wearables SDK-based approach gets HealthKit data into your backend with token-based auth and XML import. Apple Health · May 20, 2026 · 4 min read ### How to integrate Apple Health data into your app A practical apple health integration guide using Open Wearables. Learn the two paths: mobile SDK for real-time background sync and XML import for historical HealthKit exports. Apple Health · May 6, 2026 · 6 min read ### Getting Apple Health data into your backend There is no server-side Apple Health API. Getting data to your backend means building an iOS pipeline: permissions, observer queries, background delivery and reliable upload. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/building-a-health-app-with-whoop-api-data # Building a health app with Whoop API data [All posts](https://openwearables.io/blog) [Whoop](https://openwearables.io/blog/category/whoop) Open Wearables Team · May 6, 2026 · 6 min read ## Key takeaways - Whoop's Recovery Score, HRV trend and Sleep Performance are the most actionable signals for coaching and wellness products - HRV baseline over 30 days reveals fitness adaptation; single readings are too noisy to act on - Combining Whoop recovery data with activity providers like Strava or Garmin creates a complete training-recovery picture - The cycle-based data model means your sync architecture should be daily-cadence, not real-time - Open Wearables normalizes Whoop data alongside eight other providers into a single unified schema ## Introduction Getting data out of the Whoop API is one problem. Building something users actually find valuable is a different one. Whoop's metrics are well-designed for athlete coaching contexts, but they require some domain knowledge to use correctly in a product. Recovery Score is not just a number to display: it is a composite signal with contributing factors that tell different stories depending on which component is dragging the score down. HRV is not useful as a daily point value; it becomes meaningful when tracked against a personal baseline over weeks. Strain needs context from the preceding recovery to mean anything about training readiness. This guide covers how to use Whoop's data effectively in a health or coaching product: which signals matter, how to structure your data layer, how to compute derived insights that go beyond raw number display, and where Open Wearables fits if you are building across multiple device providers. ## Which Whoop metrics actually matter Not all of Whoop's data points are equally useful in a product context. Recovery Score, HRV and Sleep Performance are the core signals. Most meaningful product features are built on combinations of these three. Recovery Score is the primary daily signal. Green, yellow and red zone classification maps directly to training load recommendations without requiring users to interpret raw numbers. For a coaching app, Recovery Score is the headline: the first thing a user sees when they open the app in the morning. But it is most valuable when paired with an explanation of what drove it. HRV is the most clinically interesting signal Whoop provides. It is also the most misused. A single HRV reading on a given morning tells you almost nothing without context. What matters is the relationship between today's reading and the user's personal 30-day baseline. A user with a baseline of 65ms who wakes up at 50ms is in a meaningfully different state than a user with a baseline of 45ms who wakes up at 50ms. Building HRV features means building baseline tracking, not just displaying today's value. Sleep Performance Score is useful both as a daily signal and as a leading indicator for the next day's recovery. Poor sleep predicts lower recovery. Building features that surface this relationship, such as showing users how last night's sleep performance correlates with today's recovery trend, gives users insight they cannot easily extract themselves from the raw numbers. Day Strain is useful for training load management over time. Accumulated strain over a rolling 7-day window is a better indicator of training load than any single day. Flagging when weekly load significantly exceeds the user's historical average is a straightforward feature that most users find genuinely useful. ## HRV baseline and trend analysis HRV is the signal where most apps underdeliver. Displaying today's HRV value next to a generic reference range is not useful because HRV varies enormously between individuals. A reading of 40ms may be excellent for one person and poor for another depending on age, fitness level and genetics. The right approach is personalized baseline tracking. Calculate a 30-day rolling average for each user. Express today's reading as a percentage deviation from that baseline. Flag deviations beyond a threshold, typically 10-15% in either direction, as notable. An HRV reading 20% above baseline suggests the user is well-recovered and potentially primed for a high-intensity session. A reading 20% below baseline warrants a rest day recommendation regardless of what the Recovery Score shows, because HRV often leads recovery scoring by a day. For users who have been connected for less than 30 days, communicate that your insights are preliminary and will improve as more baseline data accumulates. Do not try to extrapolate a meaningful baseline from fewer than 7 readings. ## Combining Whoop with other providers Whoop excels at recovery monitoring but has deliberate gaps. No GPS means no route or training load data from Whoop itself. No step count means no passive daily activity. For a complete picture of a user's training and health, Whoop works best as one provider among several. The most valuable pairing is Whoop recovery data with activity data from a GPS-capable provider like Strava or Garmin. Whoop tells you the physiological state the user started a workout in. Strava or Garmin tells you the actual workout that was performed. Combining these lets you show: this user ran a hard 15km tempo run on a yellow recovery day, and the following morning their recovery dropped to red. Over time, patterns like this teach users about their individual recovery curves and appropriate training loads. Whoop plus Oura is useful for power users who wear both. Both devices measure sleep and HRV but with different methodologies and sensors. They agree most of the time but diverge on certain nights. Showing users when the two devices agree or disagree, and what drove the divergence when they do, is a feature that genuinely sophisticated health trackers find valuable. It also builds trust in your product's analytical capability. ## Data architecture for Whoop Whoop's cycle-based model suggests a specific data architecture. The unit of analysis is the day, structured as a daily health summary that aggregates the recovery, sleep and strain cycles for that calendar date. Store daily summaries in your database rather than raw cycle objects. A daily summary for a Whoop user includes: recovery score, contributing factor scores (HRV balance, RHR, sleep quality), HRV value and deviation from baseline, resting heart rate, sleep performance score, sleep duration and stage breakdown, and day strain. When the user also has Strava or Garmin data for the same day, the summary can include training load and activity type. This architecture scales well across providers. An Oura user has a daily summary too, with readiness score, sleep score and HRV. The field names map differently, but the structure is the same. A user who switches from Whoop to Oura or uses both keeps the same daily summary structure in your database, making historical trend analysis provider-agnostic. ## Open Wearables Open Wearables is an open-source platform that connects your application to wearable and health data providers through a single API. One normalized data model, multi-provider support in a single self-hosted deployment, no per-user fees, MIT licensed, and health intelligence built in: normalized recovery, sleep, activity and biometric data ready for your product layer. We offer custom deployment and integration support through Momentum. If your team needs help getting to production faster, we can set up and configure Open Wearables as part of a managed engagement. [Let's talk](https://www.themomentum.ai/lets-talk). [Book a demo](https://openwearables.io/book) to see how Open Wearables fits your use case. ## Whoop integration View the full [Whoop integration documentation](https://openwearables.io/integrations/whoop) on Open Wearables. ## See related articles [Whoop API: Recovery, Strain and Sleep Data for Developers](https://openwearables.io/blog/whoop-api-recovery-strain-sleep-data-for-developers) [Oura API: Accessing Ring Data, Sleep, HRV and Readiness](https://openwearables.io/blog/oura-api-accessing-ring-data-sleep-hrv-readiness) [How to Use Oura Ring Data in Your App](https://openwearables.io/blog/how-to-use-oura-ring-data-in-your-app) ## Keep reading Whoop · Jun 2, 2026 · 4 min read ### How to integrate Whoop API data into your health app The Whoop API requires a paid membership and OAuth setup. Learn how Open Wearables handles authentication, polling, and normalization so you query one endpoint. Whoop · May 6, 2026 · 9 min read ### Whoop API: recovery, strain and sleep data for developers The Whoop API exposes Recovery Score, HRV, Strain and Sleep Performance through a cycle-based model. Here's how it works in practice and what building with it actually requires. Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/building-with-ultrahuman-data-recovery-sleep-glucose # Building with Ultrahuman data: recovery, sleep and glucose [All posts](https://openwearables.io/blog) [Ultrahuman](https://openwearables.io/blog/category/ultrahuman) Open Wearables Team · May 5, 2026 · 6 min read ## Introduction Ultrahuman's data is interesting not because any single metric is uniquely novel, but because of the combination: ring-quality sleep and recovery biometrics alongside optional continuous glucose monitoring in a single API. No other consumer wearable integration provides both streams. Building features that use them together opens a category of health insights that is not possible with any other platform. This guide covers how to build productively with Ultrahuman data. It addresses the OAuth and token management specifics, how to work with glucose time series data, how to build recovery coaching features on top of the ring biometrics, how to construct the glucose-sleep correlation features that make Ultrahuman distinctively valuable, and how to structure your architecture for users who may or may not have the CGM patch active. ## OAuth and token management Ultrahuman uses OAuth 2.0 with the authorization code flow and rotating refresh tokens. The rotating refresh token pattern means every time you exchange a refresh token for a new access token, Ultrahuman returns a new refresh token in the response. Your previous refresh token is immediately invalidated. This creates a race condition risk in distributed systems where multiple processes might attempt to refresh the same token simultaneously. Implement a per-user mutex or advisory lock around token refresh operations so only one process refreshes a given user's token at a time. Store the new refresh token atomically with the new access token. If a token exchange returns a new refresh token but your storage write fails, you have lost the valid refresh token and the user must re-authenticate. A practical implementation stores access token, refresh token, access token expiry timestamp and a last-refreshed timestamp per user. On each API call, check whether the access token is within five minutes of expiry and refresh proactively rather than waiting for a 401 response. Log all token refresh operations for debugging. ## Building recovery coaching features Ultrahuman's Recovery Score combines HRV, resting heart rate and sleep quality into a 0-100 score. For coaching applications, the score itself is less useful than the components. A user with a low Recovery Score caused by poor HRV needs different guidance than a user with the same score caused by short sleep duration. Fetch the component data alongside the composite score: HRV (rMSSD), resting heart rate and sleep quality score separately. Build your coaching logic on the components rather than the composite. An HRV value more than one standard deviation below the user's 30-day personal HRV baseline suggests nervous system stress. A resting heart rate elevated more than five beats per minute above the user's resting baseline suggests physiological strain. Skin temperature deviation adds a third signal. Combine HRV deviation, resting heart rate deviation and temperature deviation into a three-dimensional recovery picture. When all three are in the expected direction, your training or lifestyle recommendation can be confident. When only one or two are off, the guidance should be more cautious and conditional. Establish personal baselines before surfacing recovery-based recommendations. A new user's first week of data is insufficient for reliable personal baselines. Use a soft launch for coaching features: during the first 14 days, show users their raw data with minimal coaching interpretation. After 14 days of consistent sleep data, begin showing trend-based guidance. After 30 days, personal baselines for HRV and resting heart rate are sufficiently stable for confident recommendations. ## Working with glucose time series CGM data from the Ultrahuman M1 patch arrives as a time series with readings at approximately five-minute intervals. Each reading has a timestamp (UTC) and a glucose value in either mg/dL or mmol/L depending on the user's account locale setting. Standardize to one unit in your storage layer and convert on display as needed. Common gaps in CGM time series occur when the patch temporarily loses sensor contact, the user's phone is out of range for sync, or during patch change transitions. Fill gaps shorter than 20 minutes with linear interpolation when calculating variability metrics. Mark longer gaps as missing in your data model rather than interpolating. Key glucose metrics to compute from the time series: mean glucose for a defined period (day, night, post-meal window), time in range (percentage of readings within 70-140 mg/dL is the standard healthy range for non-diabetic adults), glucose variability measured as coefficient of variation (standard deviation divided by mean), and meal response peaks (local maxima in the glucose time series that occur 30-90 minutes after a tagged meal). Ultrahuman provides a metabolic score in their API that abstracts some of this analysis. However, if you are building your own metabolic health features, working with the raw time series gives you more flexibility in how you define and surface metabolic insights. ## Glucose-sleep correlation features The most distinctive product opportunity in the Ultrahuman dataset is correlating overnight glucose patterns with sleep quality metrics from the ring. Research suggests that nocturnal glucose variability (frequent dips and rises during the night) is associated with fragmented sleep, lower HRV and worse recovery scores the following morning. To build this feature, define an overnight window for each date (for example, 10pm to 6am based on the user's typical sleep timing, or derived from the actual sleep start and end times in the ring data). Compute mean glucose, glucose variability and any nocturnal dip events (readings below 70 mg/dL) within the overnight window. Compare these metrics against the same night's Recovery Score, HRV and sleep stages from the ring. Over 14-30 days of data, you can identify whether a given user shows the glucose-sleep correlation pattern. Not all users will. Those who do have a medically and practically significant insight available: improving their nocturnal glucose stability (typically through adjusting evening meal timing and composition) may improve their sleep quality and recovery. Surface this insight carefully. You are not making a medical claim; you are showing the user their own data patterns. A statement like on nights when your overnight glucose was more stable, your Recovery Score averaged 12 points higher is a data observation, not a diagnosis. This framing is both accurate and appropriate for a consumer health app. ## Architecture for cgm-optional users Not all Ultrahuman users have active CGM data. The ring works independently; the CGM is a separate purchase. Your architecture must handle three states: user has ring data only (no CGM history), user has ring data and historical CGM data from a previous patch (data available but not current), and user has ring data and active CGM data (both streams available and current). Design your feature set accordingly. Core recovery features based on ring data are always available. Glucose features are gated on the presence of active CGM data. Correlation features require at least 14 days of overlapping ring and glucose data. Use progressive disclosure in your UI: show core features to all users and reveal glucose-dependent features only when the data is available. ## Open Wearables Open Wearables is an open-source platform that connects your application to wearable and health data providers through a single API. One normalized data model, multi-provider support in a single self-hosted deployment, no per-user fees, MIT licensed, and health intelligence built in: normalized recovery, sleep, activity and biometric data ready for your product layer. We offer custom deployment and integration support through Momentum. If your team needs help getting to production faster, we can set up and configure Open Wearables as part of a managed engagement. [Let's talk](https://www.themomentum.ai/lets-talk). [Book a demo](https://openwearables.io/book) to see how Open Wearables fits your use case. ## Ultrahuman integration View the full [Ultrahuman integration documentation](https://openwearables.io/integrations/ultrahuman) on Open Wearables. ## See related articles [Ultrahuman API: Ring Data, CGM and Recovery Metrics](https://openwearables.io/blog/ultrahuman-api-ring-data-cgm-recovery-metrics) [Oura API: Accessing Ring Data, Sleep, HRV and Readiness](https://openwearables.io/blog/oura-api-accessing-ring-data-sleep-hrv-readiness) [Building a Health App With Whoop API Data](https://openwearables.io/blog/building-a-health-app-with-whoop-api-data) ## Keep reading Ultrahuman · May 5, 2026 · 6 min read ### Ultrahuman API: ring data, CGM and recovery metrics Ultrahuman Ring AIR provides Recovery Score, Sleep Score, HRV, skin temperature and movement data. Its CGM integration adds continuous blood glucose alongside recovery metrics. Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. Guides · Oct 26, 2026 · 9 min read ### Moving from a hosted wearable API to Open Wearables: a migration playbook Moving from a hosted wearable API to Open Wearables is usually a re-integration rather than a data migration. This playbook walks through the decisions, the steps in order, how your users reconnect and what to tell your security team. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/category/apple-health # Apple Health Blog Every post filed under Apple Health, newest first. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) ## Posts Apple Health · Jun 5, 2026 · 4 min read ### How to integrate Apple Health API into your backend There is no Apple Health API in the traditional sense. Learn how Open Wearables SDK-based approach gets HealthKit data into your backend with token-based auth and XML import. Apple Health · May 20, 2026 · 4 min read ### How to integrate Apple Health data into your app A practical apple health integration guide using Open Wearables. Learn the two paths: mobile SDK for real-time background sync and XML import for historical HealthKit exports. Apple Health · May 6, 2026 · 6 min read ### Getting Apple Health data into your backend There is no server-side Apple Health API. Getting data to your backend means building an iOS pipeline: permissions, observer queries, background delivery and reliable upload. Apple Health · May 4, 2026 · 7 min read ### Apple HealthKit API: what data you can access and how HealthKit is an on-device framework, not a remote API. There is no server-side Apple Health endpoint. Here's what's available, how permissions work, and what building an integration really requires. The platform ## Looking for the product rather than the post? ### [Platform](https://openwearables.io/platform) ### [Integrations](https://openwearables.io/integrations) ### [Pricing](https://openwearables.io/pricing) --- Source: https://openwearables.io/blog/category/fitbit # Fitbit Blog Every post filed under Fitbit, newest first. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) ## Posts Fitbit · Aug 12, 2026 · 6 min read ### Fitbit Alternatives for Developers Fitbit is shutting down its Web API in September 2026. Here is how to think about replacement data sources as a developer, not as a consumer buying a new watch. Fitbit · Aug 12, 2026 · 7 min read ### Fitbit Web API Shutdown 2026: Migration Guide Google is turning down the legacy Fitbit Web API in September 2026. Here is what still works, what never did, and how the migration to the Google Health API actually looks. The platform ## Looking for the product rather than the post? ### [Platform](https://openwearables.io/platform) ### [Integrations](https://openwearables.io/integrations) ### [Pricing](https://openwearables.io/pricing) --- Source: https://openwearables.io/blog/category/garmin # Garmin Blog Every post filed under Garmin, newest first. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) ## Posts Garmin · Oct 23, 2026 · 4 min read ### Garmin Connect Developer Program reopened: what changes for your integration Garmin reopened the Connect Developer Program with Personal, Starter and Enterprise tiers. Each company now holds its own app and credentials. Here is what that means for delivery, backfill, AI use and moving an existing integration. Garmin · Jul 21, 2026 · 8 min read ### Garmin Connect API: What You Can Fetch and How to Do It Faster The Garmin API gives you access to workouts, health metrics, and device data. Here is what you can retrieve, how the OAuth 1.0 flow works, and when it makes sense to use a ready-made integration layer instead of building from scratch. Garmin · May 6, 2026 · 11 min read ### Garmin Connect API: developer guide for activities and health metrics Garmin's Health API uses push-based delivery and OAuth 1.0a, covering 100+ sport types, GPS, Body Battery, HRV, sleep and more. Here's what building with it actually requires. Garmin · May 6, 2026 · 7 min read ### Garmin API push notifications: how callback sync works Garmin's Health API pushes data to your callback URLs when users sync their devices. Here's how the system works end-to-end and what reliable implementation requires. The platform ## Looking for the product rather than the post? ### [Platform](https://openwearables.io/platform) ### [Integrations](https://openwearables.io/integrations) ### [Pricing](https://openwearables.io/pricing) --- Source: https://openwearables.io/blog/category/google-health-api # Google Health API Blog Every post filed under Google Health API, newest first. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) ## Posts Google Health API · Aug 12, 2026 · 6 min read ### Google Health API: A Practical Guide to Getting Started A step-by-step walkthrough of setting up the Google Health API: Google Cloud project, OAuth client, environment variables, and verifying your first synced data. Google Health API · Aug 12, 2026 · 6 min read ### Google Health API and Google Health Connect: What's the Difference Google runs two separate products under the same name. Health Connect lives on the device and needs an SDK. The Google Health API is a cloud REST API and needs OAuth verification and CASA at scale. Google Health API · Aug 12, 2026 · 10 min read ### Google CASA and OAuth Verification for Health Apps Moving to the Google Health API means OAuth verification and an annual CASA security assessment. Here is what it costs, how long it takes, and why self-hosting does not move the responsibility off your organization. The platform ## Looking for the product rather than the post? ### [Platform](https://openwearables.io/platform) ### [Integrations](https://openwearables.io/integrations) ### [Pricing](https://openwearables.io/pricing) --- Source: https://openwearables.io/blog/category/google-health-connect # Google Health Connect Blog Every post filed under Google Health Connect, newest first. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) ## Posts Google Health Connect · Jun 7, 2026 · 4 min read ### Google Health Connect integration for Android developers Google Health Connect is not a cloud API. It requires on-device Android SDK integration. Learn how Open Wearables handles the full Health Connect lifecycle. Google Health Connect · May 6, 2026 · 7 min read ### Google Health Connect integration: Android health data for developers Google Health Connect is Android's on-device health data hub, aggregating data from Wear OS, Galaxy Watch, Fitbit, Garmin and third-party apps. Here's how to build with it. Google Health Connect · May 6, 2026 · 7 min read ### How to access Google Health Connect data in your backend There is no Google server-side API for Health Connect. Your Android app must read data on device and upload it. Here's the complete pipeline from setup to production. The platform ## Looking for the product rather than the post? ### [Platform](https://openwearables.io/platform) ### [Integrations](https://openwearables.io/integrations) ### [Pricing](https://openwearables.io/pricing) --- Source: https://openwearables.io/blog/category/guides # Guides Blog Every post filed under Guides, newest first. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) ## Posts Guides · Oct 26, 2026 · 9 min read ### Moving from a hosted wearable API to Open Wearables: a migration playbook Moving from a hosted wearable API to Open Wearables is usually a re-integration rather than a data migration. This playbook walks through the decisions, the steps in order, how your users reconnect and what to tell your security team. Guides · Oct 26, 2026 · 7 min read ### Why teams move from a hosted wearable API to Open Wearables A hosted wearable API is a sensible way to start. As a product grows, the questions change: whose provider apps, whose cloud, whose schema. Here is why teams move to Open Wearables, what they get after the move, and what it asks of them. Guides · Jul 28, 2026 · 5 min read ### How Wearable Data Flows From Device to Your API: A Complete Architecture Guide Wearable data does not go directly from device to your API. It flows through the provider cloud, then Open Wearables, then PostgreSQL, then your application. Here is what each step looks like. Guides · Jul 22, 2026 · 5 min read ### How to Build an AI Agent That Reasons Over Health Data An AI agent that reasons over health data is different from one that reads it. Here is how the Open Wearables MCP server works and how to build the reasoning layer on top of it. Guides · Jul 22, 2026 · 5 min read ### How to Add Wearable Data to a Corporate Wellness Platform Corporate wellness platforms need wearable data from multiple providers without requiring employees to switch devices. Here is what Open Wearables handles and what your application builds on top. Guides · Jul 22, 2026 · 5 min read ### Wearable Data Deduplication: How to Handle Users With Multiple Devices Users with multiple wearables produce overlapping data. Here is how Open Wearables handles within-provider deduplication automatically and how the priority system resolves cross-provider conflicts. Guides · Jul 22, 2026 · 6 min read ### How to Structure Health Data for AI: What Your LLM Actually Needs Raw wearable data breaks LLMs. Consistent structure does not. Here is what the Open Wearables data model looks like and how to decide what to pass to your model for each type of health question. Guides · Jul 22, 2026 · 5 min read ### What Is an Open Source Wearable API and When Does It Make Sense An open source wearable API gives you the integration code itself, not just an endpoint. Here is what that means in practice, what Open Wearables provides, and when this approach fits your product. Guides · Jul 22, 2026 · 5 min read ### How to Add Wearable Support to an Existing Health App in Days, Not Months Adding wearable support to an existing app does not require rebuilding your data layer. Open Wearables sits alongside your backend. Here is what the integration looks like and how long each step actually takes. Guides · Jul 21, 2026 · 6 min read ### How to Handle OAuth, Webhooks, and Token Refresh Across Multiple Wearable Providers Every wearable provider implements OAuth differently, delivers data through a different mechanism, and has different token lifecycle rules. Here is how Open Wearables abstracts all of it and what your application still needs to handle. Guides · Jul 21, 2026 · 8 min read ### How to Give Your LLM Access to Wearable Data Most LLM integrations with health data dump raw numbers into context and hope for the best. Here is how to use the Model Context Protocol with Open Wearables so your LLM queries the right data and reasons about it. Guides · Jul 21, 2026 · 4 min read ### How to Build a HIPAA-Compliant Health App That Uses Wearable Data HIPAA compliance starts with where data lives. Open Wearables is self-hosted: wearable data stays on your infrastructure. Here is what the platform provides and what you need to configure yourself. The platform ## Looking for the product rather than the post? ### [Platform](https://openwearables.io/platform) ### [Integrations](https://openwearables.io/integrations) ### [Pricing](https://openwearables.io/pricing) --- Source: https://openwearables.io/blog/category/guides/page/2 # Guides Blog Every post filed under Guides, newest first. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) ## Posts Guides · Jul 15, 2026 · 8 min read ### What wearable app development actually looks like in 2026 Most tutorials about wearable app development skip the hard parts. This article shows where the complexity actually lives: OAuth flows, token refresh, normalization, webhook-only providers. And what you can take off the shelf with Open Wearables. Guides · Jul 15, 2026 · 7 min read ### The wearable app development checklist: what you actually need to build (and what you don't) Scoping a wearable feature is harder than it looks. This checklist maps what you actually need to build, what Open Wearables handles for you, and what you will still own no matter what. Guides · Jun 1, 2026 · 4 min read ### Strava API integration guide for health and fitness apps The Strava API requires OAuth, token refresh, and normalization. Learn how Open Wearables abstracts all of that into one sync endpoint alongside other providers. Guides · May 27, 2026 · 6 min read ### How to build an AI health coaching app with wearable data Learn how to build an AI health coaching app that turns wearable health scores into personalized coaching responses using Open Wearables and its MCP server. Guides · May 24, 2026 · 6 min read ### How to normalize wearable data across providers If you are looking for a Terra API alternative, Open Wearables normalizes data from all major wearable providers into a unified schema. Self-hosted, open source, no per-user fees. Guides · May 21, 2026 · 3 min read ### How to sync wearable data from multiple devices Garmin API uses webhook-only delivery, not REST polling. Learn how Open Wearables handles Garmin alongside Polar, Suunto, Whoop, and Apple Health in a unified normalized API. Guides · May 14, 2026 · 7 min read ### Wearable API integration: comparing SaaS, custom build, and open source A technical founder’s guide to choosing a wearable health data API. Compare SaaS vendors, in-house builds, and self-hosted open source by cost, compliance, and engineering effort. Guides · May 14, 2026 · 4 min read ### How to customize Open Wearables for your product Open Wearables is built to be adapted. Learn how to customize health scoring, add provider integrations, and deploy enterprise-grade infrastructure with Momentum's engineering team. The platform ## Looking for the product rather than the post? ### [Platform](https://openwearables.io/platform) ### [Integrations](https://openwearables.io/integrations) ### [Pricing](https://openwearables.io/pricing) --- Source: https://openwearables.io/blog/category/oura # Oura Blog Every post filed under Oura, newest first. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) ## Posts Oura · May 3, 2026 · 10 min read ### Oura API: accessing ring data, sleep, HRV and readiness The Oura Ring API provides Sleep Score, Readiness Score, HRV, body temperature deviation and SpO2 through a clean REST interface. Here's what it offers and how to build with it. Oura · May 3, 2026 · 5 min read ### How to use Oura ring data in your app Readiness Score, HRV trends and body temperature deviation are Oura's most actionable signals. Here's how to use them effectively in a coaching or wellness product. The platform ## Looking for the product rather than the post? ### [Platform](https://openwearables.io/platform) ### [Integrations](https://openwearables.io/integrations) ### [Pricing](https://openwearables.io/pricing) --- Source: https://openwearables.io/blog/category/polar # Polar Blog Every post filed under Polar, newest first. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) ## Posts Polar · May 30, 2026 · 5 min read ### How to integrate Polar data into your health app The Polar API (AccessLink) requires OAuth, token management, and polling. Open Wearables abstracts all of that into a single sync endpoint with normalized output. Polar · May 5, 2026 · 8 min read ### Polar API: training, HRV and Nightly Recharge data Polar AccessLink API provides training sessions for 100+ sport types, HRV4T nightly HRV tracking, Nightly Recharge, sleep staging and VO2 max. Here's what building with it requires. Polar · May 3, 2026 · 7 min read ### How to access Polar watch data in your health app Polar's cardio versus muscle load split and ANS Charge from Nightly Recharge enable coaching features that most wearable APIs cannot support. Here's how to use them effectively. The platform ## Looking for the product rather than the post? ### [Platform](https://openwearables.io/platform) ### [Integrations](https://openwearables.io/integrations) ### [Pricing](https://openwearables.io/pricing) --- Source: https://openwearables.io/blog/category/releases # Releases Blog Every post filed under Releases, newest first. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) ## Posts Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. Releases · Sep 23, 2026 · 13 min read ### Open Wearables 0.9.0: Google split into two providers, energy renamed, and a long list of API corrections Open Wearables 0.9.0 splits Google into google_health and health_connect, renames energy to active_energy, disables the Google Health API rollup that wrote duplicated rows, and fixes date bounds, filters and pagination across the API. Contains breaking changes. Releases · Sep 15, 2026 · 10 min read ### Open Wearables 0.8.0: Withings, sync history, and faster ingestion Open Wearables 0.8.0 adds Withings, database-backed sync history with two new endpoints, a 3.7x faster bulk upsert path, 5 GiB Apple Health XML uploads with MinIO parity, and four account takeover fixes. Releases · Aug 13, 2026 · 7 min read ### Open Wearables 0.7.0: Google Health API, Sensor Bio, and a faster Admin UI Open Wearables 0.7.0 adds a Google Health API integration ahead of the Fitbit Web API sunset, a new Sensor Bio provider, finer Oura sleep granularity, and Admin UI and logging improvements. Releases · Jul 16, 2026 · 5 min read ### Open Wearables 0.6.3: nap detection and HTTP logs middleware Open Wearables 0.6.3 adds nap detection for Apple and Oura, structured HTTP logs, an outgoing webhooks flag, and Strava workout samples. Releases · Jun 30, 2026 · 5 min read ### Open Wearables 0.6.2: data integrity for multi-source health apps Open Wearables 0.6.2 fixes step and energy double-counting for Garmin and Oura, retrieves active minutes natively from four providers, adds sleep session deduplication to the events endpoint, and resolves a Garmin respiratory rate storage bug. Releases · Jun 23, 2026 · 3 min read ### Open Wearables 0.6.1: Data coverage & observability Open Wearables 0.6.1 adds a Data Coverage tab to the admin panel, introduces PULL_SYNC_LOOKBACK as a safeguard for periodic pull syncs, ships observability and logging improvements, and includes provider-specific bug fixes. Releases · Jun 13, 2026 · 4 min read ### Open Wearables 0.6.0: Women's Health & FIT Files Open Wearables 0.6.0 adds Garmin menstrual cycle tracking, a FIT file parser with second-by-second workout data, Oura reliability fixes, and multi-account sync support. No breaking changes to the API. Releases · May 20, 2026 · 3 min read ### Open Wearables 0.5.2: Polar Webhooks, Sport Type Expansion, and HRV Score Integrity Open Wearables 0.5.2 adds Polar webhook support, expands workout type mappings, new Garmin fields, and stricter HRV scoring. Releases · May 8, 2026 · 2 min read ### Open Wearables 0.5.1: Oura & Strava Webhooks, Live Sync Status, RMSSD HRV Open Wearables 0.5.1 ships webhook support for Oura and Strava, live sync status via SSE, RMSSD HRV in Body Summary, and a redesigned Admin Panel dashboard. No breaking changes. Releases · May 7, 2026 · 2 min read ### Open Wearables Release 0.5.0: Webhooks, Sleep Fixes, MCP Updates Open Wearables 0.5.0 ships complete webhook infrastructure, incoming webhooks for Whoop and Suunto, sleep calculation fixes, HRV-CV scoring, and a new MCP Server time-series tool. Releases · Apr 15, 2026 · 1 min read ### Open Wearables Release 0.4.3: Health Scores, Webhooks Open Wearables 0.4.3 ships Sleep Score and Resilience Score with open algorithms. First release where the platform produces scored health output. Outgoing webhooks added. The platform ## Looking for the product rather than the post? ### [Platform](https://openwearables.io/platform) ### [Integrations](https://openwearables.io/integrations) ### [Pricing](https://openwearables.io/pricing) --- Source: https://openwearables.io/blog/category/releases/page/2 # Releases Blog Every post filed under Releases, newest first. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) ## Posts Releases · Mar 23, 2026 · 1 min read ### Open Wearables Release 0.4: Oura Ring, React Native SDK Open Wearables 0.4 adds Oura Ring support contributed by a community member, React Native SDK, raw payload storage to S3, and production infrastructure improvements. Releases · Mar 9, 2026 · 1 min read ### Open Wearables Release 0.3: Android, Google Health Connect, Samsung Health Open Wearables 0.3 adds Google Health Connect and Samsung Health, completing Android platform support. Includes one-click Railway deployment and a Garmin reliability overhaul. Releases · Feb 16, 2026 · 1 min read ### Open Wearables Release 0.3 Beta: Strava, Apple Health SDK, Data Source Priority Open Wearables 0.3 beta adds Strava as a provider, matures the Apple Health SDK with invitation code onboarding and refresh tokens, and introduces configurable data source priority. Releases · Jan 23, 2026 · 1 min read ### Open Wearables Release 0.3 Alpha: Flutter SDK, MCP Server Open Wearables 0.3 alpha ships the first mobile SDK for Flutter with Apple Health integration and an MCP Server connecting wearable data to LLMs. Releases · Jan 12, 2026 · 1 min read ### Open Wearables Release 0.2.2: Production Stability, Extended Provider Support Open Wearables 0.2.2 fixes critical sync issues across Apple Health, Whoop, and Suunto. Adds sleep summaries, AWS XML import guide, and API performance improvements. Releases · Jan 8, 2026 · 1 min read ### Open Wearables Release 0.2.1: Whoop, Mobile SDK Authentication Open Wearables 0.2.1 adds Whoop as the fourth provider, user-scoped SDK tokens for mobile apps, and a sleep summaries endpoint. Releases · Dec 22, 2025 · 1 min read ### Open Wearables Release 0.2: Sleep, Workouts, Timeseries Open Wearables 0.2 adds Sleep, Workout, and Timeseries endpoints with 59 data types and 870 tests. Releases · Dec 10, 2025 · 1 min read ### Open Wearables Release 0.1: Workout Data, OAuth, Developer Portal First public release of Open Wearables. Workout data from Garmin, Suunto, and Polar, unified data model, built-in OAuth flows, and a developer portal. The platform ## Looking for the product rather than the post? ### [Platform](https://openwearables.io/platform) ### [Integrations](https://openwearables.io/integrations) ### [Pricing](https://openwearables.io/pricing) --- Source: https://openwearables.io/blog/category/samsung-health # Samsung Health Blog Every post filed under Samsung Health, newest first. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) ## Posts Samsung Health · Jun 6, 2026 · 4 min read ### Samsung Health API integration guide for Android developers Samsung Health API is not a cloud API. It requires an on-device SDK. Learn how Open Wearables Android SDK handles permissions, background sync, and normalization. Samsung Health · May 6, 2026 · 6 min read ### How to connect Samsung Health to your app The Samsung Health integration pipeline covers developer program application, OAuth 2.0, token management, data querying and normalization before you ship a single product feature. Samsung Health · May 6, 2026 · 5 min read ### Samsung Health API: Galaxy Watch data for developers Samsung Health Platform provides server-side API access to Galaxy Watch data including heart rate, sleep stages, workouts, stress score, SpO2, HRV and body composition. The platform ## Looking for the product rather than the post? ### [Platform](https://openwearables.io/platform) ### [Integrations](https://openwearables.io/integrations) ### [Pricing](https://openwearables.io/pricing) --- Source: https://openwearables.io/blog/category/strava # Strava Blog Every post filed under Strava, newest first. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) ## Posts Strava · May 6, 2026 · 11 min read ### Strava API 2026: developer guide to activities, heart rate and GPS data A practical guide to connecting Strava's API in production: OAuth token refresh, rate limits, webhooks, and how to normalize activity data across multiple providers. Strava · May 4, 2026 · 5 min read ### How to integrate Strava without building OAuth from scratch Building a production Strava integration means writing OAuth, token refresh, webhooks and rate limit logic before shipping any product. Here's what that actually takes, and a simpler path. The platform ## Looking for the product rather than the post? ### [Platform](https://openwearables.io/platform) ### [Integrations](https://openwearables.io/integrations) ### [Pricing](https://openwearables.io/pricing) --- Source: https://openwearables.io/blog/category/suunto # Suunto Blog Every post filed under Suunto, newest first. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) ## Posts Suunto · Jun 2, 2026 · 6 min read ### How to integrate Suunto data into your health app The Suunto API provides workouts and 24/7 continuous monitoring. Open Wearables handles OAuth, polling, and normalization so you query one endpoint instead of building provider logic. Suunto · May 4, 2026 · 6 min read ### How to integrate Suunto data into your training app Suunto's altitude metrics and Training Effect scores enable outdoor sport features no other major wearable API covers with comparable depth. Here's how to use them in a product. Suunto · May 2, 2026 · 7 min read ### Suunto API: accessing watch data for developers The Suunto API provides workout data for 80+ sport types with GPS, heart rate, altitude metrics, Training Effect scores and VO2 max. Here's what building with it requires. The platform ## Looking for the product rather than the post? ### [Platform](https://openwearables.io/platform) ### [Integrations](https://openwearables.io/integrations) ### [Pricing](https://openwearables.io/pricing) --- Source: https://openwearables.io/blog/category/ultrahuman # Ultrahuman Blog Every post filed under Ultrahuman, newest first. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) ## Posts Ultrahuman · May 5, 2026 · 6 min read ### Ultrahuman API: ring data, CGM and recovery metrics Ultrahuman Ring AIR provides Recovery Score, Sleep Score, HRV, skin temperature and movement data. Its CGM integration adds continuous blood glucose alongside recovery metrics. Ultrahuman · May 5, 2026 · 6 min read ### Building with Ultrahuman data: recovery, sleep and glucose Ultrahuman's combination of ring biometrics and optional CGM glucose data enables product features no other single platform supports. Here's how to build with it effectively. The platform ## Looking for the product rather than the post? ### [Platform](https://openwearables.io/platform) ### [Integrations](https://openwearables.io/integrations) ### [Pricing](https://openwearables.io/pricing) --- Source: https://openwearables.io/blog/category/whoop # Whoop Blog Every post filed under Whoop, newest first. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) ## Posts Whoop · Jun 2, 2026 · 4 min read ### How to integrate Whoop API data into your health app The Whoop API requires a paid membership and OAuth setup. Learn how Open Wearables handles authentication, polling, and normalization so you query one endpoint. Whoop · May 6, 2026 · 9 min read ### Whoop API: recovery, strain and sleep data for developers The Whoop API exposes Recovery Score, HRV, Strain and Sleep Performance through a cycle-based model. Here's how it works in practice and what building with it actually requires. Whoop · May 6, 2026 · 6 min read ### Building a health app with Whoop API data Getting data out of the Whoop API is one problem. Building something users find valuable is another. Here's how to use Recovery Score, HRV trends and Sleep Performance effectively in a product. The platform ## Looking for the product rather than the post? ### [Platform](https://openwearables.io/platform) ### [Integrations](https://openwearables.io/integrations) ### [Pricing](https://openwearables.io/pricing) --- Source: https://openwearables.io/blog/fitbit-alternatives-for-developers # Fitbit Alternatives for Developers [All posts](https://openwearables.io/blog) [Fitbit](https://openwearables.io/blog/category/fitbit) Open Wearables Team · Aug 12, 2026 · 6 min read ## Key Takeaways - Fitbit's shutdown is a data-source decision for developers, not a device decision for consumers. Most published "Fitbit alternative" guides compare wrist hardware and miss this entirely. - Check what your integration actually pulled from Fitbit before searching for a replacement. Most third-party platforms only reliably shipped workouts and activity data against Fitbit's API. - Since Google owns Fitbit, the Google Health API is the most direct successor for existing Fitbit users: same underlying accounts, no new device required, but with OAuth verification and CASA requirements at scale. - Beyond that, alternatives split into cloud OAuth providers (Garmin, Whoop, Oura, Polar, Strava, Ultrahuman) and on-device SDK providers (Apple Health, Google Health Connect, Samsung Health), each with different integration models. - The real decision is single-provider integration versus a unified API layer across several providers, since most health products end up supporting more than one device over time. Search "Fitbit alternative" and you get smartwatch buying guides. Which watch has the best battery life, which one tracks sleep most accurately, which is cheapest. That is a reasonable question if you are a consumer replacing a device on your wrist. It is the wrong question if you are the team that built a product on top of Fitbit's Web API and just learned it shuts down in September 2026. Your users are not choosing a new watch. You are choosing a new data source, and that is a different decision with different criteria: API stability, data coverage, OAuth maturity, and whether the provider is investing in its developer platform or quietly running it down the way Fitbit has been. Here is that decision, framed for the team making it rather than the person wearing the device. ## Start With What You Actually Need Check what your specific integration actually pulled from Fitbit, rather than assuming. If you built directly against Fitbit's raw Web API, you may have wired up sleep or intraday heart rate yourself. If you went through a third-party wearable data platform, workouts and activity data (type, duration, calories, distance, average heart rate) is the coverage most of them shipped, since that was the reliably available surface. If that's genuinely all your product used, your replacement search is narrower than it might feel. If you were also hoping to eventually add sleep or continuous heart rate and were blocked by your platform's frozen feature set on Fitbit specifically, this is also a chance to pick a provider that actually has that data live today, rather than inheriting the same gap under a different vendor. ## The Direct Successor: Google Health API Since Google owns Fitbit, the most direct replacement for users who already have a Fitbit account is the Google Health API. It is not a different wearable, it is Google's cloud REST API that aggregates Fitbit, Pixel, and other connected sources under one OAuth connection. Your existing Fitbit users do not need a new device; their existing data keeps flowing, just through a different endpoint. The trade-off is process, not data availability: Google Health API scopes are largely restricted, which means OAuth app verification and, past 100 users, an annual CASA security assessment. That is a real cost and timeline to plan for, not a blocker, but it belongs in your evaluation alongside the technical fit. ## If You're Open to Diversifying Beyond Fitbit's User Base For teams building fitness or wellness products rather than servicing an existing Fitbit user base specifically, the practical alternatives split into two categories. Cloud OAuth providers, similar in architecture to Fitbit's old model: Garmin (broad activity, HRV, sleep, stress, body battery, VO2 max), Whoop (recovery, strain, sleep performance, HRV, resting heart rate), Oura (sleep score, readiness, HRV, body temperature deviation, SpO2), Polar (training load, Nightly Recharge, VO2 max), Strava (activity-focused, strong on GPS and social workout data), and Ultrahuman (recovery, sleep, HRV, skin temperature). Each requires its own developer credentials and has its own OAuth quirks, rate limits, and data model. On-device SDK providers, a structurally different approach: Apple Health and Google Health Connect (Google's current Android health data platform, which has replaced the older, now-deprecated Google Fit API) read data that is already aggregated on the user's phone from whichever apps and devices they have connected, without a cloud OAuth flow. Samsung Health follows the same on-device model. Coverage often broadly overlaps or exceeds a single cloud provider, since the phone is aggregating multiple sources already, but you need a mobile app under your brand for the SDK to run in, and app store review is part of the timeline. ## The Real Decision Isn't "Which Wearable" The question a team should actually be answering is: single-provider deep integration, or unified access across several. If your product only ever needs one data source, integrate directly against whichever provider's API and coverage best fits, and accept that you now own OAuth maintenance, rate limit handling, and schema changes for that one vendor indefinitely. If your roadmap realistically involves supporting more than one provider, which most consumer or clinical health products eventually do once they scale past an early user base with one device preference, a unified API layer that normalizes Garmin, Oura, Whoop, Google Health API, and the rest to one schema removes the compounding maintenance cost of running N separate integrations, each drifting on its own schedule. That is also the more resilient posture against exactly the situation you are in right now. Fitbit's shutdown is not a one-off; provider APIs get deprecated, acquired, and restructured on a longer timeline than most product roadmaps plan for. An abstraction that lets you swap or add a provider without rewriting your data model is worth more the second time this happens, and there will be a second time. See the [full list of supported providers and how they compare](https://openwearables.io/integrations) if you are mapping out which combination fits your existing user base and data requirements. For users specifically migrating off Fitbit's old API, the [Google Health API path](https://openwearables.io/integrations/google-health) is worth evaluating first, since it keeps existing Fitbit-linked accounts intact. ## See related articles [Fitbit Web API Shutdown 2026: Migration Guide](https://openwearables.io/blog/fitbit-web-api-shutdown-2026-migration-guide) [Google Health API and Google Health Connect: What's the Difference](https://openwearables.io/blog/google-health-api-and-google-health-connect-difference) [Google Health API: A Practical Guide to Getting Started](https://openwearables.io/blog/google-health-api-practical-guide-getting-started) [Google CASA and OAuth Verification for Health Apps](https://openwearables.io/blog/google-casa-oauth-verification-health-apps) ## FAQ ### What is the best Fitbit alternative for developers? It depends on whether you are servicing existing Fitbit users or building fresh. For existing Fitbit users, the Google Health API keeps their data flowing without requiring a new device, since Google owns Fitbit. For new products, Garmin, Whoop, and Oura are the closest matches in data depth to what Fitbit offered through its API. ### Do I need a new device if my users have Fitbits? No. Since Fitbit is owned by Google, existing Fitbit accounts connect through the Google Health API without users needing to buy new hardware. Their historical and ongoing data keeps flowing through a different endpoint. ### What data did most Fitbit integrations actually support? Workouts and activity data (type, duration, calories, distance, average heart rate) is what most third-party platforms reliably shipped against Fitbit's API. Sleep and intraday heart rate were technically available but were not commonly built out, so check your specific integration's coverage before assuming. ### Should I integrate with one provider or several? If your product only ever needs one data source, a direct integration is simpler to start with. If your roadmap will likely support more than one provider, which most health products eventually do, a unified API layer avoids maintaining separate OAuth flows, rate limits, and schemas per vendor. ### What is the difference between cloud OAuth and on-device SDK providers? Cloud OAuth providers (Garmin, Whoop, Oura, Polar, Strava, Ultrahuman) authenticate through a web-based flow and sync data to your backend. On-device SDK providers (Apple Health, Google Health Connect, Samsung Health) require a mobile app under your brand and read data that is already aggregated on the user's phone. ## Keep reading Fitbit · Aug 12, 2026 · 7 min read ### Fitbit Web API Shutdown 2026: Migration Guide Google is turning down the legacy Fitbit Web API in September 2026. Here is what still works, what never did, and how the migration to the Google Health API actually looks. Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. Guides · Oct 26, 2026 · 9 min read ### Moving from a hosted wearable API to Open Wearables: a migration playbook Moving from a hosted wearable API to Open Wearables is usually a re-integration rather than a data migration. This playbook walks through the decisions, the steps in order, how your users reconnect and what to tell your security team. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/fitbit-web-api-shutdown-2026-migration-guide # Fitbit Web API Shutdown 2026: Migration Guide [All posts](https://openwearables.io/blog) [Fitbit](https://openwearables.io/blog/category/fitbit) Open Wearables Team · Aug 12, 2026 · 7 min read ## Key Takeaways - Google is turning down the legacy Fitbit Web API in September 2026. It is a hard cutoff, not a gradual deprecation, and new Fitbit developer registrations have already closed. - Today's Fitbit Web API reliably supports workouts and activity data (type, duration, calories, distance, average heart rate) over pull-based OAuth 2.0, rate-limited to 150 requests per hour per user. - Sleep, intraday heart rate, and daily activity summary are technically available in Fitbit's API but were never built out against it by platforms like Open Wearables, and will not be added now that the API is being retired. - The successor is the Google Health API: a cloud REST API with no SDK, aggregating Fitbit, Pixel, and other connected sources, with webhooks and a reconcile/list choice for handling overlapping data sources. - Migrating is closer to adding a new provider than patching an existing integration: a new OAuth flow, a broader data model, and an event-driven sync architecture. In September 2026, Google is turning down the legacy Fitbit Web API. If your app reads workout, activity, sleep, or heart rate data from Fitbit through that API, this is not a distant deprecation notice to file away. It is a hard cutoff with a fixed date, and new Fitbit developer registrations have already closed, so there is no path to start fresh on the old API even if you wanted to. This is a practical guide to what is actually shutting down, what still works until then, and how the migration to Google's successor API looks in practice. ## What Is Actually Happening Fitbit's Web API, the one documented at [dev.fitbit.com](https://dev.fitbit.com) with its own OAuth 2.0 flow and REST endpoints, is being retired by Google. It will stop syncing data entirely once the shutdown lands. This is not Fitbit changing a rate limit or deprecating one endpoint. It is the whole API surface going away. Two details matter for anyone currently building on it: - New developer registrations are closed. If you do not already have Fitbit API credentials, you cannot get them. This alone should end any conversation about starting a new integration against the legacy Fitbit API today. - The API is feature-frozen in the meantime. Existing integrations keep working until the shutdown date, but nobody, including Fitbit itself, is investing further in this surface. Data types that were never implemented against it will not be implemented now. ## What the Fitbit Web API Actually Supports Today If you are running against the current API, here is where it stands. Workouts and activity data (activity type, duration, calories, distance, average heart rate during logged activities) work over OAuth 2.0, pull-based, with no webhook support, so you are polling on a schedule rather than receiving push notifications. Sleep, intraday heart rate, and daily activity summary are technically available in the Fitbit Web API, but Open Wearables never built these out against it, and will not now, given the shutdown date. Check your own integration's actual coverage rather than assuming; some teams did implement these against the raw Fitbit API directly. If you're relying on a platform like ours that didn't, that gap doesn't get resolved by the shutdown, it just becomes permanent. Rate limiting sits at 150 requests per hour per user, returning HTTP 429 when exceeded. That number matters for the migration too, since Google's replacement has different limits and a different request model entirely. ## The Successor: Google Health API Google's replacement is the Google Health API, a cloud REST API that requires no SDK. It carries Fitbit account data along with Pixel and other connected sources, aggregated under a single Google Health identity rather than Fitbit's separate developer platform. The practical implications of switching: - OAuth changes. You are authenticating against Google's OAuth 2.0 flow and requesting Google Health scopes, not Fitbit's client credentials. This is a genuine re-implementation of your auth layer, not a config change. - Broader data model. Because the Google Health API aggregates across every source connected to a user's Google Health account, not just Fitbit, you get access to 24/7 metrics (steps, distance, calories, hydration, heart rate, resting heart rate, HRV, VO2 max, respiratory rate, SpO2, weight, body fat, core temperature, blood glucose), workouts, and sleep with stages, most of which never existed on the old Fitbit path for platforms like ours that only implemented workouts and activity against it. - Webhooks, finally. Unlike Fitbit's pull-only model, the Google Health API supports notify-only webhooks. A notification tells you what changed and when; you fetch the actual data over REST in response. That changes your sync architecture from scheduled polling to event-driven fetches. - Deduplication becomes your problem, or isn't. A user's steps might be reported by both their phone and a connected Fitbit at once. Google's API exposes a reconcile mode, which returns one merged, deduplicated total matching what the native Google Health app shows, and a list mode, which returns raw per-source data tagged by device. This did not exist as a concept on the old Fitbit API, because there was only ever one source. ## What Migrating Actually Involves The honest scope of this migration is closer to adding a new provider than updating an existing one. You are not patching an integration; you are replacing an OAuth flow, a data model, and a sync mechanism. A few things worth deciding early: 1. Don't wait for the deadline to start. OAuth re-implementation, testing against real Google accounts, and validating your new data model against production traffic all take longer than the runway remaining before the September shutdown makes comfortable. 2. Decide on reconcile vs. list mode before you build storage for it. If your existing schema assumes one authoritative value per metric per day, reconcile mode is the closer match. If you need to know which physical device produced a reading, list mode is the only path, but you take on deduplication logic yourself. 3. If you are on Open Wearables or a similar abstraction layer, check whether the migration is already absorbed. A unified schema across providers means the switch from Fitbit to Google Health API can be a provider swap rather than a data-model rewrite on your end, since the same endpoints and field names keep working regardless of which upstream API is feeding them. ## If You're Evaluating Whether to Migrate at All There are two paths off the old Fitbit API: the Google Health API described above, or reading the same underlying data on-device through Health Connect (Android) or Apple Health (iOS), which avoids Google's cloud OAuth entirely at the cost of needing a mobile app under your own brand. Which one fits depends on whether you already have a mobile presence and how much of your roadmap depends on server-side access to this data. Either way, the deadline is fixed and the old registration path is already closed. The only real decision left is which successor to build against, not whether to move. If you want the specifics of how Open Wearables handles the Google Health API side of this, [the integration page covers the OAuth flow, data model, and webhook mechanics](https://openwearables.io/integrations/google-health) in detail. For what the Fitbit connector still does until the shutdown, see the [Fitbit integration page](https://openwearables.io/integrations/fitbit). ## See related articles [Fitbit Alternatives for Developers](https://openwearables.io/blog/fitbit-alternatives-for-developers) [Google CASA and OAuth Verification for Health Apps](https://openwearables.io/blog/google-casa-oauth-verification-health-apps) [Google Health API: A Practical Guide to Getting Started](https://openwearables.io/blog/google-health-api-practical-guide-getting-started) [Google Health API and Google Health Connect: What's the Difference](https://openwearables.io/blog/google-health-api-and-google-health-connect-difference) ## FAQ ### Is Fitbit's API really shutting down? Yes. Google has confirmed that the legacy Fitbit Web API will be turned down in September 2026 and will stop syncing data. New Fitbit developer accounts are no longer being issued. ### Does Open Wearables still support Fitbit? Yes, for workout and activity data, until the shutdown date. The integration is feature-frozen: Open Wearables is not adding new Fitbit data types, since the API itself is going away. ### What Fitbit data is not supported? Sleep, intraday heart rate, and daily activity summary are available in the Fitbit Web API but were never implemented by platforms like Open Wearables, and will not be added given the shutdown. ### What should I migrate to instead of the Fitbit API? The Google Health API. It is Google's cloud OAuth layer for Google Health data, and it aggregates data from Fitbit accounts, Health Connect, Google Fit, and other connected sources under one integration. ### How long do I have to migrate? The shutdown is set for September 2026. New Fitbit developer registrations are already closed, so the runway is shorter than it may appear. Start the OAuth re-implementation and data model changes well before the deadline rather than waiting for it. ### Can I avoid Google's cloud OAuth entirely? Yes, by reading the same underlying data on-device through Health Connect on Android or Apple Health on iOS instead of the Google Health API. This requires shipping your own mobile app and going through its app store review process. ## Keep reading Fitbit · Aug 12, 2026 · 6 min read ### Fitbit Alternatives for Developers Fitbit is shutting down its Web API in September 2026. Here is how to think about replacement data sources as a developer, not as a consumer buying a new watch. Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. Guides · Oct 26, 2026 · 9 min read ### Moving from a hosted wearable API to Open Wearables: a migration playbook Moving from a hosted wearable API to Open Wearables is usually a re-integration rather than a data migration. This playbook walks through the decisions, the steps in order, how your users reconnect and what to tell your security team. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/garmin-api-push-notifications-how-callback-sync-works # Garmin API push notifications: how callback sync works [All posts](https://openwearables.io/blog) [Garmin](https://openwearables.io/blog/category/garmin) Open Wearables Team · May 6, 2026 · 7 min read ## Key takeaways - Garmin's push notification system delivers data to your registered callback URLs when users sync their devices, not when you request it - Each Garmin data type has a separate callback URL: activities, daily summaries, sleep, HRV, stress, body composition and more - Your handlers must respond with HTTP 200 within a few seconds; all processing must be asynchronous - Garmin retries failed deliveries, so idempotent processing is essential at every level - Open Wearables pre-builds all Garmin callback infrastructure and delivers normalized data through a query API ## Introduction Most API integrations follow the same pattern: your code makes a request, the API returns data. You control the timing, the scope and the frequency. Garmin's Health API inverts this entirely. When a Garmin user syncs their device, Garmin processes the data on their backend and pushes it to callback URLs that you have registered in advance. You do not request the data. Garmin delivers it. Your job is to be ready to receive it at any time, process it correctly, and return a 200 response fast enough that Garmin does not mark the delivery as failed. This architecture is efficient once it is running. You only process data when it actually exists, which means no polling and no wasted API calls. But the operational requirements are more demanding than a traditional pull API: always-on public HTTPS endpoints, asynchronous processing infrastructure, idempotent database operations, and monitoring to detect delivery failures quickly. ## How the push system works The data flow from a Garmin device sync to your database has several steps. Understanding each step is necessary for building a reliable integration. When a user syncs their Garmin device via the Connect mobile app or a USB/WiFi connection to Garmin Connect on desktop, Garmin's backend processes the raw data from the device. This processing extracts structured data: activities, daily health summaries, sleep records, HRV measurements and so on. Garmin then looks up which third-party applications the user has authorized and sends the relevant data to each application's registered callback URL. Your server receives a POST request with a JSON payload. The payload may contain multiple records of the same type if the user has not synced in several days. You process the data, store it, and return HTTP 200. Garmin marks the delivery as successful. If you return a non-200 response or fail to respond within the timeout window, Garmin marks the delivery as failed and will retry. The retry behavior means your processing must be idempotent. If Garmin sends the same activity twice (once initially and once as a retry after a transient failure on your end), processing it twice should produce the same result as processing it once. Use upsert operations keyed on Garmin's unique identifiers rather than inserts that could create duplicates. ## Callback types and what they carry Garmin supports separate callback URLs for each data category. You register only the ones you need. Each callback receives a different payload structure. Activities are the most data-rich payload. Each activity includes sport type, start time, duration, distance, calories, average and maximum heart rate, and summary statistics specific to the sport type. Running activities include pace, cadence and elevation. Cycling activities include power and cadence. The payload also contains a URL to fetch the full activity details including per-second data streams if needed. Activity payloads identify the user by their OAuth access token, which you must map to your internal user ID. Daily summaries consolidate health data for a calendar day: steps, floors climbed, active and BMR calories, distance, intensity minutes, resting heart rate, average stress level, Body Battery high and low values, average respiration rate, average SpO2 where available, and sleep duration. Sleep records contain sleep start and end times, sleep duration, time in each stage (deep, light, REM, awake), average respiration rate during sleep, average SpO2 during sleep where available, and an overall sleep score. HRV summaries include the weekly average, the last-night average, the last-night 5-minute high, and a status classification (balanced, unbalanced, low or poor) based on Garmin's proprietary interpretation of HRV relative to the user's baseline. ## Implementing the callbacks The most important rule for webhook handlers is: do not do heavy work in the handler. Return 200 immediately and queue the processing. ``` @app.route('/garmin/activities', methods=['POST']) def receive_activities(): process_garmin_activities.delay(request.json) return '', 200 ``` This pattern is critical. If your database is slow, your normalization logic is complex, or your infrastructure is under load, inline processing risks timing out and causing Garmin to retry. Queuing with Celery, RQ or any task queue keeps handler response time in milliseconds regardless of downstream conditions. For user identification, Garmin includes the OAuth access token in each payload record as userAccessToken. You must store this token at OAuth connection time mapped to your internal user ID. Every callback handler needs to look up the user from this token before processing. If the lookup fails (the user has disconnected or the token has been revoked), discard the payload and return 200 to prevent Garmin from retrying. For idempotency, key your database upserts on Garmin's IDs. Activities have a unique activityId. Daily summaries have calendarDate plus userId as a natural composite key. Sleep records have their own IDs. Design your data layer to treat repeated processing of the same record as a safe no-op. ## Monitoring and failure detection Push-based integrations have a failure mode that pull integrations do not: silent data gaps. If your callback endpoint goes down, Garmin retries for a period and then stops. When your endpoint comes back up, Garmin does not automatically resend data from the outage window. That data is gone unless you implement a backfill mechanism. Monitor your callback endpoints with uptime checks and alert on downtime quickly. Monitor incoming delivery volume per data type and alert when it drops to zero unexpectedly. Users who sync their Garmin devices daily should generate daily callbacks. If you see no deliveries for a given user over 48 hours, something is likely wrong. ## Open Wearables and Garmin push Open Wearables pre-builds the complete Garmin callback infrastructure. It handles OAuth 1.0a authentication, callback URL registration for all data types, asynchronous processing of push payloads, user token mapping, idempotent storage, and normalization of Garmin's data schema into a consistent format shared with other providers. You configure Open Wearables with your Garmin Health API credentials, register your Open Wearables instance's callback URLs with Garmin, and receive normalized data through a simple query interface. The push complexity is abstracted away. ## Faq ### What happens if my server is down when Garmin sends data? Garmin retries failed deliveries on a schedule. The retry window and frequency are controlled by Garmin. Data delivered after the retry window closes is lost unless you implement historical backfill. Monitor your endpoints and minimize downtime. ### Can i request specific Garmin data on demand rather than waiting for push? Garmin's Health API is push-first. Some pull endpoints exist for initial historical backfill when a user connects, but real-time data delivery relies on push. Do not design your architecture around on-demand Garmin API calls. ### How do i test Garmin callbacks in local development? Use a tunneling service like ngrok to expose your local server with a public HTTPS URL and register that URL temporarily with Garmin during development. The Garmin sandbox environment generates synthetic push events that let you test your handlers without a physical device. ### Are Garmin activity payloads always complete? Activity payloads contain summary data. To access per-second data streams (GPS points, heart rate by second, power by second), you make a separate request to the activity detail URL included in the payload. This additional request consumes Garmin API quota. ### How does user identification work in push payloads? Each data record in a push payload includes userAccessToken, which is the OAuth access token issued to that user when they connected your application. Store this token in your database at connection time keyed to your internal user ID, and use it as the lookup key in every callback handler. ## Open Wearables Open Wearables is an open-source platform that connects your application to wearable and health data providers through a single API. One normalized data model, multi-provider support in a single self-hosted deployment, no per-user fees, MIT licensed, and health intelligence built in: normalized recovery, sleep, activity and biometric data ready for your product layer. We offer custom deployment and integration support through Momentum. If your team needs help getting to production faster, we can set up and configure Open Wearables as part of a managed engagement. [Let's talk](https://www.themomentum.ai/lets-talk). [Book a demo](https://openwearables.io/book) to see how Open Wearables fits your use case. ## Garmin integration View the full [Garmin integration documentation](https://openwearables.io/integrations/garmin) on Open Wearables. ## See related articles [Garmin Connect API: Developer Guide for Activities and Health Metrics](https://openwearables.io/blog/garmin-connect-api-developer-guide-activities-health-metrics) [How to Integrate Strava Without Building OAuth From Scratch](https://openwearables.io/blog/how-to-integrate-strava-without-building-oauth-from-scratch) [Polar API: Training, HRV and Nightly Recharge Data](https://openwearables.io/blog/polar-api-training-hrv-nightly-recharge-data) ## Keep reading Garmin · Oct 23, 2026 · 4 min read ### Garmin Connect Developer Program reopened: what changes for your integration Garmin reopened the Connect Developer Program with Personal, Starter and Enterprise tiers. Each company now holds its own app and credentials. Here is what that means for delivery, backfill, AI use and moving an existing integration. Garmin · Jul 21, 2026 · 8 min read ### Garmin Connect API: What You Can Fetch and How to Do It Faster The Garmin API gives you access to workouts, health metrics, and device data. Here is what you can retrieve, how the OAuth 1.0 flow works, and when it makes sense to use a ready-made integration layer instead of building from scratch. Garmin · May 6, 2026 · 11 min read ### Garmin Connect API: developer guide for activities and health metrics Garmin's Health API uses push-based delivery and OAuth 1.0a, covering 100+ sport types, GPS, Body Battery, HRV, sleep and more. Here's what building with it actually requires. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/garmin-connect-api-developer-guide-activities-health-metrics # Garmin Connect API: developer guide for activities and health metrics [All posts](https://openwearables.io/blog) [Garmin](https://openwearables.io/blog/category/garmin) Open Wearables Team · May 6, 2026 · 11 min read ## Key takeaways - **Garmin Health API requires partner program approval**: full server-side access to user health data is not available as a self-serve developer credential. - **Garmin uses push-based delivery**: data is sent to your registered callback URLs when a user syncs their device. There is no polling endpoint. - **Authentication uses OAuth 2.0 with PKCE**, and connecting an account automatically kicks off historical backfill for the user. - **Available data is unusually rich**: 100+ activity types, GPS, heart rate, HRV, sleep, Body Battery, stress, VO2 max, respiration, and more. - **python-garminconnect is unofficial**: it scrapes Garmin Connect session data rather than using the Health API. Useful for personal projects, fragile for production. - **30-day historical backfill** is available when a user first connects. - **Open Wearables** handles OAuth 2.0 authentication, push notification registration, callback processing, and normalization. You query unified endpoints instead of managing Garmin-specific infrastructure. ## Introduction Garmin occupies a specific position in the wearable market. Their devices are trusted by endurance athletes, military users, outdoor adventurers and sports scientists who prioritize battery life, GPS accuracy and sensor depth over sleek consumer aesthetics. The Garmin API reflects this heritage: it covers over 100 sport types with detailed per-activity data including running dynamics, cycling power metrics, swim stroke analysis and altitude tracking. For developers building serious fitness or performance applications, Garmin data is uniquely rich. But the API is also one of the more technically demanding integrations in the wearable space. Data delivery is push-based, meaning Garmin sends data to your server rather than waiting for you to request it, and it uses OAuth 2.0 with PKCE for authentication. Full access requires a partnership application rather than a self-serve developer account. This guide covers what the Garmin API provides, how its push architecture works, what authentication requires in practice, and how to handle the operational complexity of a production Garmin integration. ## What Garmin exposes Garmin's data coverage is broader than any other wearable API in terms of sport types and activity metrics. Over 100 sport types are supported with type-specific data. Running activities include not just time, distance and heart rate but also running dynamics: cadence, stride length, ground contact time, vertical oscillation, vertical ratio and ground contact time balance. These are signals that most wearable APIs do not expose at all. Cyclists get power (watts, normalized power, intensity factor, training stress score), cadence and FTP-based training load. Swimmers get stroke type, SWOLF score, strokes per length and pool length. For health and recovery monitoring, Garmin provides: Body Battery (a proprietary 0-100 energy indicator that accounts for HRV, stress and sleep), daily stress score, resting heart rate, nightly HRV, sleep staging and score, respiration rate, SpO2, and VO2 Max estimated from running and cycling activities. Body composition is available for users with compatible Garmin scales (Garmin Index) including weight, BMI, body fat percentage, muscle mass, bone mass and body water. Daily summaries aggregate step count, floors climbed, active calories, BMR calories, intensity minutes and stress levels throughout the day. ## Push-based delivery The fundamental architectural difference between Garmin and most other wearable APIs is that Garmin delivers data to you rather than waiting for you to fetch it. This is not a webhook notification that triggers a subsequent API call. Garmin pushes the full data payload directly to your registered callback URL when a user syncs their device. You register separate callback URLs for each data type you want to receive: activities, daily summaries, epochs (activity-level data by minute), sleep, body composition, stress, user metrics (VO2 Max estimates), pulse oximetry, respiration and HRV. Each has its own endpoint. When a Garmin device syncs, Garmin's backend processes the data and POSTs it to the appropriate URLs for all users who have authorized your application. The practical implications of this architecture are significant. Your callback endpoints must be publicly reachable with valid HTTPS certificates at all times. If your endpoint is down when Garmin attempts delivery, Garmin will retry, but there is no guarantee of delivery. You must design for idempotent processing because Garmin may send the same data multiple times. And you must respond to each incoming request with HTTP 200 within a few seconds, which means your handler needs to queue the actual processing asynchronously rather than doing it inline. In practice, you register a single webhook endpoint with Garmin for all data types: ``` https:///api/v1/garmin/webhooks/push ``` Garmin sends two kinds of webhook notifications to this endpoint. PING notifications carry callback URLs that your server then fetches to retrieve the actual data: ``` { "sleeps": [{"userId": "garmin-uid", "callbackURL": "https://..."}], "dailies": ["..."], "activities": ["..."] } ``` PUSH notifications, used for some data types, deliver the payload directly in the webhook body instead of a callback URL. Either way, all 16 Garmin data types are handled by the same webhook endpoint regardless of whether they're part of historical backfill. ## Authentication: OAuth 2.0 with PKCE Garmin uses OAuth 2.0 with PKCE (Proof Key for Code Exchange). The flow is standard for anyone who has implemented OAuth 2.0 before: your frontend redirects the user to an authorize endpoint, the user grants permissions on Garmin's site, and Garmin redirects back to a callback endpoint that exchanges the authorization code for tokens. The flow through Open Wearables: ``` GET /api/v1/oauth/{provider}/authorize ``` The frontend redirects the user here. After the user grants permissions on Garmin's site, Garmin redirects back to: ``` GET /api/v1/oauth/{provider}/callback ``` The callback handler creates or updates the user's connection record, dispatches an initial sync task, and for Garmin specifically, kicks off the historical backfill automatically. There is no manual "Sync Now" step for Garmin: connecting the account starts the backfill. One Garmin-specific detail to know upfront: if the user does not grant the HISTORICAL_DATA_EXPORT permission during authorization, all backfill requests will return 403 and all 5 backfill data types fail together. ## Access requirements Garmin's Health API is not available as a self-serve developer credential. Full server-side access to user health data through the push notification system requires applying to Garmin's Health API partner program. The application asks about your use case, your company, your data handling practices and your integration plans. Garmin offers different access tiers. Consumer-facing applications can apply through one channel. Research and clinical applications have a separate pathway. The approval process typically takes days to weeks depending on the completeness of your application and Garmin's current review queue. For prototyping and development purposes, Garmin provides a health API sandbox that allows testing without full partner approval. The sandbox generates synthetic data that mirrors the structure of real device data, which lets you build and validate your push handler logic before real user data arrives. Once your evaluation app is approved and created in the Garmin Developer Portal, configure Open Wearables with the resulting credentials: ``` # Garmin OAuth Credentials GARMIN_CLIENT_ID=your_client_id_here GARMIN_CLIENT_SECRET=your_client_secret_here GARMIN_REDIRECT_URI=https://yourdomain.com/api/v1/oauth/garmin/callback ``` ## The unofficial alternative: python-garminconnect If you search for "garmin api" on GitHub, the most popular result is python-garminconnect. It is an unofficial library that works by authenticating to Garmin Connect as a user would through a browser, then scraping session data. For personal projects and data exploration, it works. For production applications with real users, it has significant limitations: it depends on undocumented internal endpoints that Garmin can change without notice, it requires users to provide their Garmin Connect credentials directly to your application rather than through OAuth, and it is not a supported integration path that Garmin acknowledges or maintains compatibility with. If your use case is a personal health dashboard or a one-off data export, python-garminconnect is a reasonable tool. If you are building a product with users who are not you, the official Health API with proper OAuth is the right path. The access requirements exist precisely because Garmin wants to know who is handling their users' data. ## Backfill data types and endpoints Of Garmin's 16 total data types, only 5 are actively requested during historical backfill when a user first connects: - sleeps — /wellness-api/rest/backfill/sleeps — sleep sessions with stages - dailies — /wellness-api/rest/backfill/dailies — daily summaries (steps, calories, heart rate) - activities — /wellness-api/rest/backfill/activities — activity/workout summaries - activityDetails — /wellness-api/rest/backfill/activityDetails — detailed activity data (laps, samples) - hrv — /wellness-api/rest/backfill/hrv — heart rate variability The remaining 11 data types are not requested during backfill, but are accepted whenever Garmin pushes them via webhook: epochs, bodyComps, stressDetails, allDayRespiration, pulseox, bloodPressures, userMetrics, skinTemp, healthSnapshot, moveIQActivities, and mct. Backfill covers a single 30-day window, the maximum range Garmin allows before the user connected your app. Each data type can typically be backfilled only once. Garmin's API allows 100 requests per minute; Open Wearables reserves 30% of that budget for backfill, which works out to a 2-second delay between type requests. You can check backfill progress directly: ``` GET /api/v1/providers/garmin/users/{user_id}/backfill/status ``` Response: ``` { "overall_status": "in_progress", "current_window": 0, "total_windows": 1, "windows": { "0": {"sleeps": "done", "dailies": "done", "activities": "timed_out", "activityDetails": "done", "hrv": "pending"} }, "summary": { "sleeps": {"done": 1, "timed_out": 0, "failed": 0}, "dailies": {"done": 1, "timed_out": 0, "failed": 0}, "activities": {"done": 0, "timed_out": 1, "failed": 0}, "activityDetails": {"done": 1, "timed_out": 0, "failed": 0}, "hrv": {"done": 0, "timed_out": 0, "failed": 0} }, "in_progress": true, "retry_phase": false, "retry_type": null, "retry_window": null, "attempt_count": 0, "max_attempts": 3, "permanently_failed": false } ``` Two more endpoints let you manage an in-progress backfill: POST.../backfill/cancel requests a graceful cancellation (returns 409 if no backfill is in progress), and POST.../backfill/{type_name}/retry retries a specific timed-out type. ## Common issues when building with the Garmin API ### Webhook endpoint must be publicly reachable Garmin cannot push data to localhost. During development, you need a publicly accessible HTTPS endpoint. Tools like ngrok or a deployed staging environment work. Build gap detection into your sync logic: if your endpoint is down when Garmin pushes, you will miss that data window. ### OAuth callback and backfill permission errors If backfill requests return 403 for all 5 backfill data types at once, the user did not grant the HISTORICAL_DATA_EXPORT permission during authorization. This scope is off by default on Garmin's consent screen and must be explicitly enabled by the user; there is no way to request backfill data without it. ### Data arrives per data type, not per activity Garmin sends separate callbacks for activities, sleep, daily summaries, HRV, and epochs. A single device sync triggers multiple separate payloads to multiple callback URLs. Design your data model and processing logic to handle these as independent streams that you join on user ID and timestamp, not as a single combined event. ### Idempotent processing is required Garmin retries failed deliveries. If your callback returns anything other than HTTP 200, Garmin will attempt redelivery. Use activity IDs and summary IDs as natural keys with upsert logic to handle duplicate deliveries without corrupting your data. ## Body Battery Body Battery is Garmin's proprietary energy level indicator, scored from 0 to 100. It combines HRV analysis, stress detection and sleep quality into a running estimate of the user's available energy reserve. Body Battery depletes during the day as activity and stress accumulate, and recharges during sleep. Body Battery is available in daily summaries, including the peak value for the day and the low value. It is one of Garmin's most user-loved features and a differentiator compared to most competitors. If your app targets Garmin users, surfacing Body Battery prominently is worth doing. ## Open Wearables and Garmin Open Wearables handles Garmin's OAuth 2.0 authentication, push notification endpoint registration, callback processing and data normalization. Instead of building and maintaining OAuth infrastructure and individual callback handlers for every Garmin data type, you configure your Open Wearables instance with Garmin credentials and receive normalized activity and health data through a simple query API. The platform abstracts Garmin's push model behind a consistent interface. You query Open Wearables for a user's activity data the same way you query for Strava or Polar data, regardless of the underlying delivery mechanism each provider uses. ## Faq ### Does connecting Garmin start syncing data automatically? Yes. The OAuth callback both creates the user connection and dispatches the historical backfill task automatically. There is no separate manual sync step for Garmin, unlike some other providers. ### Do i need a physical Garmin device to develop against the API? For testing with the push sandbox, no. The sandbox generates synthetic data that mirrors real device payloads. For testing with real data including all activity types and device-specific metrics, a physical Garmin device is necessary. ### How quickly does Garmin push data after a device sync? Typically within one to five minutes of device sync. Delivery speed depends on Garmin's backend processing load. There is no real-time delivery guarantee. ### How do i handle idempotent processing of Garmin push events? Use Garmin's activity IDs and summary IDs as natural keys in your database with upsert operations. A duplicate delivery of the same activity should update the existing record rather than creating a duplicate. Design your processing to be safe to run multiple times on the same payload. ### Does Open Wearables support all Garmin data types? Open Wearables normalizes the core data types: activities, daily summaries, sleep, HRV and health metrics. Garmin-specific metrics like running dynamics are passed through where available in the activity payload. ## Open Wearables Open Wearables is an open-source platform that connects your application to wearable and health data providers through a single API. One normalized data model, multi-provider support in a single self-hosted deployment, no per-user fees, MIT licensed, and health intelligence built in: normalized recovery, sleep, activity and biometric data ready for your product layer. We offer custom deployment and integration support through Momentum. If your team needs help getting to production faster, we can set up and configure Open Wearables as part of a managed engagement. [Let's talk](https://www.themomentum.ai/lets-talk). [Book a demo](https://openwearables.io/book) to see how Open Wearables fits your use case. ## Garmin integration View the full [Garmin integration documentation](https://openwearables.io/integrations/garmin) on Open Wearables. ## See related articles - [What wearable app development actually looks like in 2026](https://openwearables.io/blog/what-wearable-app-development-actually-looks-like-in-2026) - [The wearable app development checklist: what you actually need to build (and what you don't)](https://openwearables.io/blog/wearable-app-development-checklist) [Garmin API Push Notifications: How Callback Sync Works](https://openwearables.io/blog/garmin-api-push-notifications-how-callback-sync-works) [Strava API Developer Guide: Activities, Heart Rate and GPS Data](https://openwearables.io/blog/strava-api-developer-guide-activities-heart-rate-gps-data) [Polar API: Training, HRV and Nightly Recharge Data](https://openwearables.io/blog/polar-api-training-hrv-nightly-recharge-data) ## Keep reading Garmin · Oct 23, 2026 · 4 min read ### Garmin Connect Developer Program reopened: what changes for your integration Garmin reopened the Connect Developer Program with Personal, Starter and Enterprise tiers. Each company now holds its own app and credentials. Here is what that means for delivery, backfill, AI use and moving an existing integration. Garmin · Jul 21, 2026 · 8 min read ### Garmin Connect API: What You Can Fetch and How to Do It Faster The Garmin API gives you access to workouts, health metrics, and device data. Here is what you can retrieve, how the OAuth 1.0 flow works, and when it makes sense to use a ready-made integration layer instead of building from scratch. Garmin · May 6, 2026 · 7 min read ### Garmin API push notifications: how callback sync works Garmin's Health API pushes data to your callback URLs when users sync their devices. Here's how the system works end-to-end and what reliable implementation requires. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/garmin-connect-api-what-you-can-fetch # Garmin Connect API: What You Can Fetch and How to Do It Faster [All posts](https://openwearables.io/blog) [Garmin](https://openwearables.io/blog/category/garmin) Open Wearables Team · Jul 21, 2026 · 8 min read The Garmin API gives you access to workouts, health metrics, and device data from Garmin Connect. Here is what you can retrieve, how the OAuth 1.0 flow works, and when it makes sense to use a ready-made integration layer instead of building from scratch. ## Key Takeaways - Garmin Connect API requires Partner Program approval before you get production credentials. Plan for this in your timeline - Garmin uses OAuth 1.0a, which requires signed requests (HMAC-SHA1) that most modern OAuth 2.0 libraries do not handle - Available data includes activities, daily health metrics (steps, sleep, SpO2, stress), continuous series (HR, cadence, power), and user profile - Garmin delivers activity data through webhooks, not polling. Your infrastructure needs a publicly accessible endpoint to receive it - The normalization problem compounds with every provider you add. The first integration looks fast; the third reveals every assumption you made - Open Wearables handles OAuth, token management, normalization, and deduplication as a self-hosted layer you deploy once ## What the Garmin API Returns Garmin Connect is the cloud platform that syncs data from all Garmin devices. A run logged on a Forerunner, power data from a cycling computer, a sleep cycle from a Venu, resting heart rate from a Fenix. Everything lands in Garmin Connect and is available through the garmin api. The Garmin Health API (documented at developer.garmin.com/health-api) is the interface intended for external application developers. It is distinct from Garmin Connect IQ, which is for on-device apps. The Health API is what you use when you want to read Garmin health data from your backend. **What you can fetch:** - **Activities (Events):** runs, cycling, swimming, triathlon. Each activity includes start and stop timestamps, distance, average and max heart rate, calories, sport type. GPS-tracked activities include full route data as a series of lat/lng points. - **Health metrics:** steps, resting heart rate, sleep phases (light, deep, REM), SpO2, stress score. This garmin health data is available as daily aggregates per user. - **Continuous data (Series):** heart rate sampled every few seconds during a workout, cadence, power for cyclists with a power meter. Granular time-series data is useful for load management algorithms or performance analysis. - **Profile:** weight, height, age, sex. Static data, but important for calibrating algorithms like VO2 max estimates or caloric targets. One important caveat: access to the Garmin Health API requires going through the Garmin Partner Program. The Garmin Connect Developer Program is currently not accepting new applications. The official access request form at garmin.com shows: "Stay tuned for more updates on the program." Check the current status at the Garmin developer portal before committing to a Garmin integration in your product timeline. ## OAuth 1.0: Why It Takes More Work Garmin uses OAuth 1.0a. Most modern libraries and newer providers have moved to OAuth 2.0, so OAuth 1.0 requires a bit more attention. Standard OAuth 2.0 is two steps: authorization code and access token. OAuth 1.0a adds a third: a request token you must obtain before redirecting the user to authorize. On top of that, every API request must be signed (HMAC-SHA1) with a unique timestamp and nonce. OAuth 2.0 libraries will not do this for you. In practice, the flow looks like this: 1. Fetch a request token from Garmin (request signed with your app key) 2. Redirect the user to Garmin for authorization (with the request token in the URL) 3. After the callback, exchange the request token and verifier for an access token 4. Sign every subsequent API request with the access token, timestamp, and nonce For a single application with one provider, this is manageable. The problem starts when you also need Polar (its own OAuth 2.0 flow), Whoop (OAuth 2.0 with webhooks), and Apple Health (no OAuth at all, Flutter SDK). Each provider has a different flow, different token format, and different edge case behavior. Token expiry is another layer. Garmin access tokens do not expire, but you still need to handle the case where a user revokes access or the token becomes invalid. For providers like Strava, tokens expire every six hours and require automatic refresh logic. Supporting multiple providers means building refresh logic for each one separately. ## Webhook Delivery: What It Means for Your Infrastructure Garmin delivers activity data through push webhooks, not through a polling endpoint you call on demand. When a user syncs their device, Garmin pushes the data to a callback URL you register. This means your backend needs a publicly accessible endpoint at a stable URL to receive Garmin data. If you are building in a local development environment, you will need something like ngrok to expose your local server for testing. In production, the endpoint must be reliable: if it is down when Garmin pushes, you miss that sync. The webhook payload contains the activity data in Garmin's schema. You process it, normalize it, and store it. If your endpoint returns an error, Garmin's retry behavior is limited, so the reliability requirement is real. For comparison, Oura and Strava also use webhooks. Whoop is webhook-only. Polar and Suunto support polling. If you are building for multiple providers, you end up with a mix of push and pull patterns running in parallel. ## Normalization: The Hidden Cost of Every Integration Garmin returns a running activity as a JSON object with fields in its own schema. Polar returns the same activity differently: different field names, different units (Garmin returns distance in meters, Polar in kilometers), different timestamp format. Apple Health does its own thing. A user training with a Garmin Fenix often also has a phone with Apple Health syncing the same runs. If your application listens to both providers, the same workout will appear twice in your data. Deduplication based on start time and distance is only an approximation, because providers differ by small amounts in timestamps. Sleep data is particularly inconsistent across providers. One provider may report a single sleep block with a duration. Another reports phases: light, deep, REM, awake, in separate records. A third reports segments with different phase definitions. Any downstream calculation that uses sleep as a signal (recovery scores, readiness metrics, sleep debt) has to resolve this before it can produce a meaningful result. This is the cost that is almost always underestimated at the planning stage. The first API integration is quick. The second requires a normalization layer. The third reveals all the edge cases that were missed earlier. ## When Direct Integration Makes Sense, and When It Does Not **Makes sense when:** - You are building an internal tool only for Garmin users - You have no plans to add other providers - You have time for Partner Program approval and handling OAuth 1.0 and webhook infrastructure **Starts to not make sense when:** - You plan to support more than one provider now or in the future - You want to build intelligent features (sleep score, recovery, trend analysis) rather than just displaying raw data - Time to implementation is a constraint Based on experience across dozens of healthtech projects, handling a single provider from scratch takes between 6 and 12 months of engineering time. Each additional provider adds less, but the normalization layer between them has a fixed cost that grows with every edge case you discover in production. ## Open Wearables as a Ready-Made Integration Layer [Open Wearables](https://openwearables.io/integrations/garmin) is an open-source platform for aggregating wearable device data. MIT license, self-hosted, zero per-user fees. Garmin is one of the supported providers. The platform also supports Polar, Suunto, Whoop, Oura, Strava, Fitbit, Apple HealthKit, Samsung Health, and Google Health Connect. Instead of handling OAuth 1.0 directly, you get a single unified data model: - **EventRecord** with EventRecordDetails: activities with aggregated values and timestamps - **DataPointSeries:** continuous data (heart rate, cadence) as normalized series - **PersonalRecord:** static user data Deduplication and normalization across providers are built in. When a user has both a Garmin and Apple Health syncing the same run, it will not appear twice in your data. Garmin webhook registration is handled by OW. You do not need to set up separate webhook infrastructure for Garmin; incoming data arrives through the same normalized API as other providers. Setup: ``` git clone https://github.com/the-momentum/open-wearables cd open-wearables cp .env.example .env # Add your Garmin Client ID and Client Secret docker compose up -d make init ``` First API call after connecting a Garmin account through OAuth: ``` curl -H "X-API-Key: YOUR_API_KEY" \ http://localhost:8000/api/v1/workouts ``` The response structure is the same regardless of whether the workout came from Garmin, Polar, or any other provider. Your application code does not branch on provider. If you need more than raw data, the platform also includes open algorithms for sleep score, recovery, HRV, and VO2 max. Every algorithm is in the repository, readable and modifiable. ## Related articles - [How to sync wearable data from multiple devices](https://openwearables.io/blog/how-to-sync-wearable-data-from-multiple-devices) - [How to normalize wearable data across providers](https://openwearables.io/blog/how-to-normalize-wearable-data-across-providers) - [What wearable app development actually looks like in 2026](https://openwearables.io/blog/what-wearable-app-development-actually-looks-like-in-2026) - [Wearable API integration: comparing SaaS, custom build, and open source](https://openwearables.io/blog/wearable-api-integration-saas-custom-build-open-source) ## FAQ ### Does Garmin require my users to have a Garmin Connect account? Yes. The Garmin Health API reads from Garmin Connect. Your users must have a Garmin Connect account and connect it to your application through the OAuth flow. Data syncs when they sync their device to Garmin Connect, which on most devices happens over Bluetooth to the Garmin Connect app on their phone. ### Does Open Wearables handle Garmin's webhook delivery? Yes. OW registers and manages Garmin webhook endpoints. You do not need to set up separate webhook infrastructure for Garmin; data arrives through the same normalized API as other providers. ### How long does Garmin Partner Program approval take? The Garmin Connect Developer Program is currently not accepting new applications. The official access request form shows: "Stay tuned for more updates on the program." Check the current status at garmin.com/forms/GarminConnectDeveloperAccess before planning your integration timeline. This is the most unpredictable part of any Garmin integration plan. ### What data does Garmin not expose through the Health API? Not all data visible in the Garmin Connect app is available through the Health API. Real-time streaming data (live workouts) and some advanced metrics from newer sensors may not be available, or may require specific partnership tiers. Check the Garmin Health API documentation at developer.garmin.com for the current scope of available data types. ### Can I fetch historical data after a user first connects? Backfill availability depends on the data type and your Garmin partnership agreement. Check the current scope at developer.garmin.com, as this varies by partnership tier. New data arrives via webhook going forward after the initial connection. ### What happens when a user connects both Garmin and another device that records the same activity? Open Wearables stores records from each provider separately, deduplicated by external ID within a provider. A run recorded on a Garmin watch and synced to Strava will produce two records. Merging them is application-level logic, because the definition of the same activity depends on your use case. ## Keep reading Garmin · Oct 23, 2026 · 4 min read ### Garmin Connect Developer Program reopened: what changes for your integration Garmin reopened the Connect Developer Program with Personal, Starter and Enterprise tiers. Each company now holds its own app and credentials. Here is what that means for delivery, backfill, AI use and moving an existing integration. Garmin · May 6, 2026 · 11 min read ### Garmin Connect API: developer guide for activities and health metrics Garmin's Health API uses push-based delivery and OAuth 1.0a, covering 100+ sport types, GPS, Body Battery, HRV, sleep and more. Here's what building with it actually requires. Garmin · May 6, 2026 · 7 min read ### Garmin API push notifications: how callback sync works Garmin's Health API pushes data to your callback URLs when users sync their devices. Here's how the system works end-to-end and what reliable implementation requires. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/garmin-connect-developer-program-reopened # Garmin Connect Developer Program reopened: what changes for your integration [All posts](https://openwearables.io/blog) [Garmin](https://openwearables.io/blog/category/garmin) Open Wearables Team · Oct 23, 2026 · 4 min read Garmin reopened the Garmin Connect Developer Program on 21 October 2026. It had been closed to new applications for most of the year. Teams that had Garmin on their roadmap can apply again. This post covers the parts that affect your integration. It looks at how the tiers deliver data, the rule on credentials, what the updated agreement says about AI, and how to run Garmin on your own app in Open Wearables. ## The tiers, seen from the integration side Garmin now lists three access levels. Personal gives an individual access to their own Garmin Connect data, pulled on request. It is meant for analysing your own data and is not a route for an app with users. Starter is described by Garmin as the starting point for organisations building apps. Data is delivered by push only. Historical data is not included, and user capacity is limited. Press reports put the limit at 1,000 connected users and say Starter is free. Enterprise is for companies operating at scale. It adds ping/pull delivery next to push, at least one month of historical data, unlimited users and technical support. Garmin describes the commercial terms as tailored to each company. According to press reports, there is an entry fee credited against a bill for monthly active users, and billing starts on 1 April 2027. The tier you need depends on onboarding more than on volume. A new user on Starter starts with an empty history, and data arrives from the moment they connect. If your product shows a new user their past weeks on day one, you need the backfill that comes with Enterprise. ## Your app, your credentials Under the program, every company registers its own app with Garmin and receives its own client ID and secret. Garmin's developer agreement does not allow passing the keys or the data to a third party without Garmin's written permission. Garmin has said this requirement is not new. It now applies to everyone coming through the reopened program. Strava has a similar rule. Its API agreement, in force since 1 June 2026, says a developer may not share an API token with any other developer or third party, or use it for more than one application. In practice, if your Garmin connection runs through another company's registration, check whether that company has Garmin's written permission. If it does not, plan to register your own app and move your users onto it. ## AI and the updated agreement The revised agreement rules out using Garmin data to train or improve your own AI models. Our reading is that running an existing model on one user's data to answer that same user remains possible with the user's consent and an AI transparency statement. Fine-tuning a model on your user base is out of scope. This is our reading and not legal advice. Check the current agreement with your own counsel before you ship an AI feature on Garmin data. ## Running Garmin on your own app in Open Wearables Open Wearables runs in your infrastructure, so the Garmin connection is configured with your own credentials from the start. Momentum never holds your keys and never sees your data. The setup has four steps. Apply to the Garmin Connect Developer Program under your organisation's name and register your app. Add the client ID and secret to your deployment's environment configuration. Point Garmin at your deployment's callback endpoint, which receives the data Garmin pushes. Then test the OAuth flow with a test account and confirm data arrives. Open Wearables handles the parts that are tedious to build yourself. It runs the OAuth consent flow and the token lifecycle. It hosts the callback endpoint, and the code for it is in the repository. It also coordinates backfill requests, because Garmin runs backfill as a request-and-wait chain and does not allow concurrent backfills on one account. ## Moving an existing integration onto your own app If your users currently connect through someone else's Garmin registration, the move has two sides. On your side, you register your own app and configure it in your deployment. On your users' side, each person connects Garmin again through your app's consent screen, because their existing authorisation belongs to the other registration. Treat the reconnection as part of the product. Tell users why they are being asked, keep it to one tap from the screen where they see their Garmin data, and track who has not reconnected after a week. ## What Open Wearables does not do Open Wearables does not grant Garmin access and does not replace Garmin's approval. You apply to Garmin yourself, and the relationship is between your organisation and Garmin. Open Wearables is the software you run so that your approved connection works next to Apple Health, Oura, Whoop and the other sources your users connect, behind one API in your own infrastructure. ## Open Wearables Open Wearables is an open-source platform that connects your application to wearable and health data providers through a single API. One normalized data model, multi-provider support in a single self-hosted deployment, MIT licensed, and health intelligence built in: normalized recovery, sleep, activity and biometric data ready for your product layer. We offer custom deployment and integration support through Momentum. If your team needs help getting to production faster, we can set up and configure Open Wearables as part of a managed engagement. [Let's talk](https://www.themomentum.ai/lets-talk). [Book a demo](https://openwearables.io/book) to see how Open Wearables fits your use case. ## Garmin integration View the full [Garmin integration documentation](https://openwearables.io/integrations/garmin) on Open Wearables. ## See related articles - [Garmin Connect API: developer guide for activities and health metrics](https://openwearables.io/blog/garmin-connect-api-developer-guide-activities-health-metrics) - [Garmin API push notifications: how callback sync works](https://openwearables.io/blog/garmin-api-push-notifications-how-callback-sync-works) - [How to integrate Strava without building OAuth from scratch](https://openwearables.io/blog/how-to-integrate-strava-without-building-oauth-from-scratch) ## Keep reading Garmin · Jul 21, 2026 · 8 min read ### Garmin Connect API: What You Can Fetch and How to Do It Faster The Garmin API gives you access to workouts, health metrics, and device data. Here is what you can retrieve, how the OAuth 1.0 flow works, and when it makes sense to use a ready-made integration layer instead of building from scratch. Garmin · May 6, 2026 · 11 min read ### Garmin Connect API: developer guide for activities and health metrics Garmin's Health API uses push-based delivery and OAuth 1.0a, covering 100+ sport types, GPS, Body Battery, HRV, sleep and more. Here's what building with it actually requires. Garmin · May 6, 2026 · 7 min read ### Garmin API push notifications: how callback sync works Garmin's Health API pushes data to your callback URLs when users sync their devices. Here's how the system works end-to-end and what reliable implementation requires. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/getting-apple-health-data-into-your-backend # Getting Apple Health data into your backend [All posts](https://openwearables.io/blog) [Apple Health](https://openwearables.io/blog/category/apple-health) Open Wearables Team · May 6, 2026 · 6 min read ## Key takeaways - There is no server-side Apple Health API; your iOS app must read HealthKit data on device and upload it to your backend - The full pipeline requires HealthKit entitlement, permission handling, query logic, background delivery, and a backend endpoint - Observer queries combined with enableBackgroundDelivery let your app sync new data without the user opening it - Change token patterns are not available in HealthKit; track sync position using timestamps stored locally - Open Wearables provides an iOS SDK that handles the full pipeline including permissions, background sync and normalized upload ## Introduction For developers who primarily work in backend systems, Apple Health integration involves a context switch that is easy to underestimate. The challenge is not the data model or the metrics HealthKit exposes. The challenge is that everything you would normally handle server-side has to be implemented client-side in Swift, embedded in an iOS app that must handle background execution constraints, permission complexity and upload reliability. This guide covers the complete pipeline from HealthKit to your backend: what you need to build at each layer, the implementation patterns that work reliably in production, the edge cases that trip up most implementations, and how Open Wearables removes most of this work for teams building multi-provider health applications. ## What you are building The pipeline from HealthKit to your backend has five distinct layers, each with its own implementation requirements. First, your iOS app needs the HealthKit entitlement, which requires an Apple Developer Program membership and explicit enablement in the Xcode project capabilities. Without this entitlement, all HealthKit API calls fail silently at runtime. Second, you need the permission request flow. HealthKit permissions are granted per data type. You must specify which types you want to read, present the system permission sheet to the user, and handle partial grants gracefully since users can approve some types and deny others. Third, you need query logic for each data type you want to sync. HealthKit queries are asynchronous, type-specific and require specifying predicates to filter by date range. Reading heart rate data uses different sample types than reading sleep records or workout objects. Fourth, you need background delivery. Observer queries combined with enableBackgroundDelivery allow iOS to wake your app when new HealthKit data arrives, even when the app is not in the foreground. This is the mechanism that makes automatic sync possible without requiring users to open the app. Fifth, you need reliable upload to your backend. The background wake window is limited. Upload logic must be fast, handle network failures gracefully, and track sync position so you never re-upload data that has already been sent. ## Permission request strategy The HealthKit permission sheet presents all requested data types to the user at once. How you structure this request significantly affects authorization rates. Request permissions at the moment they are contextually relevant, not automatically at app launch. A user who has just completed onboarding and understands what your app does is far more likely to grant permissions than a user who sees a permissions sheet the first time they open the app before they have any context. Explain why you need each type before triggering the system sheet. HealthKit provides a NSHealthShareUsageDescription key in your Info.plist for a general explanation, but in-app explanations tailored to your specific use case are more effective. "We read your sleep data to calculate recovery recommendations" is more compelling than the generic message many apps display. Request only the data types your product actually uses. Each type in the permission sheet is another thing the user has to evaluate and potentially reject. Over-requesting permissions reduces authorization rates and erodes user trust. ## Observer queries and background delivery The observer query is the mechanism that makes background sync work. You register an observer for a specific HealthKit sample type, and iOS wakes your app when new samples of that type are added to the HealthKit store, even when the app is backgrounded or not running. The critical pairing is HKObserverQuery with enableBackgroundDelivery. The observer query alone only fires when the app is active. Enabling background delivery tells iOS to wake the app in the background when new data arrives. The frequency parameter (immediate, hourly, daily) controls how often background delivery can occur. For most health data types, hourly or daily is appropriate. For workout completion events where you want near-real-time sync, immediate delivery is reasonable. When your observer fires, you have limited execution time. Query for new samples since your last sync timestamp, serialize the results, and upload to your backend in a single batch. Store the sync timestamp locally using UserDefaults after a successful upload so the next observer fire knows where to resume. ## Upload architecture The upload from device to backend needs to be reliable in unreliable network conditions. Users sync HealthKit data at unpredictable times including right after a workout when they may have intermittent connectivity. Use URLSession with a background session configuration for uploads. Background URLSession can complete uploads even after your app is suspended, which is important for the limited execution window of background delivery. The session delegate handles completion events, including failures, which your app can receive the next time it is active. On the backend, design your endpoint to accept batch payloads and process them idempotently. HealthKit samples have unique identifiers (UUID) that you should include in your upload payload. Your backend can use these as idempotency keys to handle duplicate uploads gracefully, which will happen when a user's network connection drops mid-upload and the SDK retries. ## Common edge cases Multiple sources for the same data type. HealthKit aggregates data from Apple Watch, iPhone, and third-party apps. A user who has both Apple Watch and a Whoop might have heart rate data in HealthKit from both devices. Decide how to handle source priority in your normalization layer. Using HKSource metadata on samples lets you filter by device type if you need to. Missing Apple Watch. Many HealthKit data types require Apple Watch. iPhone-only users will have step count and manually entered data but not continuous heart rate, sleep staging or SpO2. Build your app to degrade gracefully and show what is available rather than displaying empty states for types that require hardware the user does not have. Permission revocation. Users can revoke HealthKit permissions in iOS Settings without your app knowing. Your next query for a revoked type returns empty data rather than an error. If a user's data drops to zero unexpectedly after previously syncing successfully, surface a prompt to check permissions. Large historical datasets. A user with five years of Apple Watch heart rate data has millions of samples. For initial backfill, process in time-window chunks (one week at a time) rather than querying the entire history at once to avoid memory pressure on the device. ## Open Wearables Open Wearables is an open-source platform that connects your application to wearable and health data providers through a single API. One normalized data model, multi-provider support in a single self-hosted deployment, no per-user fees, MIT licensed, and health intelligence built in: normalized recovery, sleep, activity and biometric data ready for your product layer. We offer custom deployment and integration support through Momentum. If your team needs help getting to production faster, we can set up and configure Open Wearables as part of a managed engagement. [Let's talk](https://www.themomentum.ai/lets-talk). [Book a demo](https://openwearables.io/book) to see how Open Wearables fits your use case. ## Apple Health integration View the full [Apple Health integration documentation](https://openwearables.io/integrations/apple-health) on Open Wearables. ## See related articles [Apple HealthKit API: What Data You Can Access and How](https://openwearables.io/blog/apple-healthkit-api-what-data-you-can-access-and-how) [Google Health Connect Integration: Android Health Data for Developers](https://openwearables.io/blog/google-health-connect-integration-android-health-data-for-developers) [How to Access Google Health Connect Data in Your Backend](https://openwearables.io/blog/how-to-access-google-health-connect-data-in-your-backend) ## Keep reading Apple Health · Jun 5, 2026 · 4 min read ### How to integrate Apple Health API into your backend There is no Apple Health API in the traditional sense. Learn how Open Wearables SDK-based approach gets HealthKit data into your backend with token-based auth and XML import. Apple Health · May 20, 2026 · 4 min read ### How to integrate Apple Health data into your app A practical apple health integration guide using Open Wearables. Learn the two paths: mobile SDK for real-time background sync and XML import for historical HealthKit exports. Apple Health · May 4, 2026 · 7 min read ### Apple HealthKit API: what data you can access and how HealthKit is an on-device framework, not a remote API. There is no server-side Apple Health endpoint. Here's what's available, how permissions work, and what building an integration really requires. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/google-casa-oauth-verification-health-apps # Google CASA and OAuth Verification for Health Apps [All posts](https://openwearables.io/blog) [Google Health API](https://openwearables.io/blog/category/google-health-api) Open Wearables Team · Aug 12, 2026 · 10 min read ## Key Takeaways - The Google Health API requires two separate things: one-time OAuth app verification by Google's Trust and Safety team, and an ongoing, accredited third-party CASA security assessment for restricted scopes. - The trigger is sensitive or restricted scopes combined with more than 100 users. Below that threshold you can skip verification, but every user sees an "unverified app" warning at sign-in. - CASA costs $500 to $4,500 depending on tier, takes two to six weeks, and renews annually from the date your Letter of Validation is approved. - Whoever owns the Google OAuth client carries the assessment. Routing through a third-party integration layer, self-hosted or SaaS, does not move that responsibility off your organization. - Reading the same data on-device through Health Connect (Android) or Apple Health (iOS) avoids Google's restricted-scope verification entirely, at the cost of needing your own mobile app and going through its own app store review. If you are moving health data off Fitbit's API before it shuts down in September 2026, the natural landing spot is the Google Health API. It is the successor Google points developers toward, it aggregates Fitbit, Pixel, and other connected sources, and it is a straightforward REST API with no SDK required. Then you request your first restricted scope and Google asks you to complete OAuth app verification and an annual CASA security assessment, and the conversation changes shape. This is not a Google Health API quirk. It is how Google treats any app requesting sensitive or restricted data on its platform, and it applies whether you are calling the API directly or through a layer like Open Wearables. What follows is what that process actually involves, what it costs, and where the responsibility genuinely sits. ## Two Different Things: OAuth Verification and CASA Google treats access to sensitive and restricted scopes as two separate checkpoints, not one. OAuth app verification is a review by Google's Trust and Safety team. They look at your app's identity, every scope you request, and your justification for needing it. They also require an in-app disclosure at the point of consent, not just a line in your privacy policy. This is a one-time gate to get your app recognized rather than flagged. CASA (Cloud Application Security Assessment) is a separate, ongoing requirement layered on top for restricted scopes, which cover most of what the Google Health API exposes. It is a security assessment performed by an accredited third-party lab against the OWASP Application Security Verification Standard (ASVS). A self-scan is no longer accepted on its own. You come out the other side with a Letter of Validation, which you then submit to Google. Most teams hear "Google verification" and picture a form. It is closer to a compliance audit with a named external assessor and a formal deliverable. ## What Triggers It, and What Happens If You Skip It The trigger is the combination of scope sensitivity and user count. Apps requesting sensitive or restricted scopes with more than 100 users need verification. Under 100 users, you can skip it, which is fine for a pilot and not viable for production, because every user still sees an "unverified app" warning screen at sign-in. That screen alone is enough to kill trust in a health app, particularly one embedded in a clinical workflow. ## What It Costs and How Long It Takes Google sets the assessment tier based on your data sensitivity and scale, not a number you pick. The two tiers that matter for most health apps: - Tier 2: two to three weeks - Tier 3: four to six weeks Cost runs from $500 to $4,500, paid to the assessor, with more sensitive data and larger scale pushing you toward the top of that range. The assessment is not a one-time cost. It renews annually from the date your Letter of Validation is approved. If you are building on Google Health API for a product with real clinical or health-plan distribution, plan for the upper end of both the cost range and the timeline, and sequence the verification work to run alongside your build rather than gating launch behind it. ## Who Actually Owns the Assessment This is the part that surprises teams evaluating a wearable data platform, self-hosted or otherwise: going through a third-party integration layer does not move the assessment off you. The verification and CASA requirement attach to whoever owns the Google OAuth client. The scopes belong to your app, so Google assesses your app and your organization, regardless of what infrastructure sits behind the OAuth flow. There is no arrangement with Open Wearables where a vendor holds the client on your behalf and inherits the audit, since it is self-hosted and the OAuth client is yours by design. This is worth being precise about, because it cuts both ways: - Keeping your own OAuth client (which is what happens when you self-host something like Open Wearables) means data flows from Google straight into your environment with nobody in the middle holding a copy of it. The cost of that is that the assessment sits with you. - Using a SaaS aggregator that holds the OAuth client itself can mean the verification paperwork is technically theirs, but you inherit their scope set and their data handling practices, and you have no direct relationship with Google about your own users' data. For anything embedded in an EHR or handling PHI, that trade is usually the wrong one, since you lose visibility into exactly what the aggregator is doing with your patients' data on the other side of their client. Neither path makes CASA optional. It changes who is answering the assessor's questions and who controls the answers. ## What CASA Actually Tests: The Deletion Requirement One of the concrete things CASA verifies is whether your app can delete a user's data on request, so it is worth being specific about what that looks like in practice rather than treating it as a checkbox. In Open Wearables, deleting a user removes every stored data type for that user: records, timeseries, archived data, and derived scores, and it deregisters the OAuth connection with each connected provider in the same operation. There is also a narrower, provider-scoped version: you can wipe everything held for a single provider and revoke that specific connection while leaving the rest of the user's history intact. That provider-scoped path has a nuance worth confirming with the team before an assessor finds it for you rather than treating it as settled. Session-based scores (tied to a single sleep session, for example) are more likely to trace cleanly back to the provider that produced them and disappear when that provider is disconnected. Scores computed from a rolling window across whichever sources were connected at the time are the harder case, and may not cleanly attribute to a single disconnected provider. If your deletion request is scoped to "delete this user," this distinction does not affect you, since full deletion clears everything regardless. Because Open Wearables is open source, this is not something you have to take on faith. Your own security reviewers can read the deletion implementation directly, which tends to be the most useful property of building an evidence package on a self-hosted stack: every claim points at code your team can inspect rather than a vendor's word. ## What a Platform Like Open Wearables Can and Cannot Do for You The assessment itself has to come from an accredited third-party lab. Nobody providing your integration layer can be that lab, and be skeptical of anyone who implies otherwise. What sits upstream of the lab is where help is genuinely useful: - The evidence package: architecture and data-flow documentation, per-scope justifications, and retention/deletion documentation in the form assessors expect - Hardening the deployment against the ASVS controls the assessment tests, before the lab finds gaps rather than after - The in-app disclosure and consent flow, which is a common rejection reason and is inexpensive to get right up front - Remediation on whatever the assessor raises, so findings do not sit unresolved in your backlog None of this replaces the assessment. It reduces the odds of a failed first pass and shortens the time between opening the process and getting your Letter of Validation. ## The Alternative That Skips Verification Entirely There is a route that avoids Google's restricted-scope verification process altogether: reading the same underlying data on-device instead of through the cloud API. On Android, Fitbit and other apps write into Health Connect, and reading from that on-device layer does not touch Google's restricted scopes at all. The equivalent on iOS is Apple Health. Data coverage broadly overlaps what the cloud API exposes, and in places goes wider, since Health Connect aggregates from more sources than just Fitbit and Pixel. This is a real architectural choice, not a shortcut, and it comes with its own costs. It means shipping a mobile app on the user's device under your own brand, since the SDK has to run somewhere the user's data already lives. It adds a mobile app review process of its own (App Store or Play Store) on top of whatever else you are shipping. And it changes your product's install and onboarding flow: instead of a web-based OAuth consent screen, users need your app installed and Health Connect or Apple Health populated with their data before you can read anything. Worth a note on maturity: neither path has been rigorously battle-tested at large production scale yet, since both are relatively new. Treat the on-device route as a real option to evaluate rather than an automatic default, and confirm current maturity and data-type coverage for your specific use case with the team building it before committing engineering time to it. Which route fits depends on what your existing product looks like. If you already have a mobile app your users install, the on-device path is worth evaluating for the compliance cost it avoids. If your product is a web or backend service with no existing mobile footprint, standing up a mobile app purely to avoid CASA is its own significant scope of work, and the cloud OAuth path, verification included, is often the more pragmatic one. ## The Decision, In Short Moving off Fitbit's API means either the Google Health API or the on-device Health Connect/Apple Health path, and the Google Health API means OAuth verification plus annual CASA if you are past the pilot stage. That is true regardless of what sits behind your OAuth client. What changes based on your infrastructure choice is how much of the evidence package, hardening, and deletion behavior you have to build yourself versus what is already implemented and auditable in the platform you are building on. If you are early in that decision, [see how Open Wearables handles the Google Health API integration](https://openwearables.io/integrations/google-health), including the OAuth flow, webhook handling, and data model the CASA evidence package would need to document. ## See related articles [Google Health API: A Practical Guide to Getting Started](https://openwearables.io/blog/google-health-api-practical-guide-getting-started) [Google Health API and Google Health Connect: What's the Difference](https://openwearables.io/blog/google-health-api-and-google-health-connect-difference) [Fitbit Web API Shutdown 2026: Migration Guide](https://openwearables.io/blog/fitbit-web-api-shutdown-2026-migration-guide) [Fitbit Alternatives for Developers](https://openwearables.io/blog/fitbit-alternatives-for-developers) ## FAQ ### What is the difference between OAuth verification and CASA? OAuth app verification is a one-time review by Google's Trust and Safety team of your app's identity, scopes, and consent flow. CASA is a separate, ongoing security assessment by an accredited third-party lab against the OWASP ASVS standard, required for restricted scopes, and renewed annually. ### Does going through Open Wearables get me out of Google's CASA requirement? No. The verification and CASA requirement attach to whoever owns the Google OAuth client and requests the scopes, which is your app regardless of what integration layer sits behind it. Self-hosting Open Wearables means you keep your own OAuth client, so the assessment sits with your organization. ### How much does a CASA assessment cost and how long does it take? Cost runs from $500 to $4,500 depending on the tier Google assigns based on your data sensitivity and scale. Tier 2 assessments take two to three weeks, Tier 3 takes four to six weeks. The assessment renews annually from the date your Letter of Validation is approved. ### What happens if I skip verification? Apps under 100 users can operate without verification, which works for a pilot. Past that threshold, or with fewer users but the intent to scale, every user sees an "unverified app" warning screen at sign-in, which undermines trust in a health app. ### Does CASA check whether Open Wearables can delete user data? Yes, data deletion is one of the things CASA verifies. Open Wearables implements full user deletion (covering records, timeseries, archived data, and derived scores, plus deregistering provider OAuth connections) and a narrower provider-scoped deletion that revokes a single connection while preserving the rest of a user's history. ### Is there a way to avoid the Google Health API verification process entirely? Yes. Reading the same underlying data on-device through Health Connect (Android) or Apple Health (iOS) does not touch Google's restricted cloud scopes, so it avoids OAuth verification and CASA. It requires your own mobile app and its own app store review process, and is a less battle-tested path at scale than the cloud API today. ## Keep reading Google Health API · Aug 12, 2026 · 6 min read ### Google Health API: A Practical Guide to Getting Started A step-by-step walkthrough of setting up the Google Health API: Google Cloud project, OAuth client, environment variables, and verifying your first synced data. Google Health API · Aug 12, 2026 · 6 min read ### Google Health API and Google Health Connect: What's the Difference Google runs two separate products under the same name. Health Connect lives on the device and needs an SDK. The Google Health API is a cloud REST API and needs OAuth verification and CASA at scale. Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/google-health-api-and-google-health-connect-difference # Google Health API and Google Health Connect: What's the Difference [All posts](https://openwearables.io/blog) [Google Health API](https://openwearables.io/blog/category/google-health-api) Open Wearables Team · Aug 12, 2026 · 6 min read ## Key Takeaways - Google Health Connect and the Google Health API are two separate products that share overlapping data but work through fundamentally different architectures. - Health Connect is an on-device Android data store. It requires a mobile SDK, uses native Android permission screens instead of OAuth, and never touches Google's cloud scopes, so it sidesteps OAuth verification and CASA entirely. - The Google Health API is a server-side OAuth 2.0 flow that pulls data over REST from the cloud, no mobile app required, but its scopes are largely restricted, which brings OAuth verification and CASA into play at scale. - Open Wearables represents both under a single "google" provider identity, since they are two delivery mechanisms for overlapping data, but choosing between them is an architectural decision, not a config flag. - Many products end up using both: Health Connect for users with the mobile app installed, the Google Health API as a fallback or primary path for everyone else. Google currently runs two separate products with overlapping names and overlapping data, and the naming collision causes more confusion than almost anything else in this space. If you've been told your app needs "Google Health" and you're trying to figure out which one, this is the actual distinction. ## The One-Sentence Version Google Health Connect lives on the user's Android device and requires a mobile SDK. Google Health API is a cloud REST API and requires no SDK. They expose overlapping data but through fundamentally different architectures, and picking the wrong one shapes your entire integration. ## Google Health Connect: On-Device, SDK Required Health Connect is Google's on-device data store for Android. Wear OS, Samsung Health, Fitbit's Android app, and dozens of third-party apps all write into it, making it a genuine aggregation hub sitting on the phone itself. To read from it, you need a native Android SDK component in your app. There is no cloud API for Health Connect; the data lives on-device, and your integration has to run where the data is. That means: - Your app needs to be installed on the user's phone - Data availability depends on what is actually populated in Health Connect on that specific device - Permissions are handled through Android's native consent screens, not an OAuth flow - There is no server-side polling; sync happens through the SDK, on-device The upside is that this path does not touch Google's restricted OAuth scopes at all, so it sidesteps the verification and CASA process entirely. The trade-off is that it only works if you already have, or are willing to build, a mobile app under your brand. ## Google Health API: Cloud REST, No SDK, Broader Aggregation Google Health API is a newer, separate product: a server-side OAuth 2.0 flow that lets you connect a user's Google account and pull their data over REST from your backend, no mobile app or SDK required. It is also an aggregation layer, but at the account level rather than the device level. It surfaces data from every source connected to a user's Google Health account, including their phone's Health Connect store, their Fitbit account, Google Fit, and other connected apps, not just one device. Because it's a cloud API, it supports: - Polling on a schedule via standard REST calls - Notify-only webhooks, so you get pinged when data changes and fetch it in response - Reconcile and list fetch modes, letting you choose between one deduplicated total per metric or raw per-source data tagged by device The cost of this convenience is that most of its scopes are Google-restricted, which means OAuth app verification and, at meaningful scale, an annual CASA security assessment. Health Connect does not carry that requirement because it never touches those cloud scopes. ## Same "Google" Identity, Two Different Mechanisms If you're using a platform like Open Wearables, both paths are typically represented under a single "google" provider identity, since from a data-modeling perspective they're two delivery mechanisms for overlapping health data. That doesn't mean they're interchangeable at the integration level. Choosing between them is an architectural decision, not a config flag: - Where it runs: Health Connect runs on-device via the Android SDK. Google Health API runs in the cloud via server-side OAuth. - Requires a mobile app: Health Connect, yes. Google Health API, no. - OAuth verification / CASA: Not applicable for Health Connect. Required at scale for the Google Health API. - Sync model: Health Connect syncs through the on-device SDK. Google Health API uses polling plus webhooks. - Aggregation scope: Health Connect covers whatever is on that specific device. Google Health API covers whatever is connected to that Google account. ## Which One Should You Build Against If you already have a mobile app and want to avoid Google's cloud verification process, Health Connect is the lighter-weight and lower-compliance-overhead path, at the cost of needing your app installed and populated on the user's device before you get anything. If you're building a backend-first product, don't have (and don't want to build) a mobile app, or need webhook-driven updates rather than SDK-based sync, the Google Health API is the only path that fits, and the OAuth verification and CASA requirements are the cost of that convenience, not a sign you're doing something wrong. Many products end up wanting both: Health Connect for users who have the mobile app installed, Google Health API as a fallback or primary path for users who don't. That is exactly the kind of decision a unified provider layer is meant to absorb, so you're not maintaining two entirely separate Google integrations by hand. [The Google Health API integration](https://openwearables.io/integrations/google-health) covers the OAuth flow, reconcile/list modes, and webhook setup in detail. [The Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) covers the on-device SDK path. If you're weighing the CASA and verification cost of the API path specifically, [this breakdown of what that process actually involves](https://openwearables.io/blog/google-casa-oauth-verification-health-apps) is worth reading before you commit to either route. ## See related articles [Google Health API: A Practical Guide to Getting Started](https://openwearables.io/blog/google-health-api-practical-guide-getting-started) [Google CASA and OAuth Verification for Health Apps](https://openwearables.io/blog/google-casa-oauth-verification-health-apps) [Fitbit Web API Shutdown 2026: Migration Guide](https://openwearables.io/blog/fitbit-web-api-shutdown-2026-migration-guide) [Fitbit Alternatives for Developers](https://openwearables.io/blog/fitbit-alternatives-for-developers) ## FAQ ### Is Google Health Connect the same as the Google Health API? No. They are related but distinct products that share overlapping data. Health Connect is an on-device Android data store requiring a mobile SDK. The Google Health API is a separate, server-side OAuth flow that aggregates data at the account level, including Health Connect, Fitbit, and Google Fit data. ### Do I need a mobile app to use the Google Health API? No. The Google Health API is a cloud REST API with a server-side OAuth 2.0 flow, so you can pull data directly to your backend without shipping a mobile app. Google Health Connect requires a mobile app, since it only reads data on-device. ### Does Google Health Connect require OAuth verification or CASA? No. Health Connect uses native Android permission screens instead of an OAuth flow, so it never touches Google's restricted cloud scopes and sidesteps the verification and CASA process entirely. The Google Health API does require both at meaningful scale. ### Can I use both Google Health Connect and the Google Health API together? Yes, and many products do. Health Connect can serve users who have your mobile app installed, while the Google Health API covers everyone else or acts as the primary path for a backend-first product. A unified provider layer can absorb this so you're not building two separate Google integrations. ### Why do both show up as the same provider in some platforms? Because from a data-modeling perspective they are two delivery mechanisms for the same underlying health data. Platforms like Open Wearables represent both under a single "google" provider identity, even though the integration mechanics, sync model, and compliance requirements differ significantly between them. ## Keep reading Google Health API · Aug 12, 2026 · 6 min read ### Google Health API: A Practical Guide to Getting Started A step-by-step walkthrough of setting up the Google Health API: Google Cloud project, OAuth client, environment variables, and verifying your first synced data. Google Health API · Aug 12, 2026 · 10 min read ### Google CASA and OAuth Verification for Health Apps Moving to the Google Health API means OAuth verification and an annual CASA security assessment. Here is what it costs, how long it takes, and why self-hosting does not move the responsibility off your organization. Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/google-health-api-practical-guide-getting-started # Google Health API: A Practical Guide to Getting Started [All posts](https://openwearables.io/blog) [Google Health API](https://openwearables.io/blog/category/google-health-api) Open Wearables Team · Aug 12, 2026 · 6 min read ## Key Takeaways - The Google Health API is a server-side OAuth 2.0 flow that aggregates 24/7 metrics, workouts, and sleep from every source connected to a user's Google Health account, not just one device. - You need three things before you start: a Google Cloud project with the Health API enabled, OAuth client credentials, and a registered redirect URI. Webhooks additionally require a service account. - Setup is five steps: enable the API and create an OAuth client, configure environment variables, connect a user through OAuth, trigger a sync, and verify data comes back. - Most Google Health API scopes are restricted rather than merely sensitive, which means OAuth app verification and, past 100 users, an annual CASA security assessment before going to production. - The default configuration (reconcile mode, raw granularity) returns app-accurate, deduplicated totals out of the box, so most integrations don't need to touch the fetch mode settings at all. The Google Health API is Google's cloud OAuth layer for health data, the successor Google points developers toward as it retires the legacy Fitbit Web API in September 2026. It aggregates data from every source connected to a user's Google Health account: Fitbit, Google Fit, Health Connect on their phone, and other connected apps, all through one OAuth connection and no mobile SDK. This is a practical, step-by-step walkthrough of getting from zero to a working integration, using Open Wearables as the reference implementation. The mechanics (Google Cloud setup, OAuth client, scopes) apply whether or not you use Open Wearables specifically. ## What You Need Before You Start Four things, and you can gather all of them before writing any code: - A Google Cloud project with the Health API enabled - OAuth client credentials (Client ID and Secret) with the Google Health scopes - A redirect URI registered in your OAuth client - If you plan to use webhooks, a service account for project-level subscriber registration You also need a Google Cloud project to work from, and access to the Health API enabled on it. ## Step 1: Enable the Health API and Create an OAuth Client In the Google Cloud Console, select your project and enable the Health API: ``` gcloud config set project YOUR_PROJECT_ID gcloud services enable health.googleapis.com ``` Then create an OAuth 2.0 Client ID (Web application) under APIs & Services, Credentials, and add your server-side callback as an Authorized redirect URI. For local development, that's: ``` http://localhost:8000/api/v1/oauth/google/callback ``` One thing to get right immediately: store the Client Secret securely the moment you create it. Google shows it to you once, and there is no way to retrieve it again afterward. ## Step 2: Configure Credentials Add the following to your.env file: ``` #--- Google ---# GOOGLE_CLIENT_ID=your-google-client-id GOOGLE_CLIENT_SECRET=your-google-client-secret GOOGLE_DEFAULT_SCOPE=openid email https://www.googleapis.com/auth/googlehealth.activity_and_fitness.readonly https://www.googleapis.com/auth/googlehealth.health_metrics_and_measurements.readonly https://www.googleapis.com/auth/googlehealth.nutrition.readonly https://www.googleapis.com/auth/googlehealth.sleep.readonly https://www.googleapis.com/auth/googlehealth.settings.readonly GOOGLE_USE_RECONCILE=true ``` Four variables matter here: - GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET are your OAuth credentials from step 1. - GOOGLE_DEFAULT_SCOPE is the space-separated list of Health API scopes to request. The value above is the full read-only set covering activity and fitness, health metrics, nutrition, sleep, and settings. - GOOGLE_USE_RECONCILE controls whether overlapping data from multiple sources gets merged into one app-accurate total (true, the default) or kept as raw per-device data (false). This only affects raw-granularity data; leave it at the default unless you specifically need per-device attribution. - DEFAULT_DATA_GRANULARITY (not shown above, defaults to raw) chooses between raw, hourly, or daily data resolution. One detail worth double-checking before you move on: the redirect URI is derived from your API_BASE_URL setting, and it has to match the Authorized redirect URI you registered on the OAuth client in step 1 exactly. A mismatch here is one of the most common reasons the OAuth flow fails silently. ## Step 3: Connect a User via OAuth With credentials configured, initiate the OAuth flow for a specific user. First, get the authorization URL: ``` curl -X GET "http://localhost:8000/api/v1/oauth/google/authorize?user_id={user_id}&redirect_uri=http://localhost:3000/users/{user_id}" \ -H "X-Open-Wearables-API-Key: YOUR_API_KEY" ``` Redirect the user to the returned authorization_url. They log in to Google and grant consent on Google's standard OAuth screen. Google then redirects back to your registered callback, where the backend exchanges the authorization code for tokens and stores the connection automatically. You don't need to handle the code exchange yourself. Verify the connection landed correctly: ``` curl -X GET "http://localhost:8000/api/v1/users/{user_id}/connections" \ -H "X-Open-Wearables-API-Key: YOUR_API_KEY" ``` You should see a connection with "provider": "google" and "status": "active". If the status is anything else, the OAuth exchange did not complete, and the redirect URI mismatch from step 2 is the first thing worth checking. ## Step 4: Sync Data An initial sync typically runs automatically right after a successful OAuth connection. To trigger one manually: ``` curl -X POST "http://localhost:8000/api/v1/providers/google/users/{user_id}/sync" \ -H "X-Open-Wearables-API-Key: YOUR_API_KEY" ``` ## Step 5: Verify the Integration End to End Fetch a synced 24/7 series, for example steps: ``` curl -X GET "http://localhost:8000/api/v1/users/{user_id}/timeseries/steps?start_date=2026-01-01T00:00:00Z&end_date=2026-02-01T00:00:00Z" \ -H "X-Open-Wearables-API-Key: YOUR_API_KEY" ``` If data comes back, the integration is working end to end: OAuth, sync, and data retrieval all confirmed. ## Before You Go to Production: Verification and CASA Getting the integration working technically is not the same as being ready for production traffic. Most Google Health API scopes are restricted rather than merely sensitive, and Google requires OAuth app verification plus, past 100 users, an annual CASA security assessment. Below that user threshold you can operate unverified, but every user sees an "unverified app" warning at sign-in, which is not something you want in a live product. This is worth planning for before launch, not discovering after. [The full breakdown of what CASA actually costs and who is responsible for it](https://openwearables.io/blog/google-casa-oauth-verification-health-apps) covers the timeline, cost, and what you can and cannot delegate to a platform like Open Wearables. ## If You Need Webhooks Everything above covers pull-based sync, which is enough for most integrations. If you want to be notified when a user's data changes instead of polling on a schedule, the Google Health API supports notify-only webhooks: a notification names the changed data type and time interval, and your backend fetches the actual data over REST in response. Setting this up requires a service account for project-level subscriber registration, which is a separate setup step from the OAuth flow above. ## See related articles [Google Health API and Google Health Connect: What's the Difference](https://openwearables.io/blog/google-health-api-and-google-health-connect-difference) [Google CASA and OAuth Verification for Health Apps](https://openwearables.io/blog/google-casa-oauth-verification-health-apps) [Fitbit Web API Shutdown 2026: Migration Guide](https://openwearables.io/blog/fitbit-web-api-shutdown-2026-migration-guide) [Fitbit Alternatives for Developers](https://openwearables.io/blog/fitbit-alternatives-for-developers) ## FAQ ### What do I need before setting up the Google Health API? A Google Cloud project with the Health API enabled, OAuth client credentials (Client ID and Secret), and a registered redirect URI. If you plan to use webhooks, you also need a service account for project-level subscriber registration. ### What scopes does the Google Health API use? The full read-only scope set covers activity and fitness, health metrics and measurements, nutrition, sleep, and settings, each as a separate googlehealth.*.readonly scope requested via a space-separated GOOGLE_DEFAULT_SCOPE value. ### What does GOOGLE_USE_RECONCILE do? It controls whether overlapping data from multiple connected sources gets merged into one deduplicated, app-accurate total (true, the default) or returned as raw per-device data (false). It only affects raw-granularity data; most integrations should leave it at the default. ### Why does my OAuth flow fail after the user grants consent? The most common cause is a mismatch between your configured API_BASE_URL (which derives your redirect URI) and the Authorized redirect URI registered on your OAuth client in Google Cloud Console. These have to match exactly. ### Do I need to handle Google's OAuth token exchange myself? No, if you're using Open Wearables. When Google redirects back to the registered callback, the backend exchanges the authorization code for tokens and stores the connection automatically. ### Do I need OAuth verification and CASA just to test the integration? No. Apps under 100 users can operate without Google's OAuth app verification, which is enough for development and testing. Verification and the annual CASA security assessment become necessary once you're serving real production users past that threshold. ## Keep reading Google Health API · Aug 12, 2026 · 6 min read ### Google Health API and Google Health Connect: What's the Difference Google runs two separate products under the same name. Health Connect lives on the device and needs an SDK. The Google Health API is a cloud REST API and needs OAuth verification and CASA at scale. Google Health API · Aug 12, 2026 · 10 min read ### Google CASA and OAuth Verification for Health Apps Moving to the Google Health API means OAuth verification and an annual CASA security assessment. Here is what it costs, how long it takes, and why self-hosting does not move the responsibility off your organization. Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/google-health-connect-integration-android-developers # Google Health Connect integration for Android developers [All posts](https://openwearables.io/blog) [Google Health Connect](https://openwearables.io/blog/category/google-health-connect) Open Wearables Team · Jun 7, 2026 · 4 min read ## Key Takeaways - Google Health Connect is a local, on-device platform, not a cloud API. Integration requires an Android SDK installed in the user's app. - Open Wearables Android SDK handles the full google health connect integration lifecycle: permissions, WorkManager background sync, token refresh, and encrypted credential storage. - Health Connect covers 30+ data types across all Android 10+ devices, including HRV, VO2 max, multi-stage sleep, blood glucose, blood pressure, and hydration. - Your backend never touches Health Connect directly. After sync, data is available through standard REST endpoints in canonical units. - On Android 14+, Health Connect comes pre-installed. On Android 10-13, users need to install it from the Play Store. - Open Wearables is MIT-licensed with no per-user fees. - You do not embed credentials in the mobile app. The SDK authenticates against your backend using tokens generated server-side. ## Why Google Health Connect Integration Is Not Like Other OAuth Flows Most health and fitness APIs follow a familiar pattern: redirect the user to a consent screen, receive an authorization code, exchange it for tokens, and start making API calls from your backend. Google Health Connect does not work this way. Health Connect is a local data platform that lives on the Android device. It was designed with on-device privacy in mind: data never leaves the device through Health Connect's own mechanisms. If you want it in your backend, your code must run on the device and push it there explicitly. Practical consequences: there is no server-to-server API, permissions are granted on the device (not in a browser), background sync needs to survive app restarts using WorkManager, and you handle all of this before your backend sees a single data point. Open Wearables handles that entire layer for google health connect integration. ## Health Connect vs Samsung Health: When to Use Which **Health Connect:** Works on all Android 10+ devices, 30+ data types, pre-installed on Android 14+. Provider ID: `"google"`. **Samsung Health:** Limited to Samsung devices, 20+ data types. Provider ID: `"samsung"`. For most apps targeting a general Android audience, Health Connect is the right choice. Open Wearables supports both through a unified interface, and you query the same REST endpoints regardless of which provider the user connected. ## What Open Wearables Android SDK Does for You Without Open Wearables, google health connect integration involves: adding the Health Connect SDK, building a permission request flow for each data type, writing WorkManager sync jobs with resume support, normalizing Health Connect formats, managing token refresh, and storing credentials securely. With Open Wearables, you add one dependency and call three SDK methods. The SDK internally: maps Open Wearables type IDs to Health Connect data type constants, runs background sync through WorkManager with resumable sessions, stores credentials in EncryptedSharedPreferences, handles 401 responses with automatic token refresh, and converts all data to canonical units (bpm, meters, Celsius, UTC). ## Backend Setup: Generating Tokens ``` POST /api/v1/users/{user_id}/token ``` Returns `access_token` and `refresh_token`. Pass these to the Android client. Never embed `app_id` or `app_secret` in the mobile app. ## Android SDK: Installation and Setup **Add the dependency:** ``` // settings.gradle.kts maven { url = uri("https://jitpack.io") } // build.gradle.kts implementation("com.github.the-momentum:open-wearables-android-sdk:0.5.0") ``` Requirements: `minSdk = 29`, `compileSdk = 36`, Kotlin 2.1.0+. **Initialize in your Application class:** ``` OpenWearables.init(context = this, baseUrl = "https://your-backend.example.com") ``` **Sign in and select the Health Connect provider:** ``` sdk.signIn(accessToken = accessToken, refreshToken = refreshToken) sdk.selectProvider("google") sdk.requestAuthorization( types = listOf("steps", "heartRate", "sleep", "oxygenSaturation", "vo2Max", "bloodGlucose") ) ``` **Start background sync:** ``` sdk.startBackgroundSync(syncDaysBack = 30) ``` ## Reading Data After Sync ``` GET /api/v1/users/{user_id}/timeseries GET /api/v1/users/{user_id}/events/workouts GET /api/v1/users/{user_id}/events/sleep ``` These endpoints return data in the canonical normalized format regardless of source provider. ## Android Version Considerations **Android 14+:** Health Connect is pre-installed. The permissions dialog appears as part of your app's normal flow. **Android 10-13:** Health Connect must be installed from the Play Store. Detect availability and prompt users to install it if not present using `HealthConnectClient.getSdkStatus()`. ## Quickstart ``` git clone https://github.com/the-momentum/open-wearables cd open-wearables docker compose up -d ``` API at `http://localhost:8000`. Auth via `X-Open-Wearables-API-Key`. MIT license, $0 per user. ## See Related Articles - [How to access Google Health Connect data in your backend](https://openwearables.io/blog/how-to-access-google-health-connect-data-in-your-backend) - [Google Health Connect integration: Android health data for developers](https://openwearables.io/blog/google-health-connect-integration-android-health-data-for-developers) - [How to integrate Apple Health data into your app](https://openwearables.io/blog/how-to-integrate-apple-health-data-into-your-app) - [How to sync wearable data from multiple devices](https://openwearables.io/blog/how-to-sync-wearable-data-from-multiple-devices) - [How to normalize wearable data across providers](https://openwearables.io/blog/how-to-normalize-wearable-data-across-providers) ## FAQ **Does Health Connect require an internet connection or a Google account?** No. Health Connect is an on-device platform. It does not require a Google account, and health data does not pass through Google's servers. **Do I need to handle Health Connect permission changes after initial setup?** Yes. Users can revoke individual permissions at any time. You should handle cases where sync fails due to missing permissions and present the `requestAuthorization()` flow again when appropriate. **What happens if the user does not have Health Connect installed on Android 10-13?** Health Connect will not be available. Use `HealthConnectClient.getSdkStatus()` to detect availability and deep-link to the Play Store listing. **Is the data synced in real time or on a schedule?** Sync runs on a schedule managed by WorkManager. It is not real-time. WorkManager respects Android's battery optimization policies. For most health use cases, periodic batch sync is appropriate. **Can I request only specific data types instead of all 30+?** Yes. The `requestAuthorization()` call takes an explicit list of type IDs. Request only the types your app actually uses to minimize friction and avoid Play Store review issues. ## Keep reading Google Health Connect · May 6, 2026 · 7 min read ### Google Health Connect integration: Android health data for developers Google Health Connect is Android's on-device health data hub, aggregating data from Wear OS, Galaxy Watch, Fitbit, Garmin and third-party apps. Here's how to build with it. Google Health Connect · May 6, 2026 · 7 min read ### How to access Google Health Connect data in your backend There is no Google server-side API for Health Connect. Your Android app must read data on device and upload it. Here's the complete pipeline from setup to production. Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/google-health-connect-integration-android-health-data-for-developers # Google Health Connect integration: Android health data for developers [All posts](https://openwearables.io/blog) [Google Health Connect](https://openwearables.io/blog/category/google-health-connect) Open Wearables Team · May 6, 2026 · 7 min read ## Key takeaways - Google Health Connect is an on-device data store, not a cloud API. Your Android app must read data on the device and upload it to your backend. - Health Connect aggregates data from multiple Android sources: Wear OS, Samsung Galaxy Watch via Samsung Health, Fitbit on supported devices, Garmin Connect app, and third-party fitness apps. - Permissions are granted per data type at the Android OS level, not via an OAuth consent screen. Users must approve each data type your app requests. - Change tokens enable efficient incremental sync by identifying which records have been added, modified or deleted since your last read. - WorkManager is the recommended approach for reliable background data sync from Health Connect on Android. - Open Wearables supports a companion upload architecture where your Android app syncs Health Connect data to the Open Wearables backend. ## Introduction Google Health Connect is Android's answer to Apple HealthKit: a system-level health data hub that aggregates biometric data from multiple apps and wearables into a single on-device store. Any Android app can write health data to Health Connect, and any app with appropriate permissions can read it. The practical consequence for developers is significant. A user with a Samsung Galaxy Watch, a Fitbit, and a Garmin watch (used for different activities) can have all their health data aggregated in Health Connect on their phone. Your application can read steps, sleep, heart rate, workouts and other metrics from all these sources through a single local API without managing separate cloud integrations for each wearable. The architectural catch is that Health Connect has no server-side API. There is no way to query a user's Health Connect data from your backend without an Android app intermediary. Your Android app must read the data locally and upload it to your backend. This is a fundamentally different integration pattern from server-side wearable APIs like Garmin or Polar. ## What Health Connect provides Health Connect organizes data into record types. Each record type has a defined schema. Available record types include steps, distance, calories (active and basal), heart rate (spot measurements and series), heart rate variability, sleep sessions with sleep stage details, exercise sessions with sport type and segment data, body weight, body fat percentage, oxygen saturation, respiratory rate, blood glucose (if contributed by a connected app), blood pressure, and several dozen others. Data availability depends on which apps have written to Health Connect on the user's device. A user whose Galaxy Watch syncs through Samsung Health will have Samsung's data in Health Connect. A user with a Garmin watch and the Garmin Connect app may have Garmin workout data in Health Connect if they have enabled the Health Connect integration within the Garmin app. The source of each record is available in the metadata. Records include a dataOrigin field identifying which app wrote the data. This allows you to filter or prioritize data from specific sources when multiple apps contribute overlapping data for the same time period. ## Permissions architecture Health Connect uses Android's runtime permission system. Each data type your app reads or writes requires a specific permission declared in your AndroidManifest.xml and requested at runtime. For example, reading heart rate requires android.permission.health.READ_HEART_RATE and reading sleep data requires android.permission.health.READ_SLEEP. Permission requests are shown to the user as a Health Connect consent dialog that lists each data type your app is requesting. This is separate from the standard Android runtime permissions flow. Only request the data types you actually use: users and app stores scrutinize broad health data permission requests. Permissions can be revoked by the user at any time through the Health Connect app or Android settings. Check permission status before each read operation rather than assuming previously granted permissions are still valid. Handle PermissionException gracefully by updating your UI to show which data types are unavailable and providing a path to request permissions again. ## Change tokens for incremental sync Health Connect provides a change token mechanism that enables efficient incremental syncing. A change token represents a point in time in the Health Connect data store. When you first sync, you request a change token after your initial data read. On subsequent syncs, you provide the previous change token and Health Connect returns only the records that have been added, modified or deleted since that token was issued. Change tokens are per data type. Maintain separate change tokens for each record type you sync (steps, heart rate, sleep sessions, exercise sessions, and so on). Store change tokens in your application's local database alongside the last sync timestamp. If a change token expires (Health Connect expires tokens after 30 days), fall back to a time-range query and obtain a fresh change token. The change token approach is strongly preferred over time-range polling because it avoids re-reading data that has not changed, which reduces battery usage and sync latency on the device. ## Background sync with WorkManager Health Connect data should be synced to your backend in the background, not only when the user opens your app. WorkManager is the recommended approach for background work on Android. It handles constraints (run only when the device has network connectivity), battery optimization, and retry logic automatically. Define a PeriodicWorkRequest to run your sync job on a schedule (every 15 minutes is the minimum WorkManager interval; once per hour is practical for most health apps). Your Worker class reads from Health Connect using the stored change tokens, serializes the data, and uploads it to your backend API. ``` val syncRequest = PeriodicWorkRequestBuilder( 1, TimeUnit.HOURS ) .setConstraints( Constraints.Builder() .setRequiredNetworkType(NetworkType.CONNECTED) .build() ) .setBackoffCriteria( BackoffPolicy.EXPONENTIAL, WorkRequest.MIN_BACKOFF_MILLIS, TimeUnit.MILLISECONDS ) .build() WorkManager.getInstance(context).enqueueUniquePeriodicWork( "health_connect_sync", ExistingPeriodicWorkPolicy.KEEP, syncRequest ) ``` In the Worker class, call the Health Connect SDK's readRecords method for each record type using the stored change token. Serialize the results as JSON and POST them to your backend endpoint. On a successful upload, store the new change token returned by Health Connect. On failure, let WorkManager retry the work using the exponential backoff policy. ## Handling multiple data sources Health Connect's aggregation of multiple apps creates a data deduplication challenge. If the user has both Samsung Health and a generic step counter app writing step data to Health Connect, you may receive overlapping step records for the same time periods. Use the dataOrigin field to implement source prioritization for your application. Define a source priority list for each record type. For exercise sessions, prefer the data from the wearable device app (Samsung Health, Garmin Connect) over generic third-party apps. For daily steps, prefer the dedicated wearable source. For sleep, prefer the most detailed sleep staging data source. Alternatively, use Health Connect's built-in aggregation queries, which aggregate data across sources for compatible record types (total steps, aggregate calories). This is simpler but provides less granular information than reading individual records. ## Open Wearables and Health Connect Open Wearables supports a companion Android app architecture for Health Connect integration. Your Android app reads Health Connect data using the patterns described above and uploads it to the Open Wearables backend API. The backend normalizes the incoming Health Connect data to the same schema used for server-side providers like Garmin, Polar and Whoop. This means Health Connect users and Garmin users in your application produce normalized health summaries through the same backend pipeline. Self-hosted, MIT licensed, no per-user fees. ## Faq ### Does Health Connect work on all Android devices? Health Connect requires Android 9 (API level 28) or higher. On Android 14 and higher, Health Connect is integrated into the operating system. On Android 9-13, it is available as a standalone app from the Google Play Store. Users on affected older Android versions need to install Health Connect separately. Build a check into your app that verifies Health Connect availability and guides users to install it if needed. ### How far back does Health Connect data go? Health Connect retains data for 30 days by default. Some devices and Android versions may retain data longer. Do not assume historical data beyond 30 days is available. For initial onboarding, query the full available window using a time range from 30 days ago to now and store the results in your backend. ### Can i write data back to Health Connect from my app? Yes. Health Connect supports both read and write operations. Your app can contribute data to Health Connect for the record types where you hold write permissions. Write permissions require separate permission declarations and separate user consent from read permissions. ### Does Google play require special review for Health Connect apps? Yes. Apps that read health data from Health Connect are subject to Google Play's sensitive data policy. You must complete a Health Connect permissions declaration during app submission, explaining your data usage. Apps that handle health data may require an extended review. Start the submission process early and have your privacy policy clearly address Health Connect data usage. ## Open Wearables Open Wearables is an open-source platform that connects your application to wearable and health data providers through a single API. One normalized data model, multi-provider support in a single self-hosted deployment, no per-user fees, MIT licensed, and health intelligence built in: normalized recovery, sleep, activity and biometric data ready for your product layer. We offer custom deployment and integration support through Momentum. If your team needs help getting to production faster, we can set up and configure Open Wearables as part of a managed engagement. [Let's talk](https://www.themomentum.ai/lets-talk). [Book a demo](https://openwearables.io/book) to see how Open Wearables fits your use case. ## Google Health Connect integration View the full [Google Health Connect integration documentation](https://openwearables.io/integrations/google-health-connect) on Open Wearables. ## See related articles [How to Access Google Health Connect Data in Your Backend](https://openwearables.io/blog/how-to-access-google-health-connect-data-in-your-backend) [Apple HealthKit API: What Data You Can Access and How](https://openwearables.io/blog/apple-healthkit-api-what-data-you-can-access-and-how) [Samsung Health API: Galaxy Watch Data for Developers](https://openwearables.io/blog/samsung-health-api-galaxy-watch-data-for-developers) ## Keep reading Google Health Connect · Jun 7, 2026 · 4 min read ### Google Health Connect integration for Android developers Google Health Connect is not a cloud API. It requires on-device Android SDK integration. Learn how Open Wearables handles the full Health Connect lifecycle. Google Health Connect · May 6, 2026 · 7 min read ### How to access Google Health Connect data in your backend There is no Google server-side API for Health Connect. Your Android app must read data on device and upload it. Here's the complete pipeline from setup to production. Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/hosted-wearable-api-to-open-wearables-migration-playbook # Moving from a hosted wearable API to Open Wearables: a migration playbook [All posts](https://openwearables.io/blog) [Guides](https://openwearables.io/blog/category/guides) Open Wearables Team · Oct 26, 2026 · 9 min read ## Key takeaways - Moving from a hosted wearable API to Open Wearables is usually a re-integration rather than a data migration. Your history stays where it is, and new data lands in your own Open Wearables deployment from the switch onwards. - Open Wearables runs in your own cloud account. The provider apps are registered in your name, and your product reads one standard schema from your own database. - The slowest step is rarely engineering. Provider credentials in your name can take a day or several weeks, so that work starts first. - Users reconnect once, through your own consent screen, because a connection belongs to the app that requested it. Open Wearables runs the connection flow and the token lifecycle. - Most teams run the hosted API and Open Wearables side by side, move users in batches, and switch the hosted API off only when the new path is proven. You can run the move yourself or with Momentum. ## Who this playbook is for You run a health or fitness product that reads wearable data through a hosted API today. It got you to market quickly, and it still works. But a question has moved up your roadmap: what would it take to hold the connection to our users' devices ourselves? The timing is not an accident. In October, Garmin reopened its Connect Developer Program with a clear access model: each company registers its own app and holds its own credentials. Strava's API agreement, in force since June, says a developer may not share its API token with any third party. Add an enterprise customer's security review or a residency requirement, and owning the data layer turns from an idea into a plan. This playbook walks through that plan for a move to Open Wearables, the open-source platform for wearable and health data that runs in your own cloud. It stays at the level of decisions and sequence, for product leads, CTOs and engineering managers. The technical detail lives in the Open Wearables documentation. ## What moving to Open Wearables actually changes Today, data travels from each provider through a hosted service into your product. The provider apps are registered to that service, the data sits on its schema in its cloud, and your product calls its API. After the move, data travels from each provider into your own Open Wearables deployment, in a cloud account and region you choose. The provider apps are registered in your name. Everything lands in one standard schema in your own database, with the original provider payload kept underneath if you want it, and your product reads it over the Open Wearables REST API or reacts to its webhooks. That is why this is usually a re-integration rather than a data migration. You are not exporting years of records and loading them somewhere else. You are building a second path for new data, proving it, and moving users onto it when you are ready. The history you already hold stays where it is. ## Five decisions to make before anyone writes code **1. Which providers have to work on day one.** List the sources your users actually connect through the hosted API today. The first Open Wearables deployment covers those; others can follow without changing how your product reads the data. **2. Who runs Open Wearables.** Your engineers can stand it up from the open-source repository, or Momentum can deploy it into your account and hand it over. The architecture is identical either way. The difference is speed and who carries the operational work afterwards. **3. Which cloud account and region.** If a customer contract or a regulator says where health data may sit, this is where you answer it, once. **4. Where users reconnect.** Each user authorises your app once. Decide where in your product that happens and what you tell them. It is a product decision as much as an engineering one. **5. What "done" means.** Agree the acceptance criteria up front: data on real accounts matches what each provider's own app shows, the parallel run has been stable for an agreed period, and an agreed share of users has moved across. ## The move, step by step **Step 1: Map what your product uses today.** Start with an architecture audit: which providers, which data types your features depend on, which events your product reacts to, and what has to keep working on the first day. Most products use a smaller slice of the hosted API than they think. The outcome is a written plan that maps each of those to the Open Wearables standard schema and webhooks. **Step 2: Apply for provider credentials in your name.** Each provider issues developer credentials to your organisation, and you apply for them directly. Some approve within a day, others take weeks, and it is the usual reason a launch slips. Start here and run everything else in parallel. If you already hold credentials for a provider, the slow part is behind you: bring the client ID and secret, and point them at your deployment. **Step 3: Deploy Open Wearables next to the hosted API.** Production and staging go into your own cloud account, defined as infrastructure code in your repository. Nothing about your current integration changes yet, and nobody's users are touched. **Step 4: Connect and validate on real accounts.** Connect a handful of test accounts per provider. Open Wearables runs each provider's connection flow and manages the tokens; your team compares what arrives with what the provider's own app shows. Provider quirks surface here, when they are easy to fix, rather than after launch. **Step 5: Point your product at Open Wearables.** Switch the parts of your product that read wearable data over to the Open Wearables API and webhooks, behind a flag if you can. Because every provider comes back in the same shape, adding a source later does not change the call. **Step 6: Move users across in batches.** Invite users to reconnect through your own consent screen, a cohort at a time. Watch the numbers, fix what surfaces, then widen the next batch. **Step 7: Switch off the hosted API.** When the new path is proven and the share of users you agreed has moved, retire the hosted integration. Keep a short window for stragglers, then close it. ## Reconnecting users without drama Reconnection is the part of the move your users actually see. A connection to Garmin, Oura or Whoop belongs to the app that requested it, so moving to provider apps registered in your name means each user authorises once more. Open Wearables handles the flow itself; the experience around it is yours. - **Tell them why.** One sentence is enough: you are moving their device connection into your own systems, and it takes a single tap. - **Ask in context.** Put the prompt on the screen where they already look at their device data, not in a settings menu. - **Keep it to one tap.** The provider's own consent screen does the rest, and your app should return them exactly where they were. - **Track who has not moved.** After a week, follow up with users who have not reconnected. After two, decide what happens to their old connection. Phone-based sources work differently. Apple Health, Health Connect and Samsung Health have no cloud API, so the Open Wearables mobile SDK reads the store on the phone with the user's permission and syncs to your deployment in the background. For those users the step is a permission prompt in your own app. ## What happens to historical data The history you already hold stays where it is, and your product can keep reading it. From the switch onwards, new data lands in your own Open Wearables deployment. When a user connects, Open Wearables requests history from each provider that offers it. How far back depends on the provider and, for some, on your access tier; for several providers the default is ninety days, and you can request a specific range yourself. For Apple Health, a user's full export can be imported directly, which is how people bring years of history with them. ## What to tell your security and compliance team The conversation is usually shorter than teams expect, because the answers are architectural rather than contractual. - **Where the data sits:** in your own cloud account, in the region you chose. You show it by pointing at the account. - **Who can reach it:** your team. When Momentum works on your system, it does so under a DPA you sign. - **Whose provider apps they are:** yours. The credentials are issued to your organisation. - **What happens if you stop working with Momentum:** nothing stops. The deployment is built from infrastructure code in your repository, under an MIT license. - **Certification:** Open Wearables runs inside your own certified environment. If you hold SOC 2 or ISO 27001, the deployment can sit within that scope. ## How Momentum can help with the move Open Wearables is open source, and teams run this playbook with their own engineers, the documentation and the community on Discord. If you would rather not carry the move alone, Momentum, the team that builds Open Wearables, can take on as much of it as you need: the architecture audit and migration plan, the deployment in your cloud account with providers onboarded under your credentials, the connection and consent flow in your app, and support while your users move across. After the move, Enterprise support adds an SLA, a named on-call and tested upgrades. The deployment is yours from the first commit either way. [See how a migration to Open Wearables runs](https://openwearables.io/migrate), or [tell us what you run today](https://openwearables.io/book). ## FAQ ### Do all our users have to reconnect? Yes, once. A connection belongs to the app that requested it, so moving to provider apps registered in your name means each user authorises again. Open Wearables runs the flow; you choose where it appears in your product. ### Can we run the hosted API and Open Wearables at the same time? Yes, and most teams do. It is the safest way to validate the new path on real users before switching the hosted API off. ### Do we lose the data we already have? No. The history you hold stays where it is. New data lands in your own deployment from the switch onwards, and history is requested from providers that offer it as users reconnect. ### Do we have to rewrite our product? Usually not. The parts of your product that read wearable data switch to the Open Wearables API and webhooks. Mapping your current data model to the standard schema is part of the architecture audit. ### How long does the move take? It depends on your providers and on how long their credential approval takes. The architecture audit ends with a timeline for your setup. ## Open Wearables Open Wearables is an open-source platform that connects your application to wearable and health data providers through a single API. One normalized data model, multi-provider support in a single self-hosted deployment, MIT licensed, and health intelligence built in: normalized recovery, sleep, activity and biometric data ready for your product layer. We offer custom deployment and integration support through Momentum. If your team needs help getting to production faster, we can set up and configure Open Wearables as part of a managed engagement. [Let's talk](https://www.themomentum.ai/lets-talk). [Book a demo](https://openwearables.io/book) to see how Open Wearables fits your use case. ## See related articles - [Why teams move from a hosted wearable API to Open Wearables](https://openwearables.io/blog/why-teams-move-from-hosted-wearable-api-to-open-wearables) - [Garmin Connect Developer Program reopened: what changes for your integration](https://openwearables.io/blog/garmin-connect-developer-program-reopened) - [How to Handle OAuth, Webhooks, and Token Refresh Across Multiple Wearable Providers](https://openwearables.io/blog/how-to-handle-oauth-webhooks-token-refresh-wearable-providers) ## Keep reading Guides · Oct 26, 2026 · 7 min read ### Why teams move from a hosted wearable API to Open Wearables A hosted wearable API is a sensible way to start. As a product grows, the questions change: whose provider apps, whose cloud, whose schema. Here is why teams move to Open Wearables, what they get after the move, and what it asks of them. Guides · Jul 28, 2026 · 5 min read ### How Wearable Data Flows From Device to Your API: A Complete Architecture Guide Wearable data does not go directly from device to your API. It flows through the provider cloud, then Open Wearables, then PostgreSQL, then your application. Here is what each step looks like. Guides · Jul 22, 2026 · 5 min read ### How to Build an AI Agent That Reasons Over Health Data An AI agent that reasons over health data is different from one that reads it. Here is how the Open Wearables MCP server works and how to build the reasoning layer on top of it. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/how-to-access-google-health-connect-data-in-your-backend # How to access Google Health Connect data in your backend [All posts](https://openwearables.io/blog) [Google Health Connect](https://openwearables.io/blog/category/google-health-connect) Open Wearables Team · May 6, 2026 · 7 min read ## Introduction Google Health Connect has no server-side API. If you want Health Connect data in your backend, there is only one path: build an Android app that reads data from Health Connect on the device and uploads it to your server. This is architecturally different from every other wearable integration covered in this series. There is no OAuth flow you can initiate from your backend, no token to exchange, no webhook to receive. The data lives on the user's Android device and your app must go get it. This guide covers the complete pipeline: setting up Health Connect in your Android app, requesting permissions correctly, implementing reliable background sync with WorkManager and change tokens, serializing and uploading data to your backend, and handling the production edge cases that trip up most implementations. It also covers how to normalize Health Connect data once it reaches your backend so it fits alongside data from server-side providers. ## Android app setup Add the Health Connect SDK dependency to your app's build.gradle file. Use the androidx.health.connect:connect-client library. Check the current version in Google's Maven repository. Add the required permissions to your AndroidManifest.xml for each Health Connect data type you intend to read. Each data type has a separate read permission. Declare only the permissions you will actually request and use. Also add a queries element to your AndroidManifest.xml declaring the androidx.health.connect.client package. This is required for Android to recognize that your app uses Health Connect and enables the permission request flow. Check for Health Connect availability when the app starts. On Android 14+, Health Connect is built into the system. On older versions, the user may need to install the Health Connect app separately. Use HealthConnectClient.getSdkStatus(context) to check availability before attempting to use the SDK. If the status indicates unavailable, direct the user to the Play Store to install Health Connect. ## Requesting and managing permissions Health Connect permissions are requested using a specialized ActivityResultContract called RequestMultiplePermissions paired with Health Connect's PermissionController.createRequestPermissionResultContract(). This is not the same as the standard Android runtime permissions flow, although it looks similar to the user. Request permissions at the right moment in your onboarding flow. Explain to the user before the permission dialog appears which data you will read and why. Users who understand the value of sharing health data are significantly more likely to grant all requested permissions. A one-screen explanation before the permission dialog showing what the app does with each data type improves grant rates. After permissions are granted, check which were actually approved using healthConnectClient.permissionController.getGrantedPermissions(). Do not assume all requested permissions were granted. Build your sync logic to work with whatever subset of permissions the user granted and surface clear messaging about which features require which permissions. Permissions can be revoked at any time. Check granted permissions at the start of each sync job. If a previously granted permission is no longer present, skip the affected data types and update your UI to show the restricted data types. ## Reading data and change tokens Health Connect read operations use the readRecords method on the HealthConnectClient. Each call specifies a record type class, a time range filter, a page size and an optional page token for pagination. For initial sync, use a time range from 30 days ago to now. For incremental sync, use change tokens instead. Obtain a change token by calling getChangesToken with the record types you want to track. After your initial data read, store this token. On subsequent syncs, call getChanges with the stored token to receive only records that have been added, modified or deleted since the token was issued. This dramatically reduces the data you need to process and upload on each sync cycle. Handle token expiry: change tokens expire after 30 days. If getChanges returns a ChangesTokenExpiredException, fall back to a full time-range read and obtain a new change token after completing the read. ## Reliable background sync with WorkManager Background work in Android is subject to battery optimization restrictions that can kill background services. WorkManager is the correct tool for reliable background Health Connect sync. It survives process death, handles retry with backoff, and respects Android's battery optimization while ensuring work eventually completes. ``` class HealthConnectSyncWorker( context: Context, params: WorkerParameters ) : CoroutineWorker(context, params) { override suspend fun doWork(): Result { val client = HealthConnectClient.getOrCreate(applicationContext) val prefs = applicationContext.getSharedPreferences("hc_sync", Context.MODE_PRIVATE) return try { val recordTypes = listOf( ExerciseSessionRecord::class, SleepSessionRecord::class, HeartRateRecord::class, StepsRecord::class, HeartRateVariabilityRmssdRecord::class ) val payloads = mutableListOf() for (recordType in recordTypes) { val tokenKey = "change_token_${recordType.simpleName}" val storedToken = prefs.getString(tokenKey, null) if (storedToken != null) { val changesResponse = client.getChanges(storedToken) payloads.addAll(changesResponse.changes) prefs.edit().putString(tokenKey, changesResponse.nextChangesToken).apply() } else { val timeFilter = TimeRangeFilter.between( Instant.now().minus(30, ChronoUnit.DAYS), Instant.now() ) val response = client.readRecords( ReadRecordsRequest(recordType, timeFilter) ) payloads.addAll(response.records) val newToken = client.getChangesToken( ChangesTokenRequest(setOf(recordType)) ) prefs.edit().putString(tokenKey, newToken).apply() } } uploadToBackend(payloads) Result.success() } catch (e: PermissionException) { // Permissions revoked, do not retry Result.failure() } catch (e: Exception) { Result.retry() } } private suspend fun uploadToBackend(payloads: List) { // Serialize and POST to your backend endpoint } } ``` Register this Worker as a PeriodicWorkRequest with a one-hour interval and a network connectivity constraint. Use enqueueUniquePeriodicWork with ExistingPeriodicWorkPolicy.KEEP to ensure only one instance runs at a time. ## Serializing and uploading Health Connect data Health Connect SDK objects are not directly JSON serializable. You need to map each record type to a serializable data class before uploading. Define a data class for each record type you sync and write a conversion function that extracts the fields you need. Include the dataOrigin source package name from each record's metadata in your serialized payload. This allows your backend to identify which app contributed each record, which is important for deduplication when multiple apps write overlapping data to Health Connect. Upload batches rather than individual records. Group all records from a sync cycle into a single request payload and POST to your backend. Your backend should process the payload idempotently: uploading the same record twice should not create duplicates. Use the Health Connect record ID (available in each record's metadata) as a stable deduplication key in your backend storage. ## Backend normalization Once Health Connect data reaches your backend, normalize it to your common health data schema. Map Health Connect record types to your canonical entities: ExerciseSessionRecord to a workout event, SleepSessionRecord with SleepStageRecord children to a sleep record, HeartRateRecord to heart rate time series data, StepsRecord to daily activity, and HeartRateVariabilityRmssdRecord to HRV measurements. Health Connect sport type identifiers are enumerations from the ExerciseSessionRecord class (for example ExerciseSessionRecord.EXERCISE_TYPE_RUNNING, ExerciseSessionRecord.EXERCISE_TYPE_CYCLING). Map these to your internal sport type taxonomy using the same mapping table you use for other providers. Timestamps in Health Connect are stored as Instant objects (UTC). Ensure your backend preserves UTC timestamps and handles timezone display on the client side based on user preference or the local timezone recorded in the session metadata. ## Production edge cases Large initial syncs can fail due to payload size limits or upload timeouts. Implement chunked uploads for the initial 30-day backfill: process data in daily batches and upload each batch before moving to the next day. Store the last successfully uploaded date so you can resume from where you left off if the initial sync is interrupted. Device battery optimization can delay or kill WorkManager jobs on some Android manufacturers that apply aggressive background process restrictions (Xiaomi, OnePlus, Huawei and others are known for this). Include device-specific battery optimization guidance in your app's settings or onboarding flow, directing users to exempt your app from battery optimization. Without this, sync jobs may not run reliably on a significant portion of Android devices. Multiple overlapping change token streams for the same record type can arise if a user has multiple sessions of your app running or reinstalls the app. Manage change token storage carefully: store tokens in a persistent location that survives app updates (SharedPreferences or Room database) and implement a reset mechanism that clears all change tokens and triggers a fresh time-range backfill if you detect inconsistency. ## Open Wearables Open Wearables is an open-source platform that connects your application to wearable and health data providers through a single API. One normalized data model, multi-provider support in a single self-hosted deployment, no per-user fees, MIT licensed, and health intelligence built in: normalized recovery, sleep, activity and biometric data ready for your product layer. We offer custom deployment and integration support through Momentum. If your team needs help getting to production faster, we can set up and configure Open Wearables as part of a managed engagement. [Let's talk](https://www.themomentum.ai/lets-talk). [Book a demo](https://openwearables.io/book) to see how Open Wearables fits your use case. ## Google Health Connect integration View the full [Google Health Connect integration documentation](https://openwearables.io/integrations/google-health-connect) on Open Wearables. ## See related articles [Google Health Connect Integration: Android Health Data for Developers](https://openwearables.io/blog/google-health-connect-integration-android-health-data-for-developers) [Apple HealthKit API: What Data You Can Access and How](https://openwearables.io/blog/apple-healthkit-api-what-data-you-can-access-and-how) [Samsung Health API: Galaxy Watch Data for Developers](https://openwearables.io/blog/samsung-health-api-galaxy-watch-data-for-developers) ## Keep reading Google Health Connect · Jun 7, 2026 · 4 min read ### Google Health Connect integration for Android developers Google Health Connect is not a cloud API. It requires on-device Android SDK integration. Learn how Open Wearables handles the full Health Connect lifecycle. Google Health Connect · May 6, 2026 · 7 min read ### Google Health Connect integration: Android health data for developers Google Health Connect is Android's on-device health data hub, aggregating data from Wear OS, Galaxy Watch, Fitbit, Garmin and third-party apps. Here's how to build with it. Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/how-to-access-polar-watch-data-in-your-health-app # How to access Polar watch data in your health app [All posts](https://openwearables.io/blog) [Polar](https://openwearables.io/blog/category/polar) Open Wearables Team · May 3, 2026 · 7 min read ## Introduction Polar's training data model is deeper than any other widely integrated wearable API. Most platforms give you workout duration, heart rate and a calorie estimate. Polar gives you Cardio Load, Muscle Load, Training Effect for aerobic and anaerobic adaptation separately, ANS Charge derived from HRV during early sleep, and standardized morning HRV measurements via HRV4T. The challenge for developers is not getting the data, it is using it in ways that are meaningful to users who may not have a sports science background. This guide focuses on translating Polar's rich data model into product features: how to use Training Load Pro data for coaching recommendations, how to integrate Nightly Recharge into recovery-based training adjustments, how to build HRV trend features that serve both serious athletes and general wellness users, and how to structure your backend for a multi-provider product where Polar is one of several supported wearables. ## Setting up Polar AccessLink Register your application at the Polar developer portal. The process is self-serve. You specify your application name, redirect URI and the scopes your application needs. Available scopes include accesslink.read_all for full read access, which covers training, activity, sleep and physical information endpoints. Once registered, you receive a client_id and client_secret. Implement the OAuth 2.0 authorization code flow: redirect users to Polar's authorization endpoint, receive the authorization code at your redirect URI, exchange it for an access token at Polar's token endpoint, and then immediately register the user with your application by POSTing to the AccessLink users endpoint with the access token. This registration step is mandatory and easy to miss. Polar access tokens do not expire. Store them securely per user in your database. You will use the same token indefinitely unless the user revokes access. Implement a check that detects 401 responses, marks the user's Polar connection as disconnected, and surfaces a reconnect prompt in your application. ## Implementing the transaction model Polar's transaction model requires a specific fetch lifecycle. For each resource type (exercises, daily activity, sleep, physical information), your sync job must open a transaction, list available items within the transaction, fetch each item, process and store the results, and then commit the transaction. Only commit after successfully storing data. A robust sync job structure for exercises looks like this: attempt to open an exercise transaction for the user. If no transaction is available (HTTP 204), there is no new data and you can skip. If a transaction is opened, iterate through the list of exercise URLs within the transaction, fetch each one, store the raw response, process it into your normalized schema, and after all items are successfully stored, commit the transaction. If any fetch or storage step fails, rollback the transaction and retry on the next sync cycle. Run sync jobs for each resource type on a schedule appropriate to your product. Once per hour is sufficient for most applications. Exercise and daily activity transactions are independent, so a failure on the exercise transaction does not affect the activity transaction. ## Cardio load and muscle load in a coaching context Training Load Pro is available on Polar Vantage and Grit X series devices and provides two separate training load measures per session. Cardio Load quantifies the cardiovascular stress of the session based on heart rate response relative to the user's maximum heart rate and duration. Muscle Load quantifies neuromuscular demand based on acceleration patterns and GPS data. The practical value of this split is in training distribution analysis. A user who does a 60-minute easy run accumulates high Cardio Load and low Muscle Load. A user who does 20 minutes of sprint intervals accumulates moderate Cardio Load and very high Muscle Load. A strength training session produces low Cardio Load and high Muscle Load. Treating these as equivalent loads (as most apps that only track duration and heart rate do) produces misleading overtraining and recovery signals. For coaching features, track 7-day rolling Cardio Load and Muscle Load separately. Acute load spikes (more than 1.5 times the 28-day average in a single week) in either dimension are risk factors for injury and poor adaptation regardless of the other dimension. A user can have a high-Cardio-Load week from long aerobic training while maintaining low Muscle Load, which is quite different physiologically from a high week of both. Surface these insights in plain language rather than raw numbers. Instead of showing Cardio Load: 847, show something like cardiovascular demand this week is higher than your 28-day average, with a note on whether this is appropriate given the user's training goals. ## ANS charge and Nightly Recharge Polar's Nightly Recharge measures overnight recovery quality using two components. ANS Charge is derived from HRV and heart rate measured during the first four hours of sleep, when parasympathetic nervous system activity provides a reliable physiological recovery signal without being confounded by sleep stage transitions. Sleep Charge is based on total sleep duration, sleep continuity and time in restorative sleep stages. Polar reports Nightly Recharge with a status of Compromised, Acceptable, or Good for the overall score, and separately for ANS Charge and Sleep Charge. This gives you three status values to work with in your UI. A user with Good Sleep Charge but Compromised ANS Charge had adequate sleep duration but their nervous system did not recover well, which may indicate accumulated training stress, illness onset or external life stress. The opposite pattern (Good ANS Charge but Compromised Sleep Charge) suggests the body is physiologically recovering but sleep was disrupted. Use Nightly Recharge status as a training day modifier rather than a binary go or no-go signal. A Compromised status after a high-load training week is expected and does not necessarily mean the user should rest completely; it might mean a lower-intensity session is appropriate. Build a context layer that combines Nightly Recharge with cumulative training load to generate sensible recommendations. ## HRV4T trend analysis HRV4T morning measurements follow a consistent protocol, which makes them more comparable day-to-day than nocturnal HRV measurements that are confounded by varying sleep stage distributions. Build a personal baseline for each user using their most recent 60 rolling days of HRV4T data, excluding days with very high training load (which predictably suppress HRV) to get a cleaner rested baseline. Flag days where HRV is more than one standard deviation below the user's baseline as recovery signals. Flag multi-day trends (three or more consecutive days below baseline) as cumulative fatigue indicators requiring a genuine recovery intervention rather than just a modified training session. Polar provides HRV4T status as a categorized output alongside the raw rMSSD value. Use both: the categorized status for simple UI display and the raw rMSSD for your own calculations. Building on the raw values allows you to apply your own baseline and deviation thresholds tuned to your user population rather than relying entirely on Polar's proprietary scoring. ## Multi-provider architecture In a multi-provider health app, Polar users will often be your most data-sophisticated users. They are typically serious athletes or health enthusiasts who have chosen Polar specifically for its training depth. Design your normalization schema to preserve Polar-specific fields rather than discarding them in favor of a lowest-common-denominator model. A practical approach is a two-layer schema. The common layer holds fields that exist across all providers: workout duration, heart rate average and max, sleep duration and stages, HRV (mapped to rMSSD), resting heart rate, step count. The provider extension layer holds provider-specific fields: Polar's Cardio Load, Muscle Load, ANS Charge, Nightly Recharge and Training Effect; Samsung's stress score; Whoop's strain; Garmin's Body Battery. Build product features on the common layer where possible so they work for all users. Build enhanced features that use the extension layer where the data is available, and degrade gracefully for users on providers that do not have equivalent metrics. ## Open Wearables Open Wearables is an open-source platform that connects your application to wearable and health data providers through a single API. One normalized data model, multi-provider support in a single self-hosted deployment, no per-user fees, MIT licensed, and health intelligence built in: normalized recovery, sleep, activity and biometric data ready for your product layer. We offer custom deployment and integration support through Momentum. If your team needs help getting to production faster, we can set up and configure Open Wearables as part of a managed engagement. [Let's talk](https://www.themomentum.ai/lets-talk). [Book a demo](https://openwearables.io/book) to see how Open Wearables fits your use case. ## Polar integration View the full [Polar integration documentation](https://openwearables.io/integrations/polar) on Open Wearables. ## See related articles [Polar API: Training, HRV and Nightly Recharge Data](https://openwearables.io/blog/polar-api-training-hrv-nightly-recharge-data) [Garmin Connect API: Developer Guide for Activities and Health Metrics](https://openwearables.io/blog/garmin-connect-api-developer-guide-activities-health-metrics) [Whoop API: Recovery, Strain and Sleep Data for Developers](https://openwearables.io/blog/whoop-api-recovery-strain-sleep-data-for-developers) ## Keep reading Polar · May 30, 2026 · 5 min read ### How to integrate Polar data into your health app The Polar API (AccessLink) requires OAuth, token management, and polling. Open Wearables abstracts all of that into a single sync endpoint with normalized output. Polar · May 5, 2026 · 8 min read ### Polar API: training, HRV and Nightly Recharge data Polar AccessLink API provides training sessions for 100+ sport types, HRV4T nightly HRV tracking, Nightly Recharge, sleep staging and VO2 max. Here's what building with it requires. Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/how-to-add-wearable-data-corporate-wellness-platform # How to Add Wearable Data to a Corporate Wellness Platform [All posts](https://openwearables.io/blog) [Guides](https://openwearables.io/blog/category/guides) Open Wearables Team · Jul 22, 2026 · 5 min read ## Key Takeaways - Corporate wellness platforms need wearable data from multiple providers without asking employees to switch devices. The integration layer has to be device-agnostic from day one. - Open Wearables connects wearable providers through a single API. A Garmin user and a Whoop user in the same company connect through the same OAuth flow and appear in the same data model. - Health scores are computed from raw provider data and exposed through the health scores API. Available categories include sleep, recovery, readiness, activity, stress, resilience, and more. - Employee data stays on your infrastructure. Open Wearables is self-hosted: no third-party cloud has access to your employees' health data. - What you build on top (dashboards, aggregated reporting, coaching prompts, trigger-based notifications) is your application layer. Open Wearables provides the data foundation and health intelligence on top. Adding wearable support to a corporate wellness platform sounds straightforward until you account for the device landscape. Your employees use Garmin, Whoop, Oura, Apple Watch, Polar, Fitbit, and more. Each provider has its own OAuth flow, its own data schema, and its own sync model. Building direct integrations with each is months of work per provider. Building one abstraction layer is a different kind of project. This article covers what Open Wearables provides for corporate wellness use cases, what the integration looks like architecturally, and what you need to build on top. ## The Device Problem Corporate wellness platforms that require a specific device have poor adoption. Employees already have the devices they prefer. The platform needs to meet them there. Open Wearables handles OAuth authorization and data normalization for each supported provider. An employee with a Garmin connects through a Garmin OAuth flow. An employee with Whoop connects through a Whoop OAuth flow. Both land in the same normalized data model in your instance. Your application queries one API regardless of which device an employee uses. The current list of supported providers is at docs.openwearables.io/provider-setup. For providers not yet in the community version, Momentum can build custom integrations as a commercial service. ## What Data Is Available Open Wearables normalizes provider data into consistent types. For a corporate wellness context, the most relevant are: - **Daily activity aggregates (ActivitySummary):** steps, distance, active calories, active minutes, sedentary minutes, intensity minutes (light, moderate, vigorous), and daily heart rate stats. - **Sleep sessions (SleepSession):** sleep start and end time, total duration, sleep efficiency, sleep stages (light, deep, REM, awake), and a flag distinguishing naps from main sleep sessions. - **Workouts (Workout):** activity type, duration, distance, calories, average and max heart rate. Health scores are computed from raw provider data and exposed through the health scores API. Not every score is available from every provider. The source field on each record identifies which provider contributed the underlying data. The full list of available score categories is at docs.openwearables.io. ## Architecture: What Open Wearables Handles When an employee connects their wearable through your platform, the flow is: 1. Your application redirects to the Open Wearables authorize endpoint for the relevant provider 2. The employee authenticates with their provider account (Garmin Connect, Whoop app, Oura cloud, etc.) 3. Open Wearables receives the OAuth callback, stores the connection, and begins syncing data 4. Provider data arrives via webhook (Garmin, Whoop, Oura) or scheduled polling (Polar, Fitbit) and is normalized into your PostgreSQL instance 5. Your application queries the Open Wearables REST API for employee health data Open Wearables handles: OAuth flows for each provider, token storage and refresh, webhook registration and processing, data normalization to consistent field names and units, and within-provider deduplication. Your application handles: the authorization trigger, employee identity mapping (linking Open Wearables user IDs to your employee records), data querying, dashboard rendering, aggregated reporting, and any notification or coaching logic. ## Data Ownership and Compliance Employee health data is sensitive. In a corporate wellness context, the question of where data lives and who has access to it matters for compliance and employee trust. Open Wearables is self-hosted. Employee wearable data flows into your PostgreSQL instance on your infrastructure. For HIPAA-eligible deployments or enterprise-grade configurations, Momentum offers commercial services including BAAs. Details at openwearables.io/pricing. ## What You Build on Top Open Wearables provides the data layer. The wellness experience is what your application builds on top of it. - **Aggregated team dashboards:** query activity summaries and sleep data across your employee population. Average steps per department, sleep duration trends, activity distribution. Open Wearables returns data per user; your application aggregates. - **Individual employee views:** each employee's connected devices, daily metrics, sleep trends over time. The data is queryable by user ID and date range. - **Trigger-based notifications:** define logic in your application and query the Open Wearables API on a schedule. Outbound webhooks (push notifications from Open Wearables to your backend when new data arrives) are on the roadmap. Check the GitHub repository for current status. - **AI-powered coaching prompts:** the Open Wearables MCP server gives any LLM structured access to health data. You define the domain logic: for corporate wellness, that means focusing on stress, sleep, and energy rather than athletic performance metrics, and framing recommendations in terms of sustainable habits rather than optimization. ## Related articles - [How to Give Your LLM Access to Wearable Data](https://openwearables.io/blog/how-to-give-your-llm-access-to-wearable-data) - [How to Handle OAuth, Webhooks, and Token Refresh Across Multiple Wearable Providers](https://openwearables.io/blog/how-to-handle-oauth-webhooks-token-refresh-wearable-providers) - [How to Build a HIPAA-Compliant Health App That Uses Wearable Data](https://openwearables.io/blog/how-to-build-hipaa-compliant-health-app-wearable-data) - [Wearable Data Deduplication: How to Handle Users With Multiple Devices](https://openwearables.io/blog/wearable-data-deduplication-multiple-devices) ## FAQ ### Can employees use any wearable device? They can use any device that is supported by Open Wearables. The current list of supported providers is at docs.openwearables.io/provider-setup. For providers not yet supported, custom integrations are available through Momentum. Employees who use unsupported devices cannot be onboarded until support is added. ### Do employees need to create new accounts? No. Employees connect their existing provider accounts through the OAuth flow. They log in with their Garmin Connect account, their Oura account, their Whoop account. No new account creation is required on the provider side. ### How do we handle employees who do not want to share health data? Open Wearables requires explicit OAuth authorization per employee. An employee who does not authorize the connection has no data in your instance. The authorization is voluntary and revocable. Your platform's consent and opt-out handling is application-level logic. ### Can we aggregate data across the whole company without exposing individual records? Yes. You query individual employee data through the Open Wearables API (per user ID) and aggregate it in your application layer. Open Wearables does not expose population-level aggregate endpoints; that aggregation logic lives in your application. ### What health scores are available for corporate wellness? Health scores are computed from raw provider data. Not every category is available from every provider. The full list of available score categories is at docs.openwearables.io. Score availability depends on which providers employees have connected. ## Keep reading Guides · Oct 26, 2026 · 9 min read ### Moving from a hosted wearable API to Open Wearables: a migration playbook Moving from a hosted wearable API to Open Wearables is usually a re-integration rather than a data migration. This playbook walks through the decisions, the steps in order, how your users reconnect and what to tell your security team. Guides · Oct 26, 2026 · 7 min read ### Why teams move from a hosted wearable API to Open Wearables A hosted wearable API is a sensible way to start. As a product grows, the questions change: whose provider apps, whose cloud, whose schema. Here is why teams move to Open Wearables, what they get after the move, and what it asks of them. Guides · Jul 28, 2026 · 5 min read ### How Wearable Data Flows From Device to Your API: A Complete Architecture Guide Wearable data does not go directly from device to your API. It flows through the provider cloud, then Open Wearables, then PostgreSQL, then your application. Here is what each step looks like. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/how-to-add-wearable-support-existing-health-app # How to Add Wearable Support to an Existing Health App in Days, Not Months [All posts](https://openwearables.io/blog) [Guides](https://openwearables.io/blog/category/guides) Open Wearables Team · Jul 22, 2026 · 5 min read ## Key Takeaways - Adding wearable support to an existing app does not require rebuilding your data layer. Open Wearables sits alongside your existing backend and exposes a REST API your application calls. - The Docker Compose stack deploys in minutes. Full integration including OAuth setup with providers and end-to-end testing typically takes 1-2 weeks. - Provider credential approval is the longest step and the most variable. Most providers are self-service. Garmin's developer program is currently not accepting new applications. - If you already have Garmin or Apple Health integrated directly, you can still use Open Wearables for additional providers, the unified data model, deduplication, and the health intelligence layer. - Open Wearables works alongside existing integrations. You do not need a full cut-over to start using it. Most health apps start with one wearable integration. A user requests Garmin support. You build it. Three months later, another user wants Whoop. You build that too. By the time you have four providers integrated, you have four separate OAuth implementations, four normalization layers, and four sync architectures to maintain. The question is not whether to add wearable support. It is whether to keep building each provider separately or to replace that approach with a single layer that handles them all. ## What the Integration Actually Looks Like Open Wearables is a self-hosted service that runs alongside your existing backend. It does not replace your application. It adds a data layer that your application calls. Your application redirects users to Open Wearables to connect their wearable device. Open Wearables handles the OAuth flow, token storage, and ongoing data sync. Your application queries the Open Wearables REST API for normalized health data. The data appears in consistent format regardless of which device the user has. Your existing application logic, your existing database, your existing user management: none of that changes. You add a service dependency and a set of API calls. ## Timeline: What Takes How Long From the Open Wearables documentation: - **Docker setup: minutes.** Clone the repository, copy.env.example to.env, run docker compose up -d, run make init. The developer portal is at localhost:3000. The API is at localhost:8000. - **Provider credential setup: 1-4 weeks depending on provider.** This is the step that determines your actual timeline. Most providers (Strava, Polar, Oura, Whoop, Fitbit) are self-service and issue credentials immediately. Garmin's developer program is currently not accepting new applications. - **Integration into your application: depends on your architecture.** You need to add the authorize redirect and API calls to fetch health data. For a standard web application with a backend, this is typically a few days of work. - **End-to-end testing: a few days.** Connect test accounts for each provider, verify data is syncing correctly, test edge cases. Total realistic timeline: 1-2 weeks for teams with existing infrastructure, excluding provider approval delays. ## If You Already Have Direct Provider Integrations If your application already has Garmin or Apple Health integrated directly, you do not need to replace those integrations to use Open Wearables. You can deploy Open Wearables for new providers while keeping existing direct integrations in place. The two approaches run in parallel. If you already support Garmin directly, you can add Open Wearables to handle Suunto, Polar, Whoop, Oura, and others without touching your existing Garmin implementation. You can also use Open Wearables for its unified data model and deduplication layer even if you migrate Garmin to it later. The practical approach: keep what is working. Add Open Wearables where it solves a real problem. Migrate the rest when it makes sense. ## Web-Only vs. Mobile Applications For most providers (Garmin, Polar, Suunto, Strava, Oura, Whoop, Fitbit), the OAuth flow works through a web redirect. Your backend initiates the authorization, the user authenticates on the provider's website, and data starts syncing. No mobile SDK required. Apple Health is the exception. Apple does not expose a backend API for HealthKit data. To support Apple Health users, your application needs an iOS component that reads from HealthKit on-device and sends data to your Open Wearables instance. Open Wearables ships a Flutter SDK for this. A React Native SDK is on the roadmap. Google Health Connect and Samsung Health are similarly SDK-based on Android. If your application is web-only and you need Apple Health support, you need a companion mobile app that reads from HealthKit and sends data to your Open Wearables instance. ## What to Query Once It Is Running Once Open Wearables is deployed and users have connected their devices, you query the REST API directly from your backend: ``` # Get workouts for a user curl -H "X-API-Key: YOUR_API_KEY" \ "http://localhost:8000/api/v1/users/USER_ID/events/workouts" # Get sleep sessions curl -H "X-API-Key: YOUR_API_KEY" \ "http://localhost:8000/api/v1/users/USER_ID/events/sleep" # Get daily activity summary curl -H "X-API-Key: YOUR_API_KEY" \ "http://localhost:8000/api/v1/users/USER_ID/summaries/activity" ``` The response format is the same regardless of which provider the user has connected. A workout from Garmin and a workout from Polar use the same field names, the same units, the same timestamp format. ## Related articles - [How to Handle OAuth, Webhooks, and Token Refresh Across Multiple Wearable Providers](https://openwearables.io/blog/how-to-handle-oauth-webhooks-token-refresh-wearable-providers) - [What Is an Open Source Wearable API and When Does It Make Sense](https://openwearables.io/blog/what-is-open-source-wearable-api-when-does-it-make-sense) - [Wearable Data Deduplication: How to Handle Users With Multiple Devices](https://openwearables.io/blog/wearable-data-deduplication-multiple-devices) - [What wearable app development actually looks like in 2026](https://openwearables.io/blog/what-wearable-app-development-actually-looks-like-in-2026) - [How Wearable Data Flows From Device to Your API: A Complete Architecture Guide](https://openwearables.io/blog/how-wearable-data-flows-device-to-api-architecture) ## FAQ ### Do I need to rebuild my existing backend to use Open Wearables? No. Open Wearables is a separate service that runs alongside your existing backend. You add API calls to query it. Your existing data model, authentication, and business logic stay in place. ### Can I use Open Wearables if my app is already live in production? Yes. You deploy Open Wearables on your infrastructure, configure provider credentials, and start routing new wearable connections through it. Existing users are not affected until you migrate them, which you can do gradually. ### What if I only need one provider? Open Wearables makes sense even for a single provider if you anticipate adding more in the future, if you want the normalized data model, or if you plan to build health intelligence features on top of the data. If you only ever need one provider and have no plans to expand, a direct integration may be simpler. ### How do I map Open Wearables users to my existing users? Open Wearables manages its own user model. You link Open Wearables user IDs to your application's user IDs in your own database. When a user connects a wearable through your application, you create an Open Wearables user (or use an existing one) and store the mapping. All subsequent queries use the Open Wearables user ID. ### What support is available during integration? Community support through Discord and GitHub Issues. For hands-on implementation help, Momentum offers commercial services. Details at openwearables.io/pricing. ## Keep reading Guides · Oct 26, 2026 · 9 min read ### Moving from a hosted wearable API to Open Wearables: a migration playbook Moving from a hosted wearable API to Open Wearables is usually a re-integration rather than a data migration. This playbook walks through the decisions, the steps in order, how your users reconnect and what to tell your security team. Guides · Oct 26, 2026 · 7 min read ### Why teams move from a hosted wearable API to Open Wearables A hosted wearable API is a sensible way to start. As a product grows, the questions change: whose provider apps, whose cloud, whose schema. Here is why teams move to Open Wearables, what they get after the move, and what it asks of them. Guides · Jul 28, 2026 · 5 min read ### How Wearable Data Flows From Device to Your API: A Complete Architecture Guide Wearable data does not go directly from device to your API. It flows through the provider cloud, then Open Wearables, then PostgreSQL, then your application. Here is what each step looks like. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/how-to-build-ai-agent-reasons-over-health-data # How to Build an AI Agent That Reasons Over Health Data [All posts](https://openwearables.io/blog) [Guides](https://openwearables.io/blog/category/guides) Open Wearables Team · Jul 22, 2026 · 5 min read ## Key Takeaways - An AI agent that reasons over health data is different from one that reads it. Reading returns numbers. Reasoning connects patterns across metrics, time periods, and user context to produce actionable output. - Open Wearables ships an MCP server that gives any compatible LLM structured, queryable access to health data through five tools: get_users, get_workout_events, get_sleep_summary, get_activity_summary, and get_timeseries. - The MCP server includes a built-in workflow: discover users, determine date range, call the right tool, present results with context. The LLM follows this workflow automatically when configured correctly. - The MCP server is designed for AI assistant interfaces (Claude Desktop, Cursor IDE). For production backend integrations, call the Open Wearables REST API directly. - The reasoning layer is yours to define: which metrics matter, what thresholds apply, what the model should and should not conclude. Open Wearables provides the data access. You provide the domain logic. Most health AI integrations produce the same output regardless of how sophisticated the model is: a list of numbers with labels. "Your heart rate averaged 72 bpm. You slept 6.4 hours. You walked 8,432 steps." The model is reading, not reasoning. An agent that reasons over health data does something different. It retrieves specific data for a specific question, interprets it in context, connects it to related metrics, and produces output that a user can act on. This article covers how to build that reasoning layer using Open Wearables. ## What the Open Wearables MCP Server Provides The Open Wearables MCP server is a FastMCP application that exposes five tools and one prompt to any connected AI assistant. It runs as a REST API client on top of your Open Wearables instance. **Five tools:** - **get_users**: Discover users accessible via your API key. Takes an optional search term and limit. - **get_workout_events**: Retrieve workout sessions for a user within a date range. Filterable by workout type (running, cycling, swimming, strength_training, etc.). - **get_sleep_summary**: Retrieve daily sleep summaries including duration, stages, and efficiency. - **get_activity_summary**: Retrieve daily activity metrics: steps, calories, heart rate, distance, intensity minutes. - **get_timeseries**: Retrieve granular time-series samples for metrics not covered by summary tools (weight, SpO2, HRV, respiratory rate, blood glucose). Capped at 100 pages per call to keep responses bounded. **One prompt:** - **present_health_data**: Formatting guidelines for presenting health data in a human-readable way. Instructs the model to lead with insights, convert units, round appropriately, and highlight patterns rather than dumping raw values. ## How the Agent Workflow Works The MCP server includes a built-in workflow in its system instructions. When a user asks a health question, the agent follows this sequence: 1. If the user ID is not known, call get_users first 2. Select the appropriate user based on the query context 3. Determine the date range: explicit if specified, otherwise default to the last 14 days 4. Call the appropriate tool with the user ID and date range 5. Present the result with context and highlights From the MCP server's system instructions, a sleep query looks like this in practice: ``` User: "How did I sleep last week?" Agent: 1. Calls get_users() to find the user's ID 2. Calculates dates: start_date = 7 days ago, end_date = today 3. Calls get_sleep_summary(user_id="uuid-1", start_date="2026-01-28", end_date="2026-02-04") 4. Responds: "Over the past week, you averaged 7.2 hours of sleep per night. Your best night was Tuesday (8.1 hours), and your shortest was Friday (5.9 hours). Your sleep efficiency averaged 89%." ``` ## Setting Up the MCP Server ``` cd mcp uv sync --group code-quality cp config/.env.example config/.env # Set OPEN_WEARABLES_API_URL and OPEN_WEARABLES_API_KEY uv run start ``` To connect to Claude Desktop, add to ~/Library/Application Support/Claude/claude_desktop_config.json: ``` { "mcpServers": { "open-wearables": { "command": "uv", "args": [ "run", "--frozen", "--directory", "/path/to/open-wearables/mcp", "start" ] } } } ``` Restart Claude Desktop. The agent now has access to all five tools. ## Building the Reasoning Layer on Top The MCP server provides data access. The reasoning layer is what you define on top of it. - **Domain framing.** The same workout data means different things in different contexts. Your system prompt defines which interpretation framework the model applies. - **Metric selection.** When a user asks "how am I doing?", the agent needs to decide which metrics to retrieve. Your prompt guides this selection based on your use case. - **Thresholds and baselines.** "Your sleep efficiency was 89%" means nothing without a reference point. Your prompting layer provides the reference: the user's baseline, clinical guidelines, or domain-specific targets. - **Guardrails.** Health data applications operate near clinical territory. Your prompt defines what the agent is allowed to conclude and what it defers to a professional. ## MCP Server vs. Direct API Integration The MCP server is the right choice for AI assistant interfaces (Claude Desktop, Cursor IDE), internal tooling where analysts query health data through a chat interface, and prototyping. For production backend integrations, call the Open Wearables REST API directly from your backend. The REST API gives you full control over data retrieval, context construction, and model interaction. ``` curl -H "X-API-Key: YOUR_API_KEY" \ "http://localhost:8000/api/v1/users/USER_ID/events/workouts?start=2026-07-01&end=2026-07-22" ``` ## Related articles - [How to Give Your LLM Access to Wearable Data](https://openwearables.io/blog/how-to-give-your-llm-access-to-wearable-data) - [How to Structure Health Data for AI: What Your LLM Actually Needs](https://openwearables.io/blog/how-to-structure-health-data-for-ai-llm) - [How to build an AI health coaching app with wearable data](https://openwearables.io/blog/how-to-build-ai-health-coaching-app-with-wearable-data) - [How Wearable Data Flows From Device to Your API: A Complete Architecture Guide](https://openwearables.io/blog/how-wearable-data-flows-device-to-api-architecture) ## FAQ ### Does the MCP server work with models other than Claude? MCP support varies by model and interface. Claude Desktop and Cursor IDE have native MCP support. Other interfaces are adding support as the standard gains adoption. For model-agnostic integrations, use the Open Wearables REST API directly. ### Can the agent query multiple users at once? The get_users tool returns a list of users accessible via your API key. The agent can query data for any user in that list. Multi-user queries (comparing two users, team-level aggregations) require multiple tool calls or custom backend logic. ### What is the timeseries tool's page limit and why does it exist? The get_timeseries tool is capped at 100 pages per call (up to 10,000 samples). This prevents context overflow and protects the backend from expensive queries. For most questions about HRV, SpO2, or intraday heart rate, a bounded time window is more useful than raw full-resolution data. ### Can I extend the MCP server with custom tools? Yes. The MCP server is open source and uses FastMCP. You can add custom tools that expose additional data, perform domain-specific computations, or integrate external data sources. Custom toolsets are also part of the commercial services offered by Momentum for teams that need domain-specific health reasoning beyond what ships open source. ### What is the present_health_data prompt and when should I use it? It is a pre-built formatting prompt that instructs the model to present health data with context rather than as raw values. It covers unit conversions (meters to km), rounding rules, and presentation principles like leading with insights and highlighting patterns. You can invoke it in Claude Desktop by referencing it in your query. ## Keep reading Guides · Oct 26, 2026 · 9 min read ### Moving from a hosted wearable API to Open Wearables: a migration playbook Moving from a hosted wearable API to Open Wearables is usually a re-integration rather than a data migration. This playbook walks through the decisions, the steps in order, how your users reconnect and what to tell your security team. Guides · Oct 26, 2026 · 7 min read ### Why teams move from a hosted wearable API to Open Wearables A hosted wearable API is a sensible way to start. As a product grows, the questions change: whose provider apps, whose cloud, whose schema. Here is why teams move to Open Wearables, what they get after the move, and what it asks of them. Guides · Jul 28, 2026 · 5 min read ### How Wearable Data Flows From Device to Your API: A Complete Architecture Guide Wearable data does not go directly from device to your API. It flows through the provider cloud, then Open Wearables, then PostgreSQL, then your application. Here is what each step looks like. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/how-to-build-ai-health-coaching-app-with-wearable-data # How to build an AI health coaching app with wearable data [All posts](https://openwearables.io/blog) [Guides](https://openwearables.io/blog/category/guides) Open Wearables Team · May 27, 2026 · 6 min read ## Key Takeaways - Building an AI health coaching app without structured wearable data access forces LLMs to rely on user-reported info, which leads to vague responses or hallucinations. - Open Wearables normalizes data from providers like Garmin, Polar, Whoop, Apple Health, and others into a single API schema, so your app queries one interface regardless of what device the user has. - The MCP server gives AI assistants (Claude Desktop, Cursor) direct, tool-based access to real user health data with four ready-to-use tools: List Users, Activity Summary, Sleep Summary, and Workout Events. - Setup takes minutes: install via uv sync, drop a config file, and restart Claude Desktop. - For production apps, call the REST API endpoints directly and build your own prompt layer on top. - Sleep Score and Resilience Score are in active development and not production-ready. Use them in prototypes, not in user-facing features. - The fastest path to a working health coaching prototype: connect Open Wearables, point an LLM at the MCP tools, and iterate on your prompt logic. ## The Problem: LLMs Without Structured Health Data You want to build something like this: a user opens your app, describes how they have been feeling, and an AI coach responds with personalized guidance based on their actual sleep, recovery, and activity data, turning health scores from wearables into actionable coaching. The gap between that vision and a working app usually comes down to data access. LLMs are capable of reasoning about health metrics when given the right inputs. The problem is getting those inputs in a reliable, structured format. Without that, you have two options, both bad. First, you ask the user to describe their own data. Accuracy depends entirely on user recall. Second, you integrate directly with each wearable provider. That means separate OAuth flows, separate data schemas, separate rate limits, and months of backend work before you can write a single line of coaching logic. Garmin's API returns sleep data differently than Whoop's. Apple Health uses different field names than Samsung Health. A workout in Strava is not the same object shape as a workout in Polar. If you want to support more than one provider, you end up building a normalization layer yourself. That is the problem Open Wearables solves. ## What Open Wearables Does Under the Hood Open Wearables is an open source backend that handles provider integrations, OAuth, data ingestion, and normalization. It supports Garmin, Polar, Suunto, Whoop, Strava, Apple Health, Samsung Health, Google Health Connect, Fitbit, and Ultrahuman, giving you unified access to health scores from wearables across all of them. The output is a single, consistent API. Every provider's sleep data maps to the same schema. Every workout event has the same field structure. Your application code talks to one API and never touches provider-specific logic. For AI-powered features, this matters a lot. When you send health data to an LLM, schema consistency directly affects the quality of the output. If the model receives inconsistently shaped data, it has to make assumptions. Consistent data means the model can focus on reasoning, not interpretation. ## The MCP Server: Direct AI Access to Health Data The Model Context Protocol is a standard for connecting AI assistants to external data sources. Open Wearables ships an MCP server that exposes health data directly to AI tools like Claude Desktop and Cursor IDE. The MCP server is decoupled from the backend and runs as a REST API client on top of your Open Wearables instance. It exposes four tools: - List Users: returns the users available for querying - Activity Summary: daily activity totals (steps, calories, active time) - Sleep Summary: sleep duration, stages, and consistency metrics - Workout Events: individual workout sessions with type, duration, and load All tools default to a two-week lookback window. ### Setup: Step by Step Prerequisites: Open Wearables backend running (`docker compose up -d`), at least one user with connected wearable data. 1. Install the MCP server: ``` cd /path/to/open-wearables/mcp uv sync ``` 2. Configure environment variables. Create `config/.env` in the MCP directory: ``` OPEN_WEARABLES_API_KEY=your_api_key OPEN_WEARABLES_API_URL=http://localhost:8000 ``` 3. Add to Claude Desktop config. On macOS, edit `~/Library/Application Support/Claude/claude_desktop_config.json`. On Windows, edit `%APPDATA%\Claude\claude_desktop_config.json`. ``` { "mcpServers": { "open-wearables": { "command": "uv", "args": ["run", "--frozen", "--directory", "/path/to/open-wearables/mcp", "start"] } } } ``` 4. Restart Claude Desktop. Test the connection by asking: "Who can I query health data for?" ### Common Issues - API key errors: double-check the key in config/.env matches your Open Wearables instance - Connection refused: your backend is not running; run docker compose up -d from the Open Wearables root - No users found: verify OPEN_WEARABLES_API_URL points to the correct host and port ## What Is Ready Today vs What Is Not Production-ready endpoints: - GET /api/v1/users/{user_id}/timeseries - GET /api/v1/users/{user_id}/events/workouts - GET /api/v1/users/{user_id}/events/sleep - Summary endpoints for activity, sleep, recovery, and body metrics In active development, not production-ready: - Sleep Score (0-100): weighted across Duration 40%, Sleep Stages 20%, Consistency 20%, Interruptions 20% - Resilience Score: based on HRV coefficient of variation from a 7-night window, requires minimum 5 nights of data Planned, not available: - Health Insights Automations - AI Health Assistant Widget ## Building a Production AI Health Coaching Flow The MCP server is the fastest way to get started, but for a production app you want more control. The right approach is to call the REST API directly from your backend and manage the LLM interaction yourself. When a user initiates a coaching session, your backend fetches the relevant summaries from the Open Wearables REST API. What you fetch depends on the coaching context: sleep coaching needs sleep and recovery data; training coaching needs workout events and activity summaries. Pass the data as structured context to the model. Be explicit about the schema so the model does not have to guess field meanings. Send the prompt to your model of choice. The coaching response is grounded in real data, so the output is specific rather than generic. Not every user will have data for every day. Build logic to detect gaps and adjust the prompt accordingly. "You have data for 9 of the last 14 days" is more accurate than silently averaging over incomplete windows. ## Quickstart ``` git clone https://github.com/the-momentum/open-wearables cd open-wearables docker compose up -d # Set up the MCP server cd mcp uv sync # Create config/.env with your API key and URL # Configure Claude Desktop (see JSON above) # Restart Claude Desktop # Ask: "Who can I query health data for?" ``` ## See Related Articles - [How to normalize wearable data across providers](https://openwearables.io/blog/how-to-normalize-wearable-data-across-providers) - [How to sync wearable data from multiple devices](https://openwearables.io/blog/how-to-sync-wearable-data-from-multiple-devices) - [Building a health app with Whoop API data](https://openwearables.io/blog/building-a-health-app-with-whoop-api-data) - [How to use Oura ring data in your app](https://openwearables.io/blog/how-to-use-oura-ring-data-in-your-app) - [Wearable API integration: comparing SaaS, custom build, and open source](https://openwearables.io/blog/wearable-api-integration-saas-custom-build-open-source) - [How to Give Your LLM Access to Wearable Data](https://openwearables.io/blog/how-to-give-your-llm-access-to-wearable-data) - [How to Structure Health Data for AI: What Your LLM Actually Needs](https://openwearables.io/blog/how-to-structure-health-data-for-ai-llm) - [How to Build an AI Agent That Reasons Over Health Data](https://openwearables.io/blog/how-to-build-ai-agent-reasons-over-health-data) ## FAQ **Can I use the MCP server in a production app?** The MCP server is designed for AI assistant interfaces like Claude Desktop and Cursor IDE. For production apps, call the Open Wearables REST API directly from your backend. The MCP server is useful for prototyping, internal tooling, and exploring the data model before you write integration code. **Which wearable providers does Open Wearables support?** The current release supports Garmin, Polar, Suunto, Whoop, Strava, Apple Health, Samsung Health, Google Health Connect, Fitbit, and Ultrahuman. All providers normalize to the same API schema. **Are the Health Scores reliable enough to show to users?** Not yet. Sleep Score and Resilience Score are in active development. Use them in internal prototypes or developer demos. For anything user-facing, build on the raw summary endpoints instead. **What happens if a user has a data gap?** Open Wearables returns data for the days where it has records. If a user missed three days, those days will not appear in the response. Your application needs to handle gaps explicitly, either by noting the gap in the prompt context or by adjusting the analysis window. **Is the data stored locally or sent to a third party?** Open Wearables is self-hosted. You run it on your own infrastructure, and health data stays within your environment. There is no external service that processes or stores user data. ## Keep reading Guides · Oct 26, 2026 · 9 min read ### Moving from a hosted wearable API to Open Wearables: a migration playbook Moving from a hosted wearable API to Open Wearables is usually a re-integration rather than a data migration. This playbook walks through the decisions, the steps in order, how your users reconnect and what to tell your security team. Guides · Oct 26, 2026 · 7 min read ### Why teams move from a hosted wearable API to Open Wearables A hosted wearable API is a sensible way to start. As a product grows, the questions change: whose provider apps, whose cloud, whose schema. Here is why teams move to Open Wearables, what they get after the move, and what it asks of them. Guides · Jul 28, 2026 · 5 min read ### How Wearable Data Flows From Device to Your API: A Complete Architecture Guide Wearable data does not go directly from device to your API. It flows through the provider cloud, then Open Wearables, then PostgreSQL, then your application. Here is what each step looks like. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/how-to-build-hipaa-compliant-health-app-wearable-data # How to Build a HIPAA-Compliant Health App That Uses Wearable Data [All posts](https://openwearables.io/blog) [Guides](https://openwearables.io/blog/category/guides) Open Wearables Team · Jul 21, 2026 · 4 min read ## Key Takeaways - HIPAA compliance is an architectural decision, not a feature you add later. The most important choice is where data lives. - Open Wearables is self-hosted: your users' health data stays on your own infrastructure and never passes through a third-party SaaS. This is the foundation of a HIPAA-ready architecture. - The platform uses bcrypt for password hashing, JWT for access tokens, Fernet encryption for provider credentials at rest, and structured access logging. These are documented in the codebase. - For covered entities, Momentum offers enterprise deployment with HIPAA-eligible architecture, encryption at rest and in transit, audit logging, role-based access, and BAA (Business Associate Agreement). - Open Wearables provides the infrastructure foundation. Whether your specific deployment meets HIPAA requirements depends on how you configure and operate it. Consult your legal and compliance team. Most health app developers encounter HIPAA late: after the architecture is set, after data is flowing, after a compliance review flags the problem. The question is not just "is our app HIPAA compliant" but "where does health data live, who controls it, and can we demonstrate that?" This article covers what Open Wearables provides at the infrastructure level and what you need to configure yourself to build toward HIPAA compliance. ## Why Self-Hosting Matters for Compliance SaaS health data APIs store your users' data on their infrastructure. You depend on their security controls, their breach notification procedures, and their BAA. If they have a breach, it affects your obligations. Self-hosted infrastructure means your users' data stays on servers you control. Your security team sets the controls. Your infrastructure determines the audit trail. Open Wearables is self-hosted by design. When you deploy it, wearable data from Garmin, Polar, Oura, Whoop, and other connected providers flows into your PostgreSQL instance on your infrastructure. It does not pass through Momentum's servers unless you explicitly use Momentum's hosting services. ## What Open Wearables Provides From the Open Wearables codebase: **Authentication and access control:** - JWT-based access tokens with configurable expiry (utils/security.py) - bcrypt password hashing for user credentials (utils/security.py) - API key authentication for developer portal access - CORS configuration with explicit origin allowlisting (middlewares.py) **Credential storage:** - Provider OAuth credentials (Client ID, Client Secret, access tokens, refresh tokens) are stored using Fernet symmetric encryption from the Python cryptography library (utils/config_utils.py) - Secrets are stored as EncryptedField types in the database, not as plaintext **Access logging:** - Structured HTTP access logging via middleware, configurable per environment (middlewares.py) - Production defaults to errors-only logging (ACCESS_LOG_LEVEL=errors) - Full request logging available via ACCESS_LOG_LEVEL=all **Transport security:** - Redis TLS support for encrypted in-transit communication to Redis (redis_ssl=True in config) **Self-hosting:** - Full deployment via Docker Compose - All services (FastAPI backend, PostgreSQL, Redis, Celery workers) run on your infrastructure ## What You Need to Configure Open Wearables provides the infrastructure foundation. HIPAA compliance requires that you configure and operate it correctly. - **Encryption at rest:** PostgreSQL does not encrypt data at rest by default. You need filesystem-level encryption on your deployment infrastructure or database-level encryption. - **Encryption in transit:** HTTPS between clients and your Open Wearables instance requires TLS termination at a load balancer or reverse proxy in front of the application. This is not configured by default. - **Audit logging:** HTTP access logging captures requests, but application-level audit trails (who accessed which user's data, when, and from where) require additional implementation on top of the base logging infrastructure. - **Backup and disaster recovery:** Data availability controls, backup policies, and recovery procedures are your responsibility. - **BAA:** If your application requires HIPAA compliance, you need a Business Associate Agreement with every vendor who handles relevant data on your behalf, including your infrastructure provider. Momentum offers BAAs for enterprise deployments. ## Enterprise Deployment Open Wearables is built and maintained by Momentum. For teams that need enterprise deployment with HIPAA-eligible architecture, encryption at rest and in transit, audit logging, role-based access, and a BAA, Momentum offers this as a commercial service. Details at [openwearables.io/pricing](https://openwearables.io/pricing). ## Related articles - [How to Handle OAuth, Webhooks, and Token Refresh Across Multiple Wearable Providers](https://openwearables.io/blog/how-to-handle-oauth-webhooks-token-refresh-wearable-providers) - [How to Give Your LLM Access to Wearable Data](https://openwearables.io/blog/how-to-give-your-llm-access-to-wearable-data) - [What wearable app development actually looks like in 2026](https://openwearables.io/blog/what-wearable-app-development-actually-looks-like-in-2026) - [How to normalize wearable data across providers](https://openwearables.io/blog/how-to-normalize-wearable-data-across-providers) - [How to Add Wearable Data to a Corporate Wellness Platform](https://openwearables.io/blog/how-to-add-wearable-data-corporate-wellness-platform) ## FAQ ### Is Open Wearables HIPAA compliant out of the box? No. HIPAA compliance is not a product feature, it is an operational posture. Open Wearables provides the self-hosting architecture, credential encryption, access logging, and JWT-based authentication that are prerequisites for HIPAA-ready deployment. Whether your deployment meets HIPAA requirements depends on how you configure and operate the infrastructure, and on the specific requirements of your use case. Consult your legal and compliance team. ### Do I need a BAA with Momentum? If you use Momentum's hosting or implementation services in a context that requires HIPAA compliance, yes. Momentum offers BAAs for enterprise deployments. If you self-host Open Wearables entirely on your own infrastructure without Momentum's involvement, the question shifts to your infrastructure provider. ### Does Open Wearables support audit logging? The platform includes structured HTTP access logging via middleware, configurable per environment. Production defaults to errors-only. Full request logging is available. Application-level audit trails (who accessed which user's data, when) require additional implementation on top of the base logging infrastructure. ### Can I deploy Open Wearables on AWS? Yes. Open Wearables runs on Docker Compose and can be deployed on any cloud provider including AWS, GCP, and Azure. You are responsible for configuring the infrastructure correctly for your compliance requirements. Momentum can assist with enterprise deployments that require this configuration. ### Where does wearable data go when a user connects a device? Data flows from the provider (Garmin, Oura, Whoop, etc.) directly into your Open Wearables PostgreSQL instance on your infrastructure. It does not pass through Momentum's servers unless you use Momentum's hosting services. ## Keep reading Guides · Oct 26, 2026 · 9 min read ### Moving from a hosted wearable API to Open Wearables: a migration playbook Moving from a hosted wearable API to Open Wearables is usually a re-integration rather than a data migration. This playbook walks through the decisions, the steps in order, how your users reconnect and what to tell your security team. Guides · Oct 26, 2026 · 7 min read ### Why teams move from a hosted wearable API to Open Wearables A hosted wearable API is a sensible way to start. As a product grows, the questions change: whose provider apps, whose cloud, whose schema. Here is why teams move to Open Wearables, what they get after the move, and what it asks of them. Guides · Jul 28, 2026 · 5 min read ### How Wearable Data Flows From Device to Your API: A Complete Architecture Guide Wearable data does not go directly from device to your API. It flows through the provider cloud, then Open Wearables, then PostgreSQL, then your application. Here is what each step looks like. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/how-to-connect-samsung-health-to-your-app # How to connect Samsung Health to your app [All posts](https://openwearables.io/blog) [Samsung Health](https://openwearables.io/blog/category/samsung-health) Open Wearables Team · May 6, 2026 · 6 min read ## Introduction Samsung Health is one of the most widely used health platforms on Android. Connecting your application to it requires working through a multi-step process that differs meaningfully from most other wearable APIs. There is a gated developer program, a non-trivial OAuth implementation, and a data schema you will need to normalize before it is useful to your product. This guide covers each step in the order you will encounter it. The payoff is access to an ecosystem that includes Galaxy Watch biometrics across tens of millions of users: continuous heart rate, HRV, stress score, sleep staging with SpO2 and breathing irregularity detection, body composition from Galaxy Watch 5 and newer, and nightly skin temperature from Galaxy Watch 6 and newer. For developers building multi-provider health apps that need solid Android coverage, Samsung Health is typically a required integration. ## Before you write code: developer program Samsung Health Platform is not a self-serve API. Before you can obtain client credentials, you must apply to the Samsung Health Developer Program through the Samsung developer portal. The application form asks for your company name, app description, intended data usage, user population, data storage and security practices, and which data types you need access to. Be specific and honest in the application. Vague descriptions of intended use or overly broad data type requests tend to slow approval or result in follow-up questions from Samsung's review team. If your use case is consumer wellness or fitness coaching, say so. If you need body composition and stress data specifically, list those data categories and explain why. Approval takes five to fifteen business days in most cases. Some applications in less common categories or with clinical data handling requirements take longer. Apply at the start of your integration planning, not when you are ready to test. If you are building with Open Wearables, the project's existing Samsung Health credentials can cover development access while you wait for your own production approval. Once approved, Samsung provides a client_id and client_secret for each environment. Keep your production credentials separate from development credentials. Treat them as secrets and do not expose them in client-side code. ## OAuth and token management Samsung Health uses OAuth 2.0 with the authorization code flow. Your app redirects users to Samsung's authorization server where they log in with their Samsung account and grant permissions. Samsung returns an authorization code which you exchange for access and refresh tokens at Samsung's token endpoint. The scopes you request determine which data types your access token can fetch. The main scopes are r:exercise for workout sessions, r:sleep for sleep records, r:health for daily metrics including heart rate, HRV, stress score and SpO2, r:body for body composition measurements, and r:profile for user profile information. Request only the scopes your application actually uses. Users see the scope list during authorization and excessive scope requests increase drop-off at the consent screen. Access tokens expire after a fixed period. Use the refresh token to obtain a new access token without requiring the user to re-authorize. Store refresh tokens securely in your backend, associated with the user's account. Handle 401 Unauthorized responses from the API by first attempting a token refresh. If the refresh also fails, the user needs to re-authenticate: surface a reconnect prompt in your UI rather than silently losing their data connection. Samsung refresh tokens do not rotate on use, which simplifies token management compared to providers like Garmin that issue a new refresh token with each exchange. Store the refresh token once and reuse it until it expires or is revoked by the user. ## Working with samsung's data model Samsung Health API endpoints are organized by data type. Exercise sessions, sleep records, daily health summaries and body composition measurements each have their own endpoint and response schema. You query each endpoint with a date range and receive paginated results. Exercise sessions include a sport_type field that uses Samsung's internal numeric sport type codes. Map these to human-readable activity names using the sport type reference table in Samsung's developer documentation. Common mappings: 1001 for running, 1002 for walking, 11007 for cycling, 2009 for swimming. For unrecognized sport types, fall back to a generic activity label rather than dropping the session. Heart rate data within exercise sessions comes as a time series of readings at one-minute intervals. For summary statistics, Samsung provides mean and max. For aggregated daily resting heart rate, query the health endpoint for the relevant date range. Sleep data is organized into a parent record with overall summary statistics and child records for each sleep stage interval. The stage values are: 1 for awake, 2 for light, 3 for deep and 4 for REM. Total duration is in minutes. Parse child records to build a sleep stage timeline if your product surfaces granular sleep architecture. Stress score appears as a time series within the daily health response. Each data point has a timestamp and a score from 0 to 100. To show a daily stress summary, compute the mean across the day's readings or identify peak stress windows. ## Samsung-specific features in product context Samsung's continuous stress score is the most productively distinctive metric in the Samsung Health data model. Unlike recovery scores that are computed once per morning, stress score updates throughout the day as HRV is measured during non-exercise periods. This enables product features that are simply not possible with providers that only measure overnight. Practical uses for intraday stress data include: identifying time-of-day stress patterns over weeks (for example, stress consistently peaks between 2pm and 4pm on workdays), correlating high-stress days with poor sleep scores the following night, and triggering wellness check-ins or breathing exercise recommendations when stress readings spike. Body composition from Galaxy Watch 5 and newer is measured via BIA. The measurement requires the user to hold specific contact points on the watch. Results include body fat percentage, skeletal muscle mass, body water percentage and BMI. These measurements are point-in-time rather than continuous, so users will have one or a few readings per day rather than a time series. Treat them as periodic assessments and track trend over weeks. Skin temperature from Galaxy Watch 6 and newer is a nightly measurement recorded during sleep. Samsung reports it as a deviation from the user's established baseline rather than an absolute temperature. A positive deviation may indicate elevated recovery burden, illness or hormonal cycle phase. Surface it similarly to how Oura presents temperature deviation: as a trend signal rather than a standalone daily alarm. ## Handling device heterogeneity Not all Samsung Health users have a Galaxy Watch. The Samsung Health app also runs on Android phones and aggregates data from manual entries and third-party apps. When a user connects Samsung Health, you will not always know their hardware. Design your data pipeline to handle missing fields gracefully. A user without a Galaxy Watch will have no HRV, no stress score and no SpO2. A user with a Galaxy Watch 4 or older will have no body composition and no skin temperature. Nullable fields in your schema and conditional logic in your product UI are both required. You can infer approximate hardware from which metrics appear in the data, but this is fragile as a long-term approach since users change devices and data availability changes with firmware updates. It is better to surface available metrics dynamically based on what the API returns for each user rather than hardcoding feature sets by inferred device model. ## Open Wearables Open Wearables is an open-source platform that connects your application to wearable and health data providers through a single API. One normalized data model, multi-provider support in a single self-hosted deployment, no per-user fees, MIT licensed, and health intelligence built in: normalized recovery, sleep, activity and biometric data ready for your product layer. We offer custom deployment and integration support through Momentum. If your team needs help getting to production faster, we can set up and configure Open Wearables as part of a managed engagement. [Let's talk](https://www.themomentum.ai/lets-talk). [Book a demo](https://openwearables.io/book) to see how Open Wearables fits your use case. ## Samsung Health integration View the full [Samsung Health integration documentation](https://openwearables.io/integrations/samsung-health) on Open Wearables. ## See related articles [Samsung Health API: Galaxy Watch Data for Developers](https://openwearables.io/blog/samsung-health-api-galaxy-watch-data-for-developers) [Google Health Connect Integration: Android Health Data for Developers](https://openwearables.io/blog/google-health-connect-integration-android-health-data-for-developers) [Garmin Connect API: Developer Guide for Activities and Health Metrics](https://openwearables.io/blog/garmin-connect-api-developer-guide-activities-health-metrics) ## Keep reading Samsung Health · Jun 6, 2026 · 4 min read ### Samsung Health API integration guide for Android developers Samsung Health API is not a cloud API. It requires an on-device SDK. Learn how Open Wearables Android SDK handles permissions, background sync, and normalization. Samsung Health · May 6, 2026 · 5 min read ### Samsung Health API: Galaxy Watch data for developers Samsung Health Platform provides server-side API access to Galaxy Watch data including heart rate, sleep stages, workouts, stress score, SpO2, HRV and body composition. Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/how-to-customize-open-wearables # How to customize Open Wearables for your product [All posts](https://openwearables.io/blog) [Guides](https://openwearables.io/blog/category/guides) Bartosz Michalak · May 14, 2026 · 4 min read Open Wearables gives you a working foundation: unified wearable data, normalized across providers, self-hosted on your infrastructure. For many teams, that foundation is exactly what they need. For others, the product requires more. A clinical platform needs scoring calibrated to patient populations, not general consumers. A corporate wellness tool needs deployment on a specific cloud with audit trail configuration. A performance app needs a readiness score that reflects the logic of their coaching methodology, not a generic algorithm. Open Wearables is designed to be adapted. Here is what that looks like in practice. ## What you can customize ### Health scoring algorithms The default Open Wearables scoring covers sleep and resilience. Every algorithm is published and auditable. You can read the code, understand the thresholds, and modify them. Customization at this level means: **Adjusting population thresholds.** A score calibrated for recreational athletes performs differently on sedentary office workers or post-surgical patients. The algorithm needs to know who it is scoring. **Weighting inputs differently.** A longevity platform might weight HRV trends more heavily than acute strain. A clinical product might deprioritize exercise load entirely. **Building entirely new scores.** Metabolic tracking, cognitive recovery, medication adherence signals. If the data exists in the platform, a score can be built on top of it. This is not configuration. It is algorithm development, which is why Momentum's approach involves a dedicated health scientist from day one. ### Provider integrations Open Wearables ships with live integrations for all major wearable platforms. If your product needs a provider that is not on the list, a proprietary enterprise wearable, a legacy SDK, or a medical-grade device, Momentum builds the integration on top of the existing architecture. Custom integrations follow the same normalized schema as the rest of the platform. ### Deployment and infrastructure The open-source version runs on Docker Compose or Railway. Enterprise deployments go further: AWS, GCP, Azure, or on-premises, with HIPAA-eligible architecture, audit trail configuration, encryption, access controls, and network isolation. For teams with specific compliance requirements, Momentum handles the full infrastructure build and provides documentation for security reviews and BAAs. ## The science behind custom scoring Custom health scoring at Momentum is led by Anna Zych, PhD, an exercise physiologist with a research background in wearable data interpretation. The practical implication: custom scores are grounded in the literature, not engineering intuition alone. When a threshold is set, there is a reason for it. When an algorithm weights HRV differently for a 60-year-old than a 25-year-old, that decision is documented and explainable. For products in clinical or regulated contexts, that explainability matters. A score that cannot be justified to a medical review board is not deployable. Momentum's process produces scores that can be. The six core score types available as custom implementations: - Sleep score. Quality based on HRV, sleep stages, and resting heart rate, weighted against the user’s individual baseline. - Recovery score. Overnight recovery measured against personal baselines using HRV trends and resting heart rate. - Strain score. Cumulative cardiovascular load across training and daily activity, calibrated to individual capacity. - Resilience score. Long-term adaptation to stress combining sleep quality, recovery trends, and HRV data. - Readiness score. Daily actionable signal combining sleep, recovery, and strain into one number. - Custom scores. Tailored algorithms for clinical populations, metabolic tracking, or cognitive recovery. ## The customization process Momentum works on customizations through a five-phase process. **Discovery (one week).** Map your user population, data sources, and product goals. What devices do your users have? What does a good score mean in your context? **Scoping.** Propose architecture, metrics, and algorithms with technical specifications. Define what gets built, how it integrates with your stack, and what the timeline looks like. **Development and integration.** Build and deploy on your infrastructure. Custom scoring algorithms ship as API endpoints alongside the standard Open Wearables API. **Compliance and QA.** Document methodology with auditable thresholds, ready for security reviews and regulatory scrutiny. **Launch and support.** Thirty days of post-launch tuning with direct engineer access. ## Enterprise support The open-source tier is free forever and covers all wearable provider integrations, basic health scoring algorithms (sleep and resilience), REST API and webhooks, Docker Compose deployment, and community Discord support. Enterprise support is where Momentum's team gets directly involved. The enterprise tier includes everything in the open-source plan plus: - SLA-backed support with guaranteed response times - Dedicated Slack channel with named engineers on your project - HIPAA-eligible infrastructure with full compliance documentation - BAA and GDPR documentation ready for your legal and security review - Custom health score design and implementation by Anna Zych, PhD and Momentum’s engineering team - Custom provider integrations for platforms not in the standard library - Deployment on AWS, GCP, Azure, or on-premises - Security questionnaire support for enterprise sales processes - Quarterly architecture review as your product and user base grow Momentum has delivered 220+ healthtech projects over 10 years. The team that built Open Wearables is the same team that works on enterprise customizations. ## Starting points Most engagements start in one of two places. **You have deployed Open Wearables and hit a ceiling.** The default scoring does not fit your population. A provider you need is missing. Your compliance team has requirements the standard deployment does not cover. **You are evaluating Open Wearables for a new product.** You want to understand what is possible before committing to the architecture. Momentum can scope what custom development would look like before you start. In both cases the starting point is the same: a discovery call to map what you have, what you need, and what it takes to get there. See the full [pricing and support options](https://openwearables.io/pricing) or [book a demo](https://openwearables.io/book) to talk through your use case. ## Keep reading Guides · Oct 26, 2026 · 9 min read ### Moving from a hosted wearable API to Open Wearables: a migration playbook Moving from a hosted wearable API to Open Wearables is usually a re-integration rather than a data migration. This playbook walks through the decisions, the steps in order, how your users reconnect and what to tell your security team. Guides · Oct 26, 2026 · 7 min read ### Why teams move from a hosted wearable API to Open Wearables A hosted wearable API is a sensible way to start. As a product grows, the questions change: whose provider apps, whose cloud, whose schema. Here is why teams move to Open Wearables, what they get after the move, and what it asks of them. Guides · Jul 28, 2026 · 5 min read ### How Wearable Data Flows From Device to Your API: A Complete Architecture Guide Wearable data does not go directly from device to your API. It flows through the provider cloud, then Open Wearables, then PostgreSQL, then your application. Here is what each step looks like. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/how-to-give-your-llm-access-to-wearable-data # How to Give Your LLM Access to Wearable Data [All posts](https://openwearables.io/blog) [Guides](https://openwearables.io/blog/category/guides) Open Wearables Team · Jul 21, 2026 · 8 min read ## Key Takeaways - Raw wearable data pasted into LLM context is not the same as structured health data. The format matters as much as the content. - MCP (Model Context Protocol) is an open standard for connecting AI assistants to external data sources through defined tools. Open Wearables ships an MCP server as part of the repository. - The Open Wearables MCP server exposes five tools that give any compatible LLM structured, queryable access to health data from any connected provider. - The MCP server is designed for AI assistant interfaces (Claude Desktop, Cursor IDE). For production apps, call the Open Wearables REST API directly from your backend. - The difference between an LLM that reads health numbers and one that reasons about them is the layer underneath: normalized data, consistent units, and a query interface the model can use reliably. Most LLM integrations with health data follow the same pattern: dump a CSV or a JSON blob into the context, ask the model a question, and hope the output makes sense. It rarely does. The model reads numbers back at you. It has no framework for what those numbers mean, no sense of whether a resting heart rate of 58 bpm is good or concerning for this specific user, and no way to connect patterns across metrics over time. This article covers how the Model Context Protocol works with wearable data, what Open Wearables ships today, and how to structure the integration so your LLM reasons about health data instead of just reading it. ## Why Dumping Raw Data Into Context Does Not Work A typical workout record from a wearable provider contains a mix of timestamps, distances, heart rate values, and activity identifiers. Each provider uses different field names, different units, and different timestamp formats. Garmin, Polar, and Apple Health all represent a running workout differently at the API level. Even if you normalize this yourself before including it in context, you still have a larger problem: context is not a database. An LLM receiving 90 days of workout records, heart rate time series, and sleep data will hit the context limit before it can reason meaningfully. And even within the limit, the model does not know which data points matter for the question being asked. The solution is not to give the model more data. It is to give the model tools to query the right data for the right question. ## What MCP Is and Why It Matters for Health Data Model Context Protocol is an open standard developed by Anthropic for connecting AI assistants to external data sources and tools. Instead of embedding data directly in the prompt, you expose a set of tools that the model can call during reasoning. The model decides which tool to call, with which parameters, and uses the result to construct its response. For health data, this is the right architecture. A model with a get_workout_events tool can retrieve the last 7 days of activity data when asked about training load, without needing all of it pre-loaded in context. A model with a get_users tool can identify which users it has data for before answering a question about a specific person. MCP is supported natively by Claude Desktop and Cursor IDE. Other LLM interfaces are adding support as the standard becomes more widely adopted. ## What the Open Wearables MCP Server Provides Open Wearables ships an MCP server in the mcp/ directory of the repository. It runs as a REST API client on top of your Open Wearables instance and exposes five tools to any connected AI assistant: - **get_users**: returns the list of users accessible via your API key, with optional name or email filtering - **get_workout_events**: retrieves workout and exercise sessions for a specific user within a date range - **get_sleep_summary**: retrieves sleep data for a specific user within a date range, including per-night records and aggregated summary - **get_activity_summary**: retrieves daily activity data (steps, calories, heart rate, intensity minutes) for a specific user - **get_timeseries**: retrieves granular time-series samples (weight, SpO2, HRV, intraday heart rate) for a specific user and time window All data returned by these tools follows the Open Wearables unified data model. Units are normalized across providers. Timestamps are UTC. The model receives consistent structure regardless of which provider the data came from. ## Setting Up the MCP Server The MCP server lives in the mcp/ directory of the Open Wearables repository. Prerequisites: uv package manager version 0.9.17 or later, a running Open Wearables instance, and a valid API key. Step 1: Install dependencies ``` cd mcp uv sync --group code-quality ``` Step 2: Configure environment variables ``` cp config/.env.example config/.env ``` Edit config/.env with your instance details: ``` OPEN_WEARABLES_API_URL=http://localhost:8000 OPEN_WEARABLES_API_KEY=ow_your_api_key_here ``` Step 3: Test the server locally ``` uv run start ``` Step 4: Register with Claude Desktop Add the following to ~/Library/Application Support/Claude/claude_desktop_config.json on macOS: ``` { "mcpServers": { "open-wearables": { "command": "uv", "args": [ "run", "--frozen", "--directory", "/path/to/open-wearables/mcp", "start" ] } } } ``` Replace /path/to/open-wearables/mcp with the actual path to the mcp/ directory. Restart Claude Desktop after saving. Step 5: Verify the connection by opening Claude Desktop and asking: "Who can I query health data for?" The model calls get_users and returns the users connected to your Open Wearables instance. ## What the Interaction Looks Like in Practice Without the MCP server, a prompt like "How has this user's training load changed over the past two weeks?" produces a generic response or asks you to provide the data manually. With the MCP server connected, the model calls get_users to identify the user, then get_workout_events with a date range covering the last 14 days, receives normalized workout records including duration, distance, average heart rate, and activity type, identifies trends across the returned records, and produces a response grounded in the actual data. From the Open Wearables MCP documentation, a sleep query looks like this in practice: ``` User: "How much sleep did John get last week?" Claude: [calls get_users() to get John's user_id] Claude: [calls get_sleep_summary(user_id="uuid-1", start_date="2026-01-28", end_date="2026-02-04")] Claude: "John slept an average of 7 hours and 45 minutes over the last week. His longest sleep was 8h 15m on Monday, and shortest was 6h 30m on Thursday." ``` The model is not hallucinating or reasoning from incomplete information. It is calling a tool, receiving structured data, and synthesizing a response from that data. ## MCP Server vs. REST API: When to Use Which The MCP server is the right choice for AI assistant interfaces (Claude Desktop, Cursor IDE), internal tooling where a developer or analyst queries health data through a chat interface, and prototyping and exploring the data model before writing integration code. For production applications, call the Open Wearables REST API directly from your backend. The REST API gives you full control over how data is retrieved, how it is passed to the LLM, and how the response is processed. The MCP server is a layer on top of the REST API, designed for interactive AI assistant use cases, not for embedding in an application backend. ``` curl -H "X-API-Key: YOUR_API_KEY" \ "http://localhost:8000/api/v1/workouts?user_id=USER_ID&from=2026-07-01&to=2026-07-21" ``` The response follows the same normalized data model the MCP server returns. You retrieve the data, format it for your LLM, and manage the model interaction yourself. ## What You Still Need to Handle Yourself The MCP server and the Open Wearables REST API give you structured, normalized health data. They do not give you a health reasoning system out of the box. For a production AI health feature, you still need to decide which data to retrieve for which question (a question about recovery requires different data than a question about training volume), how to frame the context (health data without reference ranges is hard to interpret), and what the model should and should not recommend (health data applications operate near clinical territory and need guardrails). Open Wearables provides the data layer. The intelligence layer is what you build on top. ## Related articles - [How to build an AI health coaching app with wearable data](https://openwearables.io/blog/how-to-build-ai-health-coaching-app-with-wearable-data) - [How to normalize wearable data across providers](https://openwearables.io/blog/how-to-normalize-wearable-data-across-providers) - [What wearable app development actually looks like in 2026](https://openwearables.io/blog/what-wearable-app-development-actually-looks-like-in-2026) - [Garmin Connect API: What You Can Fetch and How to Do It Faster](https://openwearables.io/blog/garmin-connect-api-what-you-can-fetch) - [How to Structure Health Data for AI: What Your LLM Actually Needs](https://openwearables.io/blog/how-to-structure-health-data-for-ai-llm) - [How to Add Wearable Data to a Corporate Wellness Platform](https://openwearables.io/blog/how-to-add-wearable-data-corporate-wellness-platform) - [How to Build an AI Agent That Reasons Over Health Data](https://openwearables.io/blog/how-to-build-ai-agent-reasons-over-health-data) ## FAQ ### Does the MCP server work with models other than Claude? MCP support varies by model and interface. Claude Desktop and Cursor IDE have native MCP support. Other interfaces are adding support as the standard gains adoption. For model-agnostic integrations, use the Open Wearables REST API directly and manage the model interaction in your application code. ### Can I use the MCP server in a production application? The MCP server is designed for AI assistant interfaces, not for embedding in a production backend. For production use, call the Open Wearables REST API from your backend and pass the data to the LLM in whatever format fits your application architecture. ### What data is available through the MCP tools? The five MCP tools expose workouts, sleep data, daily activity aggregates (steps, calories, heart rate, intensity minutes), and high-frequency time series data (SpO2, HRV, intraday heart rate). Data availability depends on which providers your users have connected. The full data model is documented at docs.openwearables.io. ### Does Open Wearables store the data, or does it query providers in real time? Open Wearables stores normalized data in your PostgreSQL instance. Providers push data via webhooks or Open Wearables polls them on a schedule. When the MCP server calls a tool, it queries your local database, not the provider API directly. Response times are fast and you are not dependent on provider API availability for every query. ### Can I extend the MCP server with custom tools? The MCP server ships as open source under the MIT license. You can add custom tools that expose additional data or perform domain-specific operations. The architecture is decoupled from the backend and communicates via REST API, which makes it straightforward to extend. Full architecture details are in mcp/README.md in the repository. ## Keep reading Guides · Oct 26, 2026 · 9 min read ### Moving from a hosted wearable API to Open Wearables: a migration playbook Moving from a hosted wearable API to Open Wearables is usually a re-integration rather than a data migration. This playbook walks through the decisions, the steps in order, how your users reconnect and what to tell your security team. Guides · Oct 26, 2026 · 7 min read ### Why teams move from a hosted wearable API to Open Wearables A hosted wearable API is a sensible way to start. As a product grows, the questions change: whose provider apps, whose cloud, whose schema. Here is why teams move to Open Wearables, what they get after the move, and what it asks of them. Guides · Jul 28, 2026 · 5 min read ### How Wearable Data Flows From Device to Your API: A Complete Architecture Guide Wearable data does not go directly from device to your API. It flows through the provider cloud, then Open Wearables, then PostgreSQL, then your application. Here is what each step looks like. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/how-to-handle-oauth-webhooks-token-refresh-wearable-providers # How to Handle OAuth, Webhooks, and Token Refresh Across Multiple Wearable Providers [All posts](https://openwearables.io/blog) [Guides](https://openwearables.io/blog/category/guides) Open Wearables Team · Jul 21, 2026 · 6 min read ## Key Takeaways - Every wearable provider implements OAuth differently. Garmin uses OAuth 2.0 with PKCE. Polar, Suunto, Strava, Oura, and Whoop also use OAuth 2.0. Apple Health does not use OAuth at all and requires a mobile SDK. - Data delivery models differ per provider. Garmin pushes full payloads via webhook stream and supports webhook callback for historical backfill. Whoop, Oura, Polar, and Strava send lightweight webhook pings that trigger a follow-up REST pull. - Token refresh is handled automatically by Open Wearables for all OAuth providers. Your application code does not manage token expiry. - Open Wearables implements OAuth state validation with PKCE support, Redis-backed state storage with a 15-minute TTL, and structured logging for every auth event. - Your application triggers the authorization flow with a single redirect. Open Wearables handles the OAuth handshake, token storage, and ongoing sync. Building wearable integrations looks straightforward until you try to support more than one provider. Each provider has a different OAuth variant, a different mechanism for delivering data to your backend, and different token lifecycle rules. What works for Polar does not apply to Garmin. What works for Garmin does not apply to Apple Health at all. This article describes what each major provider requires, how Open Wearables abstracts those differences, and what you still need to handle in your application. ## OAuth Across Providers All cloud-based providers in Open Wearables use OAuth 2.0. The flows share the same structure but differ in scopes, token expiry, and optional security extensions. Garmin uses OAuth 2.0 with PKCE (Proof Key for Code Exchange). PKCE is a security extension that prevents authorization code interception attacks. Open Wearables handles the PKCE code challenge and verifier generation automatically. Polar, Suunto, Strava, Oura, Whoop, and Fitbit use standard OAuth 2.0 without PKCE. Each has its own authorization server URL, scope naming conventions, and token format. Strava in particular updated its developer program significantly in 2026, introducing new access tiers and retiring several endpoints. For the full picture, see the [Strava API 2026 developer guide](https://openwearables.io/blog/strava-api-developer-guide-activities-heart-rate-gps-data). Apple Health does not expose a backend API. There is no OAuth flow. Data comes through the HealthKit SDK on the user's iOS device. Your application needs a mobile component using HealthKit to read data and send it to your Open Wearables instance. Open Wearables ships a Flutter SDK for this. Google Health Connect and Samsung Health are similarly SDK-based on Android. No backend OAuth, no webhook delivery. ## The Authorization Flow in Open Wearables For OAuth-based providers, Open Wearables implements the authorization flow using Redis for state management. When a user initiates a connection, Open Wearables generates a cryptographically random state token (32 bytes, URL-safe Base64), stores it in Redis with a 15-minute TTL, and constructs the provider's authorization URL. For Garmin, it also generates a PKCE code challenge at this step. The user is redirected to the provider's login page, approves access, and is sent back to the Open Wearables callback endpoint with an authorization code. Open Wearables validates the state against Redis, exchanges the code for access and refresh tokens, fetches the user's provider profile, and saves the connection. Your application triggers this with a single call to the Open Wearables authorize endpoint: ``` GET /api/v1/oauth/{provider}/authorize?user_id={user_id} ``` Open Wearables returns the provider authorization URL. Your frontend redirects the user there. The rest of the handshake happens inside Open Wearables. ## How Data Gets to Your Backend After authorization, data delivery depends on the provider's architecture. Open Wearables handles all delivery models transparently, but understanding them helps when debugging sync issues. - **Webhook stream** (Garmin): The provider pushes the complete data payload directly to a registered webhook endpoint. Open Wearables receives, processes, and normalizes the payload. Garmin uses this model for live sync. - **Webhook callback** (Garmin historical backfill): You initiate a REST request asking the provider to export data for a time range. The provider processes the request asynchronously and pushes the result to your registered webhook. - **Webhook ping with REST pull** (Whoop, Oura, Polar, Strava): The provider sends a lightweight notification indicating new data is available. Open Wearables receives the ping, then makes a follow-up REST call to fetch the actual data. - **Mobile SDK** (Apple Health, Google Health Connect, Samsung Health): Data flows from the device to your Open Wearables instance through the SDK client. In practice this means a user connected to both Garmin and Strava has data arriving through two entirely different architectures simultaneously. Open Wearables normalizes both into the same EventRecord and DataPointSeries model. Your application queries the same endpoints regardless of which provider the data came from. ## Token Refresh Across Providers Token expiry and refresh is one of the most common sources of production bugs in wearable integrations. Open Wearables handles token refresh automatically for all OAuth providers. When a sync attempt encounters an expired token, the platform uses the stored refresh token to obtain a new access token before retrying. Your application code does not see expired tokens or handle refresh logic. Open Wearables also implements refresh token rotation: when a refresh token is used, the old one is revoked and a new one is issued. Token data is stored encrypted in your PostgreSQL instance. ## What Open Wearables Handles vs. What You Handle **Open Wearables handles:** - OAuth state generation, Redis storage, and validation - PKCE for Garmin - Authorization code exchange for access and refresh tokens - Token refresh for all OAuth providers - Refresh token rotation - Webhook endpoint registration with providers that support it (Garmin, Oura, Strava, Polar) - Incoming webhook payload processing and normalization - Celery-based scheduled sync for providers that support polling - Deduplication across providers for the same user **Your application handles:** - Triggering the authorization flow (redirect to the Open Wearables authorize endpoint) - Storing your provider API credentials as environment variables in your Open Wearables instance - Applying for developer credentials with each provider - Registering your redirect URI with each provider's developer portal - Querying the normalized Open Wearables API for data ## Provider Credential Setup Open Wearables uses your own developer credentials with each provider. You register your application directly with Garmin, Polar, Strava, and so on, obtain a Client ID and Client Secret, and configure them in your Open Wearables environment. For example, for Strava: ``` STRAVA_CLIENT_ID=your_client_id STRAVA_CLIENT_SECRET=your_client_secret ``` The full list of required environment variables per provider is documented at docs.openwearables.io/provider-setup. Provider approval timelines vary. Garmin requires Partner Program approval before issuing production credentials. Most other providers issue credentials immediately through a self-service developer portal. ## Related articles - [How to Give Your LLM Access to Wearable Data](https://openwearables.io/blog/how-to-give-your-llm-access-to-wearable-data) - [How to normalize wearable data across providers](https://openwearables.io/blog/how-to-normalize-wearable-data-across-providers) - [Garmin Connect API: What You Can Fetch and How to Do It Faster](https://openwearables.io/blog/garmin-connect-api-what-you-can-fetch) - [What wearable app development actually looks like in 2026](https://openwearables.io/blog/what-wearable-app-development-actually-looks-like-in-2026) - [How Wearable Data Flows From Device to Your API: A Complete Architecture Guide](https://openwearables.io/blog/how-wearable-data-flows-device-to-api-architecture) ## FAQ ### Do users need accounts on each wearable platform? No. Users connect their existing accounts through the OAuth flow. They do not need to create new accounts. The only exception is Apple Health, which requires the Open Wearables mobile SDK rather than a backend OAuth flow. ### How long does provider credential approval take? The Garmin Connect Developer Program is currently not accepting new applications. The official access request form at garmin.com shows: "Stay tuned for more updates on the program." If you are planning an integration that requires Garmin, check the current status at the Garmin developer portal before committing to a timeline. Other providers (Strava, Polar, Oura, Whoop) issue credentials through a self-service developer portal with no approval delay. ### What happens when a user revokes access? The provider stops sending data and returns 401 errors on any sync attempt. Open Wearables detects this and marks the connection as disconnected. The user needs to go through the authorization flow again to reconnect. ### Can I use Open Wearables alongside an existing direct provider integration? Yes. Open Wearables works independently. You can add providers through Open Wearables while keeping existing direct integrations. The unified API means you can gradually migrate or run both in parallel. ### Does Open Wearables support outbound webhooks to notify my system when new data arrives? As of the current release, outbound webhooks from Open Wearables to your backend when new data arrives are on the active roadmap. In the meantime, you can poll the Open Wearables REST API or use the Celery task queue for scheduled processing. Check the GitHub repository for current implementation status. ## Keep reading Guides · Oct 26, 2026 · 9 min read ### Moving from a hosted wearable API to Open Wearables: a migration playbook Moving from a hosted wearable API to Open Wearables is usually a re-integration rather than a data migration. This playbook walks through the decisions, the steps in order, how your users reconnect and what to tell your security team. Guides · Oct 26, 2026 · 7 min read ### Why teams move from a hosted wearable API to Open Wearables A hosted wearable API is a sensible way to start. As a product grows, the questions change: whose provider apps, whose cloud, whose schema. Here is why teams move to Open Wearables, what they get after the move, and what it asks of them. Guides · Jul 28, 2026 · 5 min read ### How Wearable Data Flows From Device to Your API: A Complete Architecture Guide Wearable data does not go directly from device to your API. It flows through the provider cloud, then Open Wearables, then PostgreSQL, then your application. Here is what each step looks like. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/how-to-integrate-apple-health-api-into-your-backend # How to integrate Apple Health API into your backend [All posts](https://openwearables.io/blog) [Apple Health](https://openwearables.io/blog/category/apple-health) Open Wearables Team · Jun 5, 2026 · 4 min read ## Key Takeaways - Apple Health does not expose a server-side REST API. All access requires an on-device SDK that pushes health records to your backend. - Open Wearables provides the mobile SDK (iOS Swift, Flutter, React Native) along with the self-hosted backend that receives and normalizes that data. - Your backend generates a short-lived token via `POST /api/v1/users/{user_id}/token`. The SDK uses this token. Your `app_id` and `app_secret` never leave the server. - Apple Health API offers the broadest coverage: steps, heart rate, HRV, VO2 max, sleep stages, workouts, blood oxygen, body composition, respiratory rate, and 100+ additional metrics. - For users who want to export their full Health history, Open Wearables supports XML import for both small and large files. - Cloud sync is not available for Apple Health. If your product is web-only or has no iOS app, Apple Health is not a viable source. - The stack is MIT-licensed with no per-user fees. ## Why There Is No Apple Health API in the Traditional Sense If you search for "Apple Health API", you will find HealthKit documentation. HealthKit is an on-device framework. There is no server-side endpoint you can call with a token to pull a user's step count or sleep data. Apple does not expose that data to third-party backends directly. Apple Health data lives in the HealthKit store on the user's iPhone and is accessible only to apps running on that device with explicit user permission. The standard integration pattern is: your iOS app reads from HealthKit, then sends the data to your backend. The work that lands on you: parsing HealthKit objects, handling background delivery, managing token refresh, deduplicating records across sync sessions, normalizing units. All of that happens before you write a single line of business logic. Open Wearables handles that entire layer. ## What Open Wearables Does Under the Hood The architecture has two layers. **SDK layer (on-device).** The Open Wearables mobile SDK runs inside your iOS app. It requests HealthKit permissions, reads the relevant data types, and pushes records to your backend at `POST {host}/api/v1/sdk/users/{userId}/sync`. Background sync is handled by the SDK including automatic token refresh and retry logic. Credentials are stored in Keychain on iOS. **Backend normalization layer (self-hosted).** The Open Wearables backend receives raw HealthKit payloads, normalizes them into a unified schema, deduplicates records by `external_id`, and makes them available through a consistent REST API. ## Backend Setup: Token Generation Your backend generates a token pair for each user: ``` POST /api/v1/users/{user_id}/token ``` This returns an `access_token` and a `refresh_token`. Pass these tokens to the mobile SDK. The SDK handles all subsequent refreshes automatically. Never embed `app_id` or `app_secret` in the mobile app binary. Token generation must happen server-side. ## SDK Integration **iOS (Swift)** ``` sdk.configure(host: "https://your-backend.com") sdk.signIn( userId: credentials.userId, accessToken: credentials.accessToken, refreshToken: credentials.refreshToken ) sdk.startBackgroundSync(syncDaysBack: 90) ``` **Flutter (Dart)** ``` await OpenWearablesHealthSdk.configure( host: 'https://your-backend.com', ); final user = await OpenWearablesHealthSdk.signIn( userId: credentials['userId'], accessToken: credentials['accessToken'], refreshToken: credentials['refreshToken'], ); await OpenWearablesHealthSdk.startBackgroundSync(syncDaysBack: 90); ``` The `HealthDataType` enum covers the data types the SDK will request: `steps`, `heartRate`, `restingHeartRate`, `sleep`, `workout`, `activeEnergy`, `bodyMass`, and more. ## What the Backend Receives and How to Query It After sync, data is available through the Open Wearables REST API: ``` GET /api/v1/users/{user_id}/timeseries GET /api/v1/users/{user_id}/events/workouts GET /api/v1/users/{user_id}/events/sleep ``` All responses use a normalized schema regardless of the source provider. ## XML Import Path Apple allows users to export their full Health history as an XML archive. **Small files (under 10 MB):** ``` POST /api/v1/users/{user_id}/import/apple/xml/direct ``` **Large files:** ``` POST /api/v1/users/{user_id}/import/apple/xml/s3 ``` The S3 endpoint accepts `filename` (max 200 chars), `expiration_seconds` (60-3600), `max_file_size` (default 50 MB). Import processing is asynchronous. Records with the same `external_id` will not be duplicated. ## Quickstart ``` git clone https://github.com/the-momentum/open-wearables cd open-wearables docker compose up -d ``` API at `http://localhost:8000`. Auth via `X-Open-Wearables-API-Key` header. ## See Related Articles - [How to integrate Apple Health data into your app](https://openwearables.io/blog/how-to-integrate-apple-health-data-into-your-app) - [Getting Apple Health data into your backend](https://openwearables.io/blog/getting-apple-health-data-into-your-backend) - [How to sync wearable data from multiple devices](https://openwearables.io/blog/how-to-sync-wearable-data-from-multiple-devices) - [How to normalize wearable data across providers](https://openwearables.io/blog/how-to-normalize-wearable-data-across-providers) - [Wearable API integration: comparing SaaS, custom build, and open source](https://openwearables.io/blog/wearable-api-integration-saas-custom-build-open-source) ## FAQ **Is there a way to access Apple Health API data without a mobile SDK?** No. Apple does not provide a server-side API for HealthKit data. Open Wearables handles the SDK side of this; you embed it into your existing iOS app. **What happens if the user's phone is offline when a sync is scheduled?** The SDK queues pending syncs locally and retries when connectivity is restored. Background sync is managed by iOS's background task scheduling. **Does Open Wearables support Android alongside iOS?** Yes. The Android SDK reads from Google Health Connect using the same token flow and backend endpoint. Apple Health specifically is iOS-only. **How does deduplication work across multiple sync sessions?** Each health record has an `external_id` derived from HealthKit's internal UUID. When the SDK sends a batch, the backend checks whether a record with that `external_id` already exists. If it does, the record is skipped. **Can I control which health data types the SDK requests access to?** Yes. You configure the set of `HealthDataType` values during SDK initialization. The SDK will only request HealthKit permissions for the types you specify. ## Keep reading Apple Health · May 20, 2026 · 4 min read ### How to integrate Apple Health data into your app A practical apple health integration guide using Open Wearables. Learn the two paths: mobile SDK for real-time background sync and XML import for historical HealthKit exports. Apple Health · May 6, 2026 · 6 min read ### Getting Apple Health data into your backend There is no server-side Apple Health API. Getting data to your backend means building an iOS pipeline: permissions, observer queries, background delivery and reliable upload. Apple Health · May 4, 2026 · 7 min read ### Apple HealthKit API: what data you can access and how HealthKit is an on-device framework, not a remote API. There is no server-side Apple Health endpoint. Here's what's available, how permissions work, and what building an integration really requires. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/how-to-integrate-apple-health-data-into-your-app # How to integrate Apple Health data into your app [All posts](https://openwearables.io/blog) [Apple Health](https://openwearables.io/blog/category/apple-health) Open Wearables Team · May 20, 2026 · 4 min read ## Key Takeaways - Apple Health does not expose a server-side REST API. The only way to read HealthKit data is on-device, which means your integration requires a mobile SDK. - Open Wearables provides native iOS (Swift), Flutter (Dart), and React Native (TypeScript) SDKs that handle HealthKit permissions, observer queries, and background sync automatically. - Authentication follows a secure token flow: your backend calls `POST /api/v1/users/{user_id}/token` with app credentials and returns the resulting access and refresh tokens to the mobile app. App credentials must never be embedded in client code. - The SDK stores tokens in Keychain (iOS) or EncryptedSharedPreferences (Android) and handles token refresh automatically. - Background sync uses iOS BGTaskScheduler and HealthKit observer queries, persists sync state across app restarts, and posts data to `POST {host}/api/v1/sdk/users/{userId}/sync`. - For users with existing Apple Health exports (XML files), you can import them via REST API without any mobile SDK. - Open Wearables is MIT-licensed, self-hosted, and free per user. Run the full stack locally with `docker compose up -d`. Apple Health integration gives you access to some of the richest health data available on any consumer platform. Heart rate, steps, workouts, body composition, blood oxygen: it is all there, recorded continuously on hundreds of millions of devices. The challenge is getting that data into your application. Most health data providers expose a cloud API. Your backend calls an endpoint, receives a JSON response, and you are done. Apple Health does not work that way. ## Why Apple Health integration requires a mobile SDK HealthKit data lives on the device and is not accessible from the cloud. There is no Apple-provided REST API you can call from your backend. Any integration with Apple Health data requires code running on the user's iPhone that reads from HealthKit and then pushes data to your systems. This is not a limitation of any particular library or approach. It is how HealthKit is designed. As the Open Wearables documentation states directly: "Apple Health requires the Open Wearables mobile SDK. Cloud sync is not available for Apple Health." ## Two integration paths Open Wearables gives you two ways to complete your Apple Health integration and get data into your backend. **SDK-based real-time sync** is the primary path for live applications. The mobile SDK runs on the user's device, requests HealthKit permissions, and continuously syncs new data to your backend. **Apple Health XML Import** is the secondary path for historical data or migration scenarios. Apple lets users export their entire Health history as an XML file (Settings > Health > Export All Health Data). Records with the same `external_id` are not created twice. ## Running the backend ``` git clone https://github.com/the-momentum/open-wearables.git docker compose up -d ``` The API is available at `http://localhost:8000`. All requests authenticate using the `X-Open-Wearables-API-Key` header. You can get an access token via `POST /api/v1/auth/login`. ## The token flow 1. Your mobile app authenticates the user against your own backend. 2. Your backend calls `POST /api/v1/users/{user_id}/token` with your app credentials. 3. Your backend returns the resulting `access_token` and `refresh_token` to the mobile app. 4. The mobile app passes these tokens to the SDK. The SDK stores tokens in Keychain on iOS and handles automatic refresh when they expire. App credentials stay server-side only. ## Flutter integration ``` await OpenWearablesHealthSdk.configure( host: 'https://api.openwearables.io', ); final user = await OpenWearablesHealthSdk.signIn( userId: credentials['userId'], accessToken: credentials['accessToken'], refreshToken: credentials['refreshToken'], ); await OpenWearablesHealthSdk.startBackgroundSync(syncDaysBack: 90); ``` ## iOS (Swift) integration ``` sdk.configure(host: "https://api.openwearables.io") sdk.signIn( userId: credentials.userId, accessToken: credentials.accessToken, refreshToken: credentials.refreshToken ) sdk.startBackgroundSync(syncDaysBack: 90) ``` The SDK uses BGTaskScheduler for background execution and HealthKit observer queries to detect new data. Sync state persists across app restarts. Synced data is sent to `POST {host}/api/v1/sdk/users/{userId}/sync`. ## Available data types The SDK exposes via the `HealthDataType` enum: steps, heart rate, resting heart rate, sleep, workout, active energy, body mass. ## XML import for historical data For files under 10 MB: ``` POST /api/v1/users/{user_id}/import/apple/xml/direct ``` For larger files: ``` POST /api/v1/users/{user_id}/import/apple/xml/s3 ``` The S3 endpoint accepts: `filename` (max 200 chars), `expiration_seconds` (60-3600), `max_file_size` (default 50 MB). Processing is asynchronous: "Import processing is asynchronous. Don't expect immediate data availability." The XML importer supports workout metadata (activity types, duration, distance, calories, elevation), heart rate, steps, blood oxygen, and 100+ other metrics. ## See Related Articles - [Building a health app with Whoop API data](https://openwearables.io/blog/building-a-health-app-with-whoop-api-data) - [How to access Google Health Connect data in your backend](https://openwearables.io/blog/how-to-access-google-health-connect-data-in-your-backend) - [How to use Oura ring data in your app](https://openwearables.io/blog/how-to-use-oura-ring-data-in-your-app) - [Wearable API integration: comparing SaaS, custom build, and open source](https://openwearables.io/blog/wearable-api-integration-saas-custom-build-open-source) - [Getting Apple Health data into your backend](https://openwearables.io/blog/getting-apple-health-data-into-your-backend) ## FAQ **Does Apple Health have a REST API for server-side access?** No. Apple Health data is stored on the user's device, not in Apple's cloud infrastructure. There is no server-to-server API. The only supported way to access HealthKit data programmatically is through a mobile SDK running on the device with the user's permission. **Which mobile platforms does the Open Wearables Apple Health SDK support?** iOS (Swift), Flutter (Dart), and React Native (TypeScript). All three connect to the same backend and produce the same normalized data format. **What is the difference between the Mobile SDK path and the XML Import path?** The Mobile SDK is for continuous background sync. The XML Import is for historical exports. For most production applications, you will use both: XML Import for onboarding historical data and the SDK for ongoing sync. **How does Open Wearables handle large Apple Health XML exports?** Files below 10 MB can be uploaded directly. For larger files, request a presigned S3 URL and upload to S3. Processing happens asynchronously on the backend. **Can the same Apple Health data be imported twice?** No. Open Wearables uses `external_id` deduplication. Records with the same `external_id` will not be duplicated. **What does it cost?** MIT licensed, self-hosted, no per-user fee. ## Keep reading Apple Health · Jun 5, 2026 · 4 min read ### How to integrate Apple Health API into your backend There is no Apple Health API in the traditional sense. Learn how Open Wearables SDK-based approach gets HealthKit data into your backend with token-based auth and XML import. Apple Health · May 6, 2026 · 6 min read ### Getting Apple Health data into your backend There is no server-side Apple Health API. Getting data to your backend means building an iOS pipeline: permissions, observer queries, background delivery and reliable upload. Apple Health · May 4, 2026 · 7 min read ### Apple HealthKit API: what data you can access and how HealthKit is an on-device framework, not a remote API. There is no server-side Apple Health endpoint. Here's what's available, how permissions work, and what building an integration really requires. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/how-to-integrate-polar-data-into-your-health-app # How to integrate Polar data into your health app [All posts](https://openwearables.io/blog) [Polar](https://openwearables.io/blog/category/polar) Open Wearables Team · May 30, 2026 · 5 min read ## Key Takeaways - Polar uses the AccessLink API, which requires OAuth 2.0 setup, token management, and a polling model. Building this yourself means handling token refresh, transaction lifecycle, and per-user state storage before you get a single data point. - Open Wearables abstracts all of that. You connect a user once via a single OAuth endpoint, and subsequent syncs are one POST call. - The sync endpoint accepts optional parameters (samples, zones, route) so you pull only the data your app actually needs. - After sync, you read Polar data through the same generic endpoints (/events/workouts, /events/sleep, /timeseries) as every other provider. No Polar-specific parsing code in your app. - Open Wearables normalizes all values to canonical units: bpm for heart rate, meters for distance, Celsius for temperature, UTC for timestamps. - Polar coverage includes workouts, sleep with stages, and HRV. Continuous 24/7 data is not available through AccessLink. - The full local stack runs in under five minutes with git clone and docker compose up -d. ## The Problem: What Direct Polar API Integration Actually Costs You The Polar API (AccessLink) is well-documented and reasonably capable. If you sit down to integrate it directly, here is what you are actually building. OAuth 2.0 flow. You register an application, implement the authorization redirect, handle the callback, exchange the code for access and refresh tokens, and store per-user credentials securely. Standard OAuth, but boilerplate you have to write and maintain. Token lifecycle. AccessLink tokens expire. You need a refresh mechanism, error handling for when refresh fails, and a way to prompt re-authorization. If your token store goes stale, all syncs silently fail. Polling and transaction management. AccessLink uses a pull model with transaction semantics. To retrieve new data, you create a transaction, list available items, fetch each item, and then commit the transaction. If you commit before fetching everything, you lose that batch. You need to handle partial failures, retries, and the case where there is no new data. Data normalization. AccessLink returns heart rate in bpm and distance in meters in most endpoints, but timestamps are in ISO 8601 with timezone offsets that vary by device locale. Sleep stage data comes in a different shape than workout data. HRV metrics have their own structure. None of this maps directly to a common schema without work. Multiply this by every other provider you plan to support and the integration surface becomes significant. ## What Open Wearables Does Under the Hood Open Wearables wraps AccessLink entirely. When you call its Polar endpoints, here is what happens inside: - OAuth credential storage and refresh are handled per user. Your app never touches Polar tokens directly. - Polling is managed by the sync call. Open Wearables creates the AccessLink transaction, iterates items, commits on success, and retries on transient errors. - All data is normalized before it reaches your app. Heart rate in bpm, distance in meters, temperature in Celsius, all timestamps in UTC. - Exercise type codes from AccessLink are mapped to a common activity type vocabulary. The result is that your application code has no Polar-specific logic. You call the same endpoints you would call for any other provider. ## Setup and OAuth Flow ``` git clone https://github.com/the-momentum/open-wearables.git cd open-wearables docker compose up -d ``` The API is available at `http://localhost:8000`. All requests use the `X-Open-Wearables-API-Key` header. Authorizing a user: ``` GET /api/v1/oauth/polar/authorize?user_id={user_id}&redirect_uri={your_callback_url} ``` Open Wearables handles the AccessLink OAuth exchange and stores the credentials. Your callback receives confirmation that the user is connected. From this point, you do not manage Polar credentials for this user. ## Syncing Data Once a user is authorized, trigger a sync: ``` POST /api/v1/providers/polar/users/{user_id}/sync ``` This fetches new workouts and sleep data since the last sync. Optional parameters give you control over payload size: - samples (default false): detailed heart rate samples per workout - zones (default false): heart rate zone breakdown - route (default false): GPS route data Full sync with all optional data: ``` POST /api/v1/providers/polar/users/{user_id}/sync?samples=true&zones=true&route=true ``` Use the baseline when you only need summary metrics or aggregate sleep. Pulling fewer fields means faster syncs and smaller stored payloads. ## Reading Data After sync, data is available through the standard provider-agnostic endpoints: ``` GET /api/v1/users/{user_id}/events/workouts GET /api/v1/users/{user_id}/events/sleep GET /api/v1/users/{user_id}/timeseries ``` The `provider` field in each response tells you the source, but your query logic does not need to branch on it. If you are building a dashboard that shows runs from multiple devices, you query `/events/workouts` once. Polar runs, Garmin runs, and Suunto runs all come back in the same normalized format. Sleep data includes fields for sleep stages (light, deep, REM) where the device provides them. Polar provides sleep stage data, so those fields will be populated. HRV is available through the timeseries endpoint. ## Limitations to Know Before You Build No continuous 24/7 data. AccessLink does not expose continuous heart rate streams or step counts in real time. If your app requires continuous HR monitoring or live activity tracking, Polar through this integration is not the right fit. Polling latency. Because AccessLink is pull-based, data freshness depends on your sync frequency. There is no instant notification when a user completes a workout. Webhook support is upcoming. Provider Webhook Subscriptions for Polar are on the Open Wearables roadmap, which will enable event-driven syncs when it ships. ## Quickstart ``` # 1. Clone and start the stack git clone https://github.com/the-momentum/open-wearables.git cd open-wearables docker compose up -d # 2. Authorize a user curl "http://localhost:8000/api/v1/oauth/polar/authorize?user_id=user_001&redirect_uri=http://localhost:3000/callback" \ -H "X-Open-Wearables-API-Key: your_key" # 3. Trigger sync curl -X POST http://localhost:8000/api/v1/providers/polar/users/user_001/sync \ -H "X-Open-Wearables-API-Key: your_key" # 4. Read workouts curl http://localhost:8000/api/v1/users/user_001/events/workouts \ -H "X-Open-Wearables-API-Key: your_key" # 5. Sync with full detail curl -X POST "http://localhost:8000/api/v1/providers/polar/users/user_001/sync?samples=true&zones=true&route=true" \ -H "X-Open-Wearables-API-Key: your_key" ``` ## See Related Articles - [How to integrate Suunto data into your health app](https://openwearables.io/blog/how-to-integrate-suunto-data-into-your-health-app) - [How to sync wearable data from multiple devices](https://openwearables.io/blog/how-to-sync-wearable-data-from-multiple-devices) - [Garmin Connect API: developer guide](https://openwearables.io/blog/garmin-connect-api-developer-guide-activities-health-metrics) - [Building a health app with Whoop API data](https://openwearables.io/blog/building-a-health-app-with-whoop-api-data) - [Wearable API integration: comparing SaaS, custom build, and open source](https://openwearables.io/blog/wearable-api-integration-saas-custom-build-open-source) ## FAQ **Does Open Wearables support real-time Polar data?** No. AccessLink is a polling API. There is no real-time or streaming data available through this integration. Provider Webhook Subscriptions for Polar are on the Open Wearables roadmap, which will reduce latency once available. **Can I pull Polar data alongside data from other providers in the same query?** Yes. After syncing, all data is stored in Open Wearables' normalized schema. Queries to /events/workouts, /events/sleep, and /timeseries return results across all connected providers for a given user. **What happens if a Polar user revokes access?** When AccessLink returns an authorization error during a sync, Open Wearables surfaces that as an error response. Your app should handle this by prompting the user to re-authorize via the OAuth endpoint. **Is HRV data available from Polar?** Yes. HRV data is available through the /timeseries endpoint after sync. Polar provides HRV from overnight recordings on supported devices. The data follows the same canonical schema as HRV from other providers. **How do the optional sync parameters affect stored data?** The samples, zones, and route parameters control what is fetched and stored during that sync call. If you sync without samples=true, heart rate sample arrays are not retrieved or stored for those workouts. Pull the detail you need at sync time. ## Keep reading Polar · May 5, 2026 · 8 min read ### Polar API: training, HRV and Nightly Recharge data Polar AccessLink API provides training sessions for 100+ sport types, HRV4T nightly HRV tracking, Nightly Recharge, sleep staging and VO2 max. Here's what building with it requires. Polar · May 3, 2026 · 7 min read ### How to access Polar watch data in your health app Polar's cardio versus muscle load split and ANS Charge from Nightly Recharge enable coaching features that most wearable APIs cannot support. Here's how to use them effectively. Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/how-to-integrate-strava-without-building-oauth-from-scratch # How to integrate Strava without building OAuth from scratch [All posts](https://openwearables.io/blog) [Strava](https://openwearables.io/blog/category/strava) Open Wearables Team · May 4, 2026 · 5 min read ## Key takeaways - Building a production Strava integration means writing OAuth 2.0, token refresh, webhook handling, rate limit logic and a data normalization layer before shipping any product feature - Each of these pieces is non-trivial, and together they represent weeks of engineering work that has nothing to do with your actual product - The challenge multiplies when you add more providers: every wearable API has a different OAuth flavor, different token lifecycle and different data schema - Open Wearables is an open-source, self-hosted platform that handles this entire infrastructure layer for Strava and eight other providers simultaneously - MIT licensed, $0 per user, deployable in under an hour via Docker Compose ## Introduction Adding Strava to a health or fitness app sounds like a two-day job. In practice, it often turns into two weeks once you account for everything production requires. The OAuth flow itself is straightforward enough. Redirect the user, handle the callback, exchange the code, store the tokens. But that is only the beginning. Strava access tokens expire after six hours, which means every API call needs to check token expiry first and refresh proactively if needed. Rate limits are enforced at 100 requests per 15-minute window and 1000 per day per athlete, which means you need per-user tracking in your backend infrastructure, not a global counter. Webhooks require a publicly reachable validated HTTPS endpoint before Strava will send you anything. And when you add the second provider, you repeat all of this from scratch with different conventions. This post covers what it actually takes to build a Strava integration that works reliably in production, and what a simpler path looks like for teams who need multiple providers without the infrastructure overhead. ## The OAuth problem is bigger than you think OAuth 2.0 with Strava follows the standard authorization code flow. But the operational burden starts immediately after the initial exchange. Strava issues access tokens with a six-hour expiry, which is significantly shorter than most providers. This means you cannot fetch a token at connection time and reuse it. You need a refresh mechanism woven into your data layer that checks expiry before every API call. In a small codebase, this might be a single helper function. In a production system with multiple services, background jobs and async workers all potentially making Strava API calls, token management becomes a cross-cutting concern. Every component that touches the Strava API needs access to up-to-date tokens for each user. The tokens need to be stored persistently, refreshed atomically so two concurrent processes do not both try to refresh the same token simultaneously, and cleaned up properly when a user deauthorizes your app. Deauthorization itself is an edge case that is easy to miss in development and critical in production. When a user removes your app from their Strava connected applications, their refresh token is invalidated. Your next API call returns a 401 with a specific error indicating token revocation, not a generic auth failure. Your code needs to detect this, mark the connection as disconnected in your database, and surface a re-authentication prompt to the user rather than silently failing. ## Rate limits are a system design problem The 100 requests per 15 minutes and 1000 per day limits sound generous in development. In production, they shape how you architect your entire data pipeline. Consider a user who has been on Strava for three years and runs four days a week. That is roughly 600 activities. If you want to backfill their history when they first connect, and you fetch activity summaries plus GPS and heart rate streams for each one, you are looking at well over 1000 API calls for a single user. That exceeds the daily limit before you have even touched a second user. You need a backfill strategy that spreads historical sync over multiple days, prioritizes recent data, and handles interruption and resumption gracefully. For ongoing sync, the answer is webhooks rather than polling. Polling on a fixed schedule burns through rate limits regardless of whether there is new data. Webhooks notify you when something actually happens. But webhooks introduce their own complexity: a publicly reachable HTTPS endpoint that responds to Strava's validation challenge within seconds, asynchronous processing so the webhook handler returns 200 immediately while actual data fetching happens in a queue, idempotent processing so duplicate deliveries do not create duplicate records, and dead-letter handling for events that fail processing. None of this is rocket science, but it is real engineering work. For a team focused on building a coaching or wellness product, it is work that delays the features users actually care about. ## The multi-provider problem Strava is rarely the only provider a health app needs. Users who run on Strava also sleep with an Oura Ring, train with a Garmin watch, and track recovery with Whoop. A compelling product needs data from wherever the user actually generates it. For a full breakdown of how the Strava API changed in 2026, including the new developer tiers, retired endpoints, and upcoming breaking changes, see the [Strava API 2026 developer guide](https://openwearables.io/blog/strava-api-developer-guide-activities-heart-rate-gps-data). Each provider has its own OAuth flavor, token lifecycle, rate limits and data schema. Garmin uses OAuth 1.0a and push-based delivery, not OAuth 2.0 and polling. Apple Health requires an iOS SDK rather than a server-side API. Whoop has rotating refresh tokens that must be stored after every exchange. The implementation patterns are different enough that there is very little code reuse between providers. The result is that adding each new provider takes a substantial engineering investment, and the infrastructure complexity grows non-linearly. By the time you have three or four providers integrated, you have a significant maintenance surface: token refresh for multiple providers, webhook handlers for multiple event formats, normalization logic mapping each provider's schema to yours, and monitoring to detect when any of these stops working. ## Open Wearables Open Wearables is an open-source platform that connects your application to wearable and health data providers through a single API. One normalized data model, multi-provider support in a single self-hosted deployment, no per-user fees, MIT licensed, and health intelligence built in: normalized recovery, sleep, activity and biometric data ready for your product layer. We offer custom deployment and integration support through Momentum. If your team needs help getting to production faster, we can set up and configure Open Wearables as part of a managed engagement. [Let's talk](https://www.themomentum.ai/lets-talk). [Book a demo](https://openwearables.io/book) to see how Open Wearables fits your use case. ## Strava integration View the full [Strava integration documentation](https://openwearables.io/integrations/strava) on Open Wearables. ## See related articles [Strava API Developer Guide: Activities, Heart Rate and GPS Data](https://openwearables.io/blog/strava-api-developer-guide-activities-heart-rate-gps-data) [Polar API: Training, HRV and Nightly Recharge Data](https://openwearables.io/blog/polar-api-training-hrv-nightly-recharge-data) [Garmin Connect API: Developer Guide for Activities and Health Metrics](https://openwearables.io/blog/garmin-connect-api-developer-guide-activities-health-metrics) ## Keep reading Strava · May 6, 2026 · 11 min read ### Strava API 2026: developer guide to activities, heart rate and GPS data A practical guide to connecting Strava's API in production: OAuth token refresh, rate limits, webhooks, and how to normalize activity data across multiple providers. Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. Guides · Oct 26, 2026 · 9 min read ### Moving from a hosted wearable API to Open Wearables: a migration playbook Moving from a hosted wearable API to Open Wearables is usually a re-integration rather than a data migration. This playbook walks through the decisions, the steps in order, how your users reconnect and what to tell your security team. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/how-to-integrate-suunto-data-into-your-health-app # How to integrate Suunto data into your health app [All posts](https://openwearables.io/blog) [Suunto](https://openwearables.io/blog/category/suunto) Open Wearables Team · Jun 2, 2026 · 6 min read ## Key Takeaways - Integrating Suunto directly requires building OAuth 2.0 flows, managing token refresh, polling Suunto's cloud API, and normalizing data to your own schema. Open Wearables handles all of that. - Suunto in Open Wearables provides both workout data and 24/7 continuous monitoring: sleep with stages, recovery scores, and activity metrics. - The sync endpoint accepts data_type values of workouts, 247, or all, so you pull exactly what you need. - Historical sync is a single POST call. Use it on user onboarding to backfill data before going to incremental polling. - All data comes out in canonical units: bpm, meters, Celsius, UTC. The same read endpoints work across all connected providers. - Open Wearables is MIT-licensed, self-hostable via Docker, and costs $0 per user. - Suunto is one of four providers with full 24/7 continuous data support in Open Wearables, alongside Garmin, with Oura and Ultrahuman coming. ## The Problem: What You Build When You Integrate the Suunto API Directly If you want to integrate the Suunto API in your app, here is what you are signing up for. OAuth 2.0 implementation. Suunto uses OAuth 2.0. You register an application, build an authorization redirect, handle the callback, exchange the code for access and refresh tokens, store both securely, and write logic to detect expiry and refresh before every API call. If you are building for multiple users, this logic runs at scale. Polling. Suunto's API is cloud-based with REST polling. There is no webhook push. You write a scheduler that polls on some interval, tracks what you have already fetched via a since timestamp, and handles pagination when results exceed a page size. Data normalization. Suunto returns data in its own schema and units. Your app likely needs a consistent internal representation. You write mapping code that converts Suunto's fields to your schema, handles missing or nullable fields, and converts units. Then you do the same thing again when you add the next provider. None of this is unsolvable. It is just a lot of undifferentiated work before you get to build anything specific to your product. ## What Open Wearables Does for You Open Wearables is an open-source middleware layer that handles the full OAuth 2.0 flow including token storage and refresh, polls Suunto's cloud API, normalizes the response into a canonical schema, and exposes the data through a single REST API that you own and host. Canonical units are consistent across all providers: heart rate in bpm, distance in meters, temperature in Celsius, timestamps in UTC. The read endpoints are the same regardless of whether a user has Suunto, Garmin, or any other supported device. You write your data layer once. ## The Suunto Differentiator: 24/7 Continuous Data Suunto is one of four providers in Open Wearables with full 24/7 continuous data support. In practice, this means you get more than workout records. When a user connects their Suunto watch, you have access to workouts with GPS traces, heart rate, speed, and elevation; sleep including duration and stages; recovery scores and readiness data; and continuous activity data including steps, calories, and intraday metrics. For health apps, the difference between workout-only and 24/7 data is significant. If you are building a recovery tracker, a training load tool, or anything that reasons about a user's day rather than just their runs, you need the continuous stream. Suunto gives you that. The `data_type` parameter on the sync endpoint controls which subset you pull. ## Setup and OAuth Flow ``` git clone https://github.com/the-momentum/open-wearables.git cd open-wearables docker compose up -d ``` The API is available at `http://localhost:8000`. Authenticate all requests with the `X-Open-Wearables-API-Key` header. To connect a Suunto account, redirect the user to: ``` GET /api/v1/oauth/suunto/authorize?user_id={user_id}&redirect_uri={your_callback_url} ``` Open Wearables handles the OAuth handshake, stores the tokens, and manages refresh from that point forward. You do not touch the tokens directly. ## Syncing Data ### The Sync Endpoint ``` POST /api/v1/providers/suunto/users/{user_id}/sync ``` Parameters: - since (Unix timestamp, default 0): fetch data modified after this time. 0 fetches all available data. - limit (default 50, max 100): records per page - offset (default 0): pagination offset - filter_by_modification_time (default true): filter by modification time rather than creation time - data_type: workouts, 247, or all ### Choosing data_type **workouts** pulls recorded exercise sessions only. Use this if your app is activity-focused and does not use sleep or continuous health data. **247** pulls the continuous monitoring stream: sleep, recovery, intraday activity. Use this if you are building recovery dashboards, sleep tracking, or anything that works with the user's baseline state. **all** pulls both. Use this for general health apps or when you are not sure what downstream features will need. A typical incremental polling call: ``` curl -X POST "http://localhost:8000/api/v1/providers/suunto/users/user_123/sync" \ -H "X-Open-Wearables-API-Key: your_api_key" \ -H "Content-Type: application/json" \ -d '{"since": 1748736000, "limit": 100, "data_type": "all"}' ``` Set `since` to the timestamp of your last successful sync. Store that value and increment it after each successful run. ## Historical Sync: Onboarding a New User When a user first connects, backfill their history with the historical sync endpoint: ``` POST /api/v1/providers/suunto/users/{user_id}/sync/historical ``` Run this once during onboarding, right after OAuth completes. After that, switch to incremental polling with a `since` timestamp. Monitor sync status at: ``` GET /api/v1/sync/events ``` Useful for confirming that a historical sync completed before you start displaying data to the user. ## Reading the Data Once synced, data is available through the standard read endpoints: ``` GET /api/v1/users/{user_id}/events/workouts GET /api/v1/users/{user_id}/events/sleep GET /api/v1/users/{user_id}/timeseries ``` These return data in the canonical schema regardless of the source provider. If a user later connects a Garmin device alongside their Suunto, the same endpoint returns data from both, merged and normalized. Your read logic does not change. ## Pagination The sync endpoint returns up to 100 records per call. For users with long history, page through results using `offset`: ``` offset = 0 limit = 100 while True: response = sync(user_id, since=last_sync_ts, limit=limit, offset=offset) records = response["data"] if not records: break store(records) offset += limit ``` For regular polling intervals, a single call with `limit=100` is usually sufficient. Pagination is mainly relevant for historical sync and initial onboarding. ## Quickstart ``` # 1. Clone and start git clone https://github.com/the-momentum/open-wearables.git cd open-wearables docker compose up -d # 2. Connect a Suunto user (redirect them to this URL) GET /api/v1/oauth/suunto/authorize?user_id=user_123&redirect_uri=https://yourapp.com/callback # 3. Historical backfill on first connect curl -X POST http://localhost:8000/api/v1/providers/suunto/users/user_123/sync/historical \ -H "X-Open-Wearables-API-Key: your_api_key" # 4. Incremental sync (run on a schedule) curl -X POST "http://localhost:8000/api/v1/providers/suunto/users/user_123/sync" \ -H "X-Open-Wearables-API-Key: your_api_key" \ -H "Content-Type: application/json" \ -d '{"since": 1748736000, "limit": 100, "data_type": "all"}' # 5. Read normalized data curl http://localhost:8000/api/v1/users/user_123/events/workouts -H "X-Open-Wearables-API-Key: your_api_key" curl http://localhost:8000/api/v1/users/user_123/events/sleep -H "X-Open-Wearables-API-Key: your_api_key" curl http://localhost:8000/api/v1/users/user_123/timeseries -H "X-Open-Wearables-API-Key: your_api_key" ``` ## See Related Articles - [How to integrate Polar data into your health app](https://openwearables.io/blog/how-to-integrate-polar-data-into-your-health-app) - [How to sync wearable data from multiple devices](https://openwearables.io/blog/how-to-sync-wearable-data-from-multiple-devices) - [Garmin Connect API: developer guide](https://openwearables.io/blog/garmin-connect-api-developer-guide-activities-health-metrics) - [How to integrate Strava without building OAuth from scratch](https://openwearables.io/blog/how-to-integrate-strava-without-building-oauth-from-scratch) - [Wearable API integration: comparing SaaS, custom build, and open source](https://openwearables.io/blog/wearable-api-integration-saas-custom-build-open-source) ## FAQ **Does Open Wearables support Suunto sleep stages, not just total sleep duration?** Yes. Suunto's 24/7 monitoring data includes sleep with stages, and Open Wearables surfaces that through the sleep events endpoint, normalized to the canonical schema. **How often should I poll the sync endpoint?** For most health apps, once per hour is sufficient for near-real-time data. For daily digests or recovery summaries, polling once per day is enough. Suunto's API is cloud-based, so data from the watch syncs to Suunto's servers periodically anyway. **What happens if a user's Suunto token expires?** Open Wearables manages token refresh automatically. As long as the user remains connected, OAuth tokens are refreshed behind the scenes and you do not need to handle this in your application code. **What is the difference between filter_by_modification_time=true and false?** When set to true (the default), the since parameter filters records by when they were last modified. This catches updated records, such as a workout that was corrected or a sleep entry that was reprocessed. When set to false, it filters by creation time only. The default is recommended for most use cases. **Does Suunto data normalize to the same schema as Garmin or Polar?** Yes. Workout data from Suunto and from Garmin comes out of the same endpoints in the same format with the same units. If a user connects both devices, you get their data through one API without any provider-specific handling on your end. ## Keep reading Suunto · May 4, 2026 · 6 min read ### How to integrate Suunto data into your training app Suunto's altitude metrics and Training Effect scores enable outdoor sport features no other major wearable API covers with comparable depth. Here's how to use them in a product. Suunto · May 2, 2026 · 7 min read ### Suunto API: accessing watch data for developers The Suunto API provides workout data for 80+ sport types with GPS, heart rate, altitude metrics, Training Effect scores and VO2 max. Here's what building with it requires. Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/how-to-integrate-suunto-data-into-your-training-app # How to integrate Suunto data into your training app [All posts](https://openwearables.io/blog) [Suunto](https://openwearables.io/blog/category/suunto) Open Wearables Team · May 4, 2026 · 6 min read ## Introduction Suunto's data model is narrower than Polar's or Garmin's but deeper in the specific dimension that matters most to outdoor athletes: altitude. If you are building a training app for trail runners, mountain bikers, alpinists, hikers or any athlete whose training involves significant elevation change, Suunto integration provides data capabilities that no other major wearable API matches. This guide covers the practical integration work: OAuth setup, handling the subscription or polling model for new workout delivery, parsing GPS and altitude data, building altitude-aware training load features, working with Training Effect scores, handling the sport type taxonomy, and structuring a multi-provider backend where Suunto users and Garmin or Polar users produce normalized outputs. ## Integration setup Register your application at developer.suunto.com. Specify your application name, description and redirect URI. You will receive a client_id and client_secret. These are environment-agnostic in the Suunto developer portal (unlike Samsung which issues separate credentials per environment), so maintain your own environment separation by using different redirect URIs and keeping credentials in environment-specific configuration files. Implement the OAuth 2.0 authorization code flow. Direct the user to Suunto's authorization endpoint with your client_id, redirect_uri, response_type of code, and the scope parameter. The primary scope for workout data is workout. After authorization, exchange the code for tokens at Suunto's token endpoint. Persist the user's access token and refresh token in your database. Implement token refresh logic that detects access token expiry (check the expiry timestamp before each request rather than waiting for a 401) and exchanges the refresh token for a new access token. Log all token operations for debugging. Handle permanent authorization failures (where refresh also fails) by marking the user's Suunto connection as inactive and surfacing a reconnect prompt. ## Fetching workout data Suunto workout data is fetched through two mechanisms: webhook notifications and polling. For production applications with reliable webhook infrastructure, register your callback URL so Suunto sends a notification when a user syncs a new workout. The notification contains the workout ID. Fetch the full workout details in a subsequent request to the workouts endpoint using that ID. For polling-based implementations, request the workouts list for a user filtered by a start timestamp. Store the timestamp of the most recently processed workout per user and use it as the cursor for subsequent polling requests. Run polling jobs hourly per user on a schedule. This approach is simpler to operate than webhook-based delivery and sufficient for most training app use cases where near-real-time data delivery is not required. When fetching a workout, request the full detail including the samples (the time series data for GPS, heart rate, altitude, cadence and speed). The workout summary endpoint provides aggregate metrics. The samples endpoint provides the per-point time series needed for GPS tracks and altitude profiles. For storage efficiency, decide upfront whether you need to store raw sample data or only the computed summaries. Raw sample storage enables reprocessing and visualization features but requires significantly more storage. ## Building altitude-aware training load A standard training load model based only on heart rate and duration underestimates the effort of uphill and trail workouts. A 90-minute trail run with 800 meters of ascent has a physiological cost that is significantly higher than a 90-minute flat road run at a similar average heart rate, because the muscular demand of climbing is not fully captured in heart rate. Two approaches for altitude-aware load modeling: the Training Effect approach and the grade-adjusted approach. Training Effect (Aerobic TE and Anaerobic TE from the Suunto API) incorporates the heart rate response to the entire session including the climbing effort, so using Training Effect as your load metric implicitly captures altitude stress through heart rate. This approach works but is opaque to users who want to understand why a session felt hard. The grade-adjusted approach uses the GPS track and altitude profile to compute grade-adjusted pace (GAP) for each GPS sample. GAP normalizes pace to the equivalent flat-ground pace using a grade factor. Common approximations add roughly 10 seconds per kilometer per percent of grade for uphill segments. Compute the total GAP-adjusted equivalent duration for the session as the training load input. This approach makes the altitude adjustment transparent and auditable. Track weekly cumulative ascent as a separate metric from distance and duration. A trail runner whose weekly mileage stays constant but whose weekly vertical gain doubles has meaningfully increased their training load even if heart rate data looks similar. Surface weekly vertical as a trend metric in training plan features. ## Working with training effect scores Suunto's Training Effect scores use the Firstbeat Analytics methodology, the same system used by Polar and Garmin. Aerobic Training Effect (1.0-5.0) indicates the session's expected aerobic adaptation stimulus. Anaerobic Training Effect (1.0-5.0) indicates anaerobic adaptation stimulus. Both are available for most run and cycle sport types on supported devices. The five-level scale maps to: 1 (minor effect), 2 (maintaining fitness), 3 (improving fitness), 4 (highly improving fitness), 5 (overreaching). For coaching features, the useful application is tracking the distribution of Training Effect levels across a training week or month. A periodized training plan for endurance athletes should produce a mix of level 2-3 aerobic sessions (the base work) with occasional level 3-4 sessions and rare level 4-5 sessions. If Training Effect is not available for a session (because the sport type does not support it, the device does not have the feature, or the user trained without a heart rate source), handle the null gracefully. Fall back to a simpler load estimate based on duration and average heart rate relative to the user's maximum heart rate. ## Sport type normalization Suunto's sport type identifiers are string-based (for example trail_running, cycling, swimming_pool, mountain_biking). Map these to your application's internal activity taxonomy. Create a mapping table that associates each Suunto sport type string with your canonical activity category. Handle unmapped sport types by assigning them to a generic activity category rather than dropping the workout. For multi-provider normalization, create a cross-provider sport type map that aligns Suunto sport types with Garmin, Polar, Samsung and other providers' sport type codes. This is tedious to build but critical for features that analyze training distribution across sport types: a user who trains with both a Suunto watch and a Garmin watch (using different devices for different activities) should have their cycling workouts aggregated regardless of which device recorded them. ## The recovery gap and multi-provider architecture Suunto's API does not provide sleep or recovery data. This is a significant gap for building holistic training apps. Trail runners need recovery guidance as much as any other athlete, but Suunto data alone cannot support it. Design your multi-provider architecture to pair Suunto with a recovery-focused provider for users who need both training load tracking and recovery monitoring. A common pairing is Suunto for training data plus Oura or Whoop for recovery data. The user connects both providers. Training load from Suunto is evaluated against recovery status from the ring or band. For users who only have Suunto connected, surface training load trends without recovery context and recommend adding a recovery provider if they want training recommendations. ## Open Wearables Open Wearables is an open-source platform that connects your application to wearable and health data providers through a single API. One normalized data model, multi-provider support in a single self-hosted deployment, no per-user fees, MIT licensed, and health intelligence built in: normalized recovery, sleep, activity and biometric data ready for your product layer. We offer custom deployment and integration support through Momentum. If your team needs help getting to production faster, we can set up and configure Open Wearables as part of a managed engagement. [Let's talk](https://www.themomentum.ai/lets-talk). [Book a demo](https://openwearables.io/book) to see how Open Wearables fits your use case. ## Suunto integration View the full [Suunto integration documentation](https://openwearables.io/integrations/suunto) on Open Wearables. ## See related articles [Suunto API: Accessing Watch Data for Developers](https://openwearables.io/blog/suunto-api-accessing-watch-data-for-developers) [Polar API: Training, HRV and Nightly Recharge Data](https://openwearables.io/blog/polar-api-training-hrv-nightly-recharge-data) [Oura API: Accessing Ring Data, Sleep, HRV and Readiness](https://openwearables.io/blog/oura-api-accessing-ring-data-sleep-hrv-readiness) ## Keep reading Suunto · Jun 2, 2026 · 6 min read ### How to integrate Suunto data into your health app The Suunto API provides workouts and 24/7 continuous monitoring. Open Wearables handles OAuth, polling, and normalization so you query one endpoint instead of building provider logic. Suunto · May 2, 2026 · 7 min read ### Suunto API: accessing watch data for developers The Suunto API provides workout data for 80+ sport types with GPS, heart rate, altitude metrics, Training Effect scores and VO2 max. Here's what building with it requires. Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/how-to-integrate-whoop-api-data-into-your-health-app # How to integrate Whoop API data into your health app [All posts](https://openwearables.io/blog) [Whoop](https://openwearables.io/blog/category/whoop) Open Wearables Team · Jun 2, 2026 · 4 min read ## Key Takeaways - Integrating the Whoop API directly requires building OAuth 2.0 flows, managing token refresh, polling for new data, and normalizing response shapes. - Open Wearables handles all of that infrastructure so you make a single sync call and read normalized data from one consistent schema. - Whoop requires an active paid membership to grant API access. Free accounts are not supported. - The sync endpoint accepts a `data_type` parameter (`workouts`, `247`, or `all`) and defaults to the last 30 days when no date range is specified. - Whoop provides solid workout, sleep, recovery, and HRV data. It does not provide continuous 24/7 timeseries or step counts. - The entire stack is MIT-licensed, self-hosted, and costs $0 per user. - You can be reading normalized Whoop data in a local environment within minutes of running `docker compose up -d`. ## What You Have to Build When You Call the Whoop API Directly If you go straight to the Whoop API, the first thing you encounter is OAuth 2.0. That means building an authorization redirect, handling the callback, exchanging the code for tokens, storing those tokens, and implementing a refresh flow before the access token expires. None of that delivers any health data. It just gets you to the point where you can start asking for data. Then comes polling. Whoop does not push data to you. You set up a scheduled job that calls their endpoints at intervals, tracks sync state per user, handles rate limits, and deals with partial failures when a polling job times out. Then normalization. Whoop returns data in its own schema. If you ever add a second wearable provider, every field name, every unit, and every data structure differs. You now maintain a mapping layer that grows with every new device you support. ## What Open Wearables Does for the Whoop API Integration Open Wearables wraps the Whoop API so that the infrastructure described above is already built. **OAuth lifecycle.** OW exposes a single authorize endpoint. You redirect your user there, and OW handles the full OAuth 2.0 flow including token storage and refresh. **Polling and sync state.** When you trigger a sync, OW handles the requests to Whoop's REST endpoints, manages pagination, and tracks what has already been fetched per user. **Normalization.** OW writes all Whoop data into a canonical schema: heart rate in bpm, distances in meters, timestamps in UTC. ## Whoop Data Coverage: What You Get and What You Do Not **Available:** Workouts (145+ activity types), sleep with full stage data, recovery metrics, HRV. **Not available:** Continuous 24/7 heart rate timeseries, step counts, 24/7 timeseries data. If your core feature requires continuous biometric streams or step-based activity tracking, Whoop is not the right primary source. If your use case is workout analysis, sleep quality, or recovery-based recommendations, Whoop data is well-suited. ## Setup and OAuth **Prerequisites:** An active Whoop membership, a registered developer application at developer.whoop.com, Open Wearables running. When configuring OAuth redirect URIs, add: ``` http://localhost:8000/api/v1/oauth/whoop/callback ``` To connect a user's Whoop account: ``` GET /api/v1/oauth/whoop/authorize?user_id={id}&redirect_uri={url} ``` OW handles the full OAuth exchange. Once the user completes the flow, their tokens are stored and you can begin syncing. ## Syncing Whoop Data ``` POST /api/v1/providers/whoop/users/{user_id}/sync ``` The `data_type` parameter controls what gets fetched: `workouts`, `247`, or `all`. When no date range is specified, OW defaults to syncing the last 30 days of Whoop data. ## Reading Normalized Data ``` GET /api/v1/users/{user_id}/events/workouts GET /api/v1/users/{user_id}/events/sleep GET /api/v1/users/{user_id}/timeseries ``` All responses use canonical units and a consistent schema regardless of provider. ## Quickstart ``` git clone https://github.com/the-momentum/open-wearables.git cd open-wearables docker compose up -d ``` API at `http://localhost:8000`. Auth via `X-Open-Wearables-API-Key` header. MIT-licensed, $0 per user. ## See Related Articles - [Building a health app with Whoop API data](https://openwearables.io/blog/building-a-health-app-with-whoop-api-data) - [How to sync wearable data from multiple devices](https://openwearables.io/blog/how-to-sync-wearable-data-from-multiple-devices) - [How to normalize wearable data across providers](https://openwearables.io/blog/how-to-normalize-wearable-data-across-providers) - [How to integrate Polar data into your health app](https://openwearables.io/blog/how-to-integrate-polar-data-into-your-health-app) - [Wearable API integration: comparing SaaS, custom build, and open source](https://openwearables.io/blog/wearable-api-integration-saas-custom-build-open-source) ## FAQ **Does the Whoop API require a paid membership?** Yes. Whoop requires an active paid membership to grant API access. Free accounts cannot be used. **What Whoop data types can I access through Open Wearables?** Workout records (145+ activity types), sleep data, recovery metrics, and HRV. Continuous 24/7 heart rate timeseries and step counts are not available from the Whoop API. **How far back does a default Whoop sync go?** When no date range is specified, OW defaults to syncing the last 30 days of Whoop data. **How does OW handle Whoop token refresh?** OW manages the full OAuth 2.0 token lifecycle including refresh. Once a user has authorized access, you do not need to interact with Whoop's authorization servers again under normal circumstances. **Is there a cost per user for running Open Wearables?** No. OW is MIT-licensed and self-hosted. There is no per-user pricing. ## Keep reading Whoop · May 6, 2026 · 9 min read ### Whoop API: recovery, strain and sleep data for developers The Whoop API exposes Recovery Score, HRV, Strain and Sleep Performance through a cycle-based model. Here's how it works in practice and what building with it actually requires. Whoop · May 6, 2026 · 6 min read ### Building a health app with Whoop API data Getting data out of the Whoop API is one problem. Building something users find valuable is another. Here's how to use Recovery Score, HRV trends and Sleep Performance effectively in a product. Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/how-to-normalize-wearable-data-across-providers # How to normalize wearable data across providers [All posts](https://openwearables.io/blog) [Guides](https://openwearables.io/blog/category/guides) Open Wearables Team · May 24, 2026 · 6 min read ## Key Takeaways - Without a normalization layer, adding each new wearable provider means writing separate API clients, handling different authentication flows, mapping provider-specific field names, and converting units manually. - Open Wearables uses a unified data model built around five components: Events, Time Series, Descriptors, ID Mapping, and Series Type Definitions. - All data is automatically converted to canonical units: heart rate in bpm, distance in meters, temperature in Celsius, timestamps in UTC. - Provider sync differences (Garmin webhook-only vs. Polar REST polling vs. Apple Health mobile-SDK-only) are abstracted away. Your app always calls the same endpoints. - Three endpoints cover the main data types: /api/v1/users/{user_id}/timeseries, /api/v1/users/{user_id}/events/workouts, and /api/v1/users/{user_id}/events/sleep. - Open Wearables is self-hosted, MIT-licensed, and costs $0 per user. - You can be running locally in under five minutes with git clone and docker compose up -d. ## The Problem Without a Normalization Layer Imagine you are building a health dashboard that pulls workout and sleep data. You start with Garmin. You write a client, handle webhooks (because Garmin does not support REST polling), map their field names to your internal schema, convert distances from whatever unit Garmin returns to meters, and store it. Then a user wants to connect their Polar device. Polar uses REST polling via AccessLink. Different auth, different field names, different response shape. You write another client. Then Whoop. OAuth 2.0, defaults to the last 30 days, different sleep stage taxonomy. Another client. If you have looked for a Terra API alternative, this is exactly the problem you are trying to solve. A rough sketch of what this looks like without any abstraction layer: ``` # Garmin: webhook handler def handle_garmin_webhook(payload): activity = payload["activities"][0] return { "distance_m": activity["distanceInMeters"], "hr_bpm": activity["averageHeartRateInBeatsPerMinute"], "started_at": parse_garmin_timestamp(activity["startTimeLocal"]), } # Polar: polling def fetch_polar_workouts(user_token, since): resp = requests.get( "https://www.polaraccesslink.com/v3/exercises", headers={"Authorization": f"Bearer {user_token}"}, params={"after": since}, ) exercises = resp.json()["exercises"] return [ { "distance_m": e["distance"], "hr_bpm": e["heart_rate"]["average"], "started_at": e["start_time"], } for e in exercises ] # Whoop: polling, different schema def fetch_whoop_workouts(user_token): resp = requests.get( "https://api.prod.whoop.com/developer/v1/activity/workout", headers={"Authorization": f"Bearer {user_token}"}, ) workouts = resp.json()["records"] return [ { "distance_m": w["score"]["distance_meter"], "hr_bpm": w["score"]["average_heart_rate"], "started_at": w["start"], } for w in workouts ] ``` This is three providers. Each with its own client, its own field mapping, its own timestamp handling. Add Suunto. Add Apple Health (mobile SDK only, no cloud sync). The surface area grows fast and so does the maintenance burden. With Open Wearables, the sync logic for all of these is handled by the platform. It works as a Terra API alternative that normalizes data across providers, so you do not have to maintain separate clients for each one. ``` import requests def get_workouts(user_id: str, api_key: str): resp = requests.get( f"http://localhost:8000/api/v1/users/{user_id}/events/workouts", headers={"X-Open-Wearables-API-Key": api_key}, ) return resp.json() ``` Same call regardless of whether the data came from Garmin, Polar, Whoop, Suunto, or any other connected provider. ## What Open Wearables Does Under the Hood The normalization is built on five components. Here is what each one does in practice. **Events** store discrete sessions: workouts and sleep. Each event has a start and end timestamp, aggregate values (average heart rate, total distance, sleep duration), and metadata linking it to a user, device, and provider. When Garmin sends a webhook and Polar returns the same activity via polling, both end up as Event records with the same shape. **Time Series** stores high-frequency float values: continuous heart rate, SpO2, skin temperature. Each record has a timestamp, a value, a type identifier, and a device source. This handles continuous monitoring data from Garmin (24/7) or Suunto (24/7) while also accommodating partial coverage from Whoop or Apple Health. **Descriptors** hold static user biometric information: birth date, biological sex, and gender. These do not change with each sync. Stored once and referenced when needed. **ID Mapping** links internal references to specific users, devices, and providers. When the same user connects two devices from different providers, ID Mapping keeps those relationships clean without scattering provider-specific identifiers across your tables. **Series Type Definitions** provide metadata for entire time series: units, display names, expected ranges. Unit definitions live in one place and apply consistently instead of being scattered across your codebase. The stack is SQLAlchemy, Pydantic, and Alembic. If you are familiar with FastAPI-style Python applications, the codebase will feel familiar. ## Canonical Units: What OW Handles Automatically Unit normalization is one of the places where provider differences most often cause silent bugs. A distance stored in kilometers looks like a plausible number when you expected meters. A timestamp in local time looks correct until a user travels to a different timezone. Open Wearables enforces canonical units across all providers: heart rate in bpm, distance in meters, temperature in Celsius, timestamps in UTC. When a provider returns distance in a non-standard unit or a timestamp in local time, OW converts it before storage. Your application always receives data in the same units regardless of where it came from. This matters especially when aggregating across providers. If one user has Garmin data and another has Polar data and a third has Strava data, the numbers in your database are directly comparable without any additional conversion logic on your side. ## One Endpoint Per Data Type, Across All Providers ``` GET /api/v1/users/{user_id}/timeseries GET /api/v1/users/{user_id}/events/workouts GET /api/v1/users/{user_id}/events/sleep ``` All requests use the `X-Open-Wearables-API-Key` header. A practical example for sleep data: ``` import requests BASE_URL = "http://localhost:8000" API_KEY = "your-api-key" def get_sleep_sessions(user_id: str): response = requests.get( f"{BASE_URL}/api/v1/users/{user_id}/events/sleep", headers={"X-Open-Wearables-API-Key": API_KEY}, ) response.raise_for_status() return response.json() sessions = get_sleep_sessions("usr_abc123") for session in sessions: print(session["started_at"], session["duration_seconds"], session["provider"]) ``` The `provider` field tells you where the data came from. Everything else is normalized. ## Provider Coverage Not all providers expose the same data types. Current coverage: - Apple Health: Sleep yes, HRV yes, Continuous yes, Workouts broad. Mobile SDK only (no cloud sync). - Garmin: Sleep yes, HRV yes, Continuous 24/7, Workouts yes. Webhook-only delivery. - Polar: Sleep stages, HRV yes, Continuous no, Workouts yes. REST polling via AccessLink. - Suunto: Sleep yes, HRV yes, Continuous 24/7, Workouts yes. REST with since/limit/offset. - Whoop: Sleep yes, HRV yes, Continuous partial (significant limitations), Workouts 145+ types. - Strava: Sleep no, HRV no, Continuous no, Workouts 50+ types. - Oura: Sleep stages, HRV yes, coming soon. OW handles the different sync models in its provider integration layer. You do not write webhook handlers for Garmin or polling loops for Polar. You configure the provider connection and OW gets the data into the normalized store. ## Quickstart ``` git clone https://github.com/the-momentum/open-wearables.git cd open-wearables docker compose up -d ``` The API is available at `http://localhost:8000`. Authentication uses the `X-Open-Wearables-API-Key` header. No managed service, no per-user pricing, no data leaving your infrastructure. MIT license. ## See Related Articles - [How to sync wearable data from multiple devices](https://openwearables.io/blog/how-to-sync-wearable-data-from-multiple-devices) - [Wearable API integration: comparing SaaS, custom build, and open source](https://openwearables.io/blog/wearable-api-integration-saas-custom-build-open-source) - [Garmin Connect API: developer guide](https://openwearables.io/blog/garmin-connect-api-developer-guide-activities-health-metrics) - [Building a health app with Whoop API data](https://openwearables.io/blog/building-a-health-app-with-whoop-api-data) - [How to use Oura ring data in your app](https://openwearables.io/blog/how-to-use-oura-ring-data-in-your-app) - [What wearable app development actually looks like in 2026](https://openwearables.io/blog/what-wearable-app-development-actually-looks-like-in-2026) - [Garmin Connect API: What You Can Fetch and How to Do It Faster](https://openwearables.io/blog/garmin-connect-api-what-you-can-fetch) - [How to Give Your LLM Access to Wearable Data](https://openwearables.io/blog/how-to-give-your-llm-access-to-wearable-data) - [How to Handle OAuth, Webhooks, and Token Refresh Across Multiple Wearable Providers](https://openwearables.io/blog/how-to-handle-oauth-webhooks-token-refresh-wearable-providers) - [How to Structure Health Data for AI: What Your LLM Actually Needs](https://openwearables.io/blog/how-to-structure-health-data-for-ai-llm) - [Wearable Data Deduplication: How to Handle Users With Multiple Devices](https://openwearables.io/blog/wearable-data-deduplication-multiple-devices) ## FAQ **What happens if two providers return conflicting data for the same time window?** Each record includes a provider field, so data from different sources is always distinguishable. OW does not merge or deduplicate across providers automatically. If a user has both Garmin and Apple Health connected and both record the same workout, you will see two Event records with different provider values. How you handle that in your application is up to you. **Does Open Wearables support real-time data, or only batch sync?** It depends on the provider. Garmin delivers data via webhooks as soon as a sync completes, which is close to real-time. Polar and Suunto use REST polling, so latency depends on how frequently you poll. OW handles whatever the provider supports; there is no additional delay introduced by the normalization layer. **Is the data model extensible if I need to store provider-specific fields?** The five-component model covers the most common wearable data types. For fields outside it, the project is open source (MIT), so you can extend the schema using the same SQLAlchemy and Alembic patterns already in use. **How do I handle Apple Health if it requires a mobile SDK?** Apple Health data does not sync to any cloud API. To ingest it into Open Wearables, you need a mobile component that reads from HealthKit and pushes data to your OW instance. Once the data is in OW, it is normalized alongside data from all other providers. ## Keep reading Guides · Oct 26, 2026 · 9 min read ### Moving from a hosted wearable API to Open Wearables: a migration playbook Moving from a hosted wearable API to Open Wearables is usually a re-integration rather than a data migration. This playbook walks through the decisions, the steps in order, how your users reconnect and what to tell your security team. Guides · Oct 26, 2026 · 7 min read ### Why teams move from a hosted wearable API to Open Wearables A hosted wearable API is a sensible way to start. As a product grows, the questions change: whose provider apps, whose cloud, whose schema. Here is why teams move to Open Wearables, what they get after the move, and what it asks of them. Guides · Jul 28, 2026 · 5 min read ### How Wearable Data Flows From Device to Your API: A Complete Architecture Guide Wearable data does not go directly from device to your API. It flows through the provider cloud, then Open Wearables, then PostgreSQL, then your application. Here is what each step looks like. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/how-to-structure-health-data-for-ai-llm # How to Structure Health Data for AI: What Your LLM Actually Needs [All posts](https://openwearables.io/blog) [Guides](https://openwearables.io/blog/category/guides) Open Wearables Team · Jul 22, 2026 · 6 min read ## Key Takeaways - LLMs do not need all your health data. They need the right data, in a consistent structure, with enough context to reason about it. - Raw wearable data from different providers uses different field names, units, and timestamp formats. An LLM receiving inconsistent data will produce inconsistent output. - Open Wearables normalizes all provider data into a unified model: Workout, SleepSession, ActivitySummary, and TimeSeriesSample. Every provider returns the same field names, same units, same timestamp format. - The MCP server exposes this normalized data through five queryable tools, so your LLM retrieves exactly what it needs for each question rather than receiving a data dump. - What the LLM does with that data is your responsibility. Open Wearables provides the data structure. You provide the reasoning framework. The most common mistake in health AI integrations is treating data formatting as a solved problem. Developers spend weeks on OAuth flows and provider integrations, get data flowing, and then pass raw API responses directly into an LLM prompt. The model produces something that sounds plausible. Then a user from a different provider connects, the field names are different, the units are different, and the output breaks. Structured health data for AI is not just about getting data into context. It is about getting consistent, queryable, well-typed data that a model can reason about reliably regardless of which device a user has. ## Why Consistency Matters More Than Completeness An LLM reasoning about health data needs to compare values over time, across sessions, across metrics. That comparison only works if the data is consistent. Consider distance. Garmin returns distance in meters. Some providers return it in kilometers. If your prompt contains workout records from both without normalization, the model has no way to know which unit applies to which record. It will either guess or produce nonsense. Consider timestamps. Some providers return local time. Others return UTC. If your model is answering "how did I sleep last Tuesday?" and the timestamps are not normalized to a consistent format, the answer may be wrong by hours. Consider field names. A workout's average heart rate might be averageHR, avg_hr, heart_rate_avg, or heartRate depending on the provider. If your prompt mixes these, the model treats them as different concepts. The solution is normalization before the data reaches the model, not prompt engineering around the inconsistency. ## The Open Wearables Data Model Open Wearables normalizes all provider data into a consistent set of types. These are the schemas your LLM receives through the API or MCP tools, defined in the backend codebase. ### Workout A discrete exercise session: ``` id: UUID type: str # "running", "cycling", "swimming", etc. name: str | None # "Morning Run" start_time: datetime # UTC end_time: datetime # UTC duration_seconds: int | None calories_kcal: float | None distance_meters: float | None # always meters, regardless of provider avg_heart_rate_bpm: int | None # always bpm max_heart_rate_bpm: int | None avg_pace_sec_per_km: int | float | None elevation_gain_meters: float | None source: SourceMetadata # which provider and device ``` Distance is always in meters. Heart rate is always in bpm. Timestamps are always UTC. The model does not need to handle unit conversion or field name variations. ### SleepSession A discrete sleep or nap period: ``` id: UUID start_time: datetime end_time: datetime duration_seconds: int sleep_duration_seconds: int | None # actual sleep, not just time in bed efficiency_percent: float | None is_nap: bool # distinguishes naps from main sleep stages: awake_minutes: int | None light_minutes: int | None deep_minutes: int | None rem_minutes: int | None source: SourceMetadata ``` The is_nap field is populated for providers that distinguish naps from main sleep sessions (Apple Health, Oura). This matters when your model is calculating sleep debt or readiness: a 25-minute afternoon nap and an 8-hour overnight session are both sleep records, but should not be treated identically. ### ActivitySummary Daily aggregate data: ``` date: date steps: int | None distance_meters: float | None active_calories_kcal: float | None total_calories_kcal: float | None active_minutes: int | None sedentary_minutes: int | None intensity_minutes: light: int | None moderate: int | None vigorous: int | None heart_rate: avg_bpm: int | None max_bpm: int | None min_bpm: int | None source: SourceMetadata ``` ### TimeSeriesSample High-frequency time series data: ``` timestamp: datetime type: SeriesType # "heart_rate", "spo2", "hrv", etc. value: float | int unit: str # "bpm", "percent", "ms", etc. source: SourceMetadata ``` This is the continuous data: heart rate every few seconds during a workout, SpO2 readings, HRV samples. For most LLM queries, you do not want to pass raw time series into context. You pass aggregates or specific samples, not thousands of rows. ## What to Pass to Your LLM and What to Leave Out The normalized data model gives you consistency. The next question is selection: what subset of that data belongs in the context for a given query? - For questions about training: workouts from the relevant time range, activity summaries for the same period. Avoid raw time series unless the question is specifically about intra-workout patterns. - For questions about recovery or readiness: sleep sessions, HRV samples if available, resting heart rate from activity summaries. Training load from recent workouts for context. - For questions about daily habits: activity summaries (steps, active minutes, calories). Sleep summaries. No need for individual workout records. What to avoid: full-resolution time series (thousands of rows per session), data outside the relevant time window, fields that are null for most providers, multiple records of the same session from different providers without deduplication. The Open Wearables MCP server handles the selection problem: the model calls a tool with a date range and the tool returns the relevant data. The model does not receive everything; it queries what it needs. ## The Reasoning Layer Is Yours to Build Open Wearables provides consistent, normalized, queryable health data. It does not tell your LLM how to reason about that data. For a production health AI feature, you need to define: reference ranges (a resting heart rate of 58 bpm means nothing without knowing the user's baseline), domain rules (what metrics matter for your use case and how to interpret them), guardrails (what the model should not conclude without clinical context), and aggregation logic (when a user has both Garmin and Apple Health data for the same day, which takes precedence). The data structure is the foundation. The reasoning layer is what you build on top of it. ## Related articles - [How to Give Your LLM Access to Wearable Data](https://openwearables.io/blog/how-to-give-your-llm-access-to-wearable-data) - [How to build an AI health coaching app with wearable data](https://openwearables.io/blog/how-to-build-ai-health-coaching-app-with-wearable-data) - [How to normalize wearable data across providers](https://openwearables.io/blog/how-to-normalize-wearable-data-across-providers) - [What wearable app development actually looks like in 2026](https://openwearables.io/blog/what-wearable-app-development-actually-looks-like-in-2026) ## FAQ ### Does Open Wearables handle unit normalization automatically? Yes. All provider data is normalized to consistent units at ingestion. Distance is always in meters. Heart rate is always in bpm. Duration is always in seconds. Your LLM receives consistent units regardless of which provider a user has connected. ### How do I handle users with multiple connected devices? Open Wearables stores records from each provider separately with a source field identifying the provider and device. The platform includes configurable data priority rules for determining which source to use when multiple providers record the same data. Your application sets the priority order. ### Should I pass raw time series data to my LLM? Generally no. Full-resolution time series produces thousands of rows that exceed context limits and add noise. Pass aggregates (ActivitySummary, SleepSession) for most queries. Use TimeSeriesSample for specific lookups: peak heart rate during a workout, HRV samples around a specific event. ### How does the MCP server decide what data to return? The MCP tools are queryable by user ID and date range. The model calls the appropriate tool with the parameters it needs. It does not receive a data dump; it queries specific data for specific questions. ### Can I build my own reasoning layer on top of Open Wearables data? Yes. The normalized data model and REST API give you full access to the underlying data. You can build your own prompting strategy, aggregation logic, and domain rules entirely outside of Open Wearables. The platform handles data ingestion and normalization. The reasoning layer is yours. ## Keep reading Guides · Oct 26, 2026 · 9 min read ### Moving from a hosted wearable API to Open Wearables: a migration playbook Moving from a hosted wearable API to Open Wearables is usually a re-integration rather than a data migration. This playbook walks through the decisions, the steps in order, how your users reconnect and what to tell your security team. Guides · Oct 26, 2026 · 7 min read ### Why teams move from a hosted wearable API to Open Wearables A hosted wearable API is a sensible way to start. As a product grows, the questions change: whose provider apps, whose cloud, whose schema. Here is why teams move to Open Wearables, what they get after the move, and what it asks of them. Guides · Jul 28, 2026 · 5 min read ### How Wearable Data Flows From Device to Your API: A Complete Architecture Guide Wearable data does not go directly from device to your API. It flows through the provider cloud, then Open Wearables, then PostgreSQL, then your application. Here is what each step looks like. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/how-to-sync-wearable-data-from-multiple-devices # How to sync wearable data from multiple devices [All posts](https://openwearables.io/blog) [Guides](https://openwearables.io/blog/category/guides) Open Wearables Team · May 21, 2026 · 3 min read ## Key Takeaways - Syncing from multiple devices requires handling fundamentally different sync models: Garmin is webhook-only, Polar and Suunto use REST polling, Whoop uses OAuth with a 30-day default, Apple Health requires a mobile SDK. - Open Wearables abstracts provider-specific logic through a unified API with a single set of read endpoints. - Canonical units enforced at ingestion: heart rate in bpm, distance in meters, temperature in Celsius, timestamps in UTC. - Deduplication is automatic: records with the same `external_id` are not duplicated. - Garmin is webhook-only. Do not use the generic `/sync` endpoint for Garmin. Historical backfill covers 30 days. - Suunto and Polar both support REST polling with time range and data type filters. - Apple Health requires the Open Wearables mobile SDK. Cloud sync is not available. - The unified data model has five components: Events, Time Series, Descriptors, ID Mapping, Series Type Definitions. Most users who track health data seriously do not use just one device. The Garmin API, for example, handles daily activity and workouts. A Whoop strap captures recovery and sleep. An Apple Watch sits on the wrist for spot checks. The data exists. The problem is getting it into one place without losing context, duplicating records, or writing glue code for every provider combination. ## Step 1: Create a user ``` POST /api/v1/users X-Open-Wearables-API-Key: your_api_key ``` ## Step 2: Connect each device ``` GET /api/v1/oauth/{provider}/authorize?user_id={id}&redirect_uri={url} X-Open-Wearables-API-Key: your_api_key ``` Replace `{provider}` with `garmin`, `polar`, `suunto`, `whoop`, etc. ## Step 3: Sync data per provider ### Garmin API: webhook-only delivery The Garmin API does not support REST polling. Data is delivered via webhooks. For historical data: ``` POST /api/v1/providers/garmin/users/{user_id}/sync/historical ``` Covers up to 30 days. Do not use the generic `/sync` endpoint for Garmin. ### Polar: REST polling with options ``` POST /api/v1/providers/polar/users/{user_id}/sync?samples=true&zones=true&route=true ``` ### Suunto: REST polling with filters ``` POST /api/v1/providers/suunto/users/{user_id}/sync?data_type=all ``` Key parameters: `since` (Unix timestamp), `limit` (max 100), `offset`, `filter_by_modification_time` (default true), `data_type` (workouts/247/all). ### Whoop: OAuth, last 30 days default ``` POST /api/v1/providers/{provider}/users/{user_id}/sync ``` Optional: `summary_start_time`, `summary_end_time`. ### Apple Health: mobile SDK required Cloud sync is not available. Use the Open Wearables mobile SDK on iOS. ## Step 4: Read unified data ``` GET /api/v1/users/{user_id}/timeseries GET /api/v1/users/{user_id}/events/workouts GET /api/v1/users/{user_id}/events/sleep ``` All providers return data through the same endpoints in the same normalized format. ## The unified data model Five components: **Events** (workouts, sleep sessions), **Time Series** (high-frequency floats with type and device source), **Descriptors** (session metadata), **ID Mapping** (provider IDs to internal IDs), **Series Type Definitions** (schema per metric type including units). Stack: SQLAlchemy, Pydantic, Alembic. ## Provider coverage notes 24/7 continuous monitoring: Garmin, Suunto, Ultrahuman, Oura (coming soon). Whoop and Strava have significant limitations. Strava has no sleep data. ## See Related Articles - [How to integrate Apple Health data into your app](https://openwearables.io/blog/how-to-integrate-apple-health-data-into-your-app) - [Garmin Connect API: developer guide](https://openwearables.io/blog/garmin-connect-api-developer-guide-activities-health-metrics) - [Building a health app with Whoop API data](https://openwearables.io/blog/building-a-health-app-with-whoop-api-data) - [Wearable API integration: comparing SaaS, custom build, and open source](https://openwearables.io/blog/wearable-api-integration-saas-custom-build-open-source) - [How to integrate Strava without building OAuth from scratch](https://openwearables.io/blog/how-to-integrate-strava-without-building-oauth-from-scratch) - [The wearable app development checklist: what you actually need to build (and what you don't)](https://openwearables.io/blog/wearable-app-development-checklist) - [Wearable Data Deduplication: How to Handle Users With Multiple Devices](https://openwearables.io/blog/wearable-data-deduplication-multiple-devices) ## FAQ **Do I need separate sync logic for each device?** No. Open Wearables handles provider-specific sync behavior internally. You trigger sync per provider using the appropriate endpoint, then read data through unified endpoints. **What happens if the same data syncs twice?** Records are deduplicated by `external_id`. Syncing the same data multiple times will not create duplicates. **Can I sync historical data for all providers?** It depends on the provider. Garmin has a dedicated historical sync endpoint covering up to 30 days. Suunto accepts `since=0` for all available data. Whoop defaults to the last 30 days. **My users have Apple Watches. Can I sync Apple Health data via the API?** Apple Health requires the Open Wearables mobile SDK on iOS. Cloud-only sync is not available. **How do I handle a user who adds a second device?** Each provider connection is independent under the same `user_id`. Run OAuth for each provider and data from all of them will be available under that single user in the unified model. ## Keep reading Guides · Oct 26, 2026 · 9 min read ### Moving from a hosted wearable API to Open Wearables: a migration playbook Moving from a hosted wearable API to Open Wearables is usually a re-integration rather than a data migration. This playbook walks through the decisions, the steps in order, how your users reconnect and what to tell your security team. Guides · Oct 26, 2026 · 7 min read ### Why teams move from a hosted wearable API to Open Wearables A hosted wearable API is a sensible way to start. As a product grows, the questions change: whose provider apps, whose cloud, whose schema. Here is why teams move to Open Wearables, what they get after the move, and what it asks of them. Guides · Jul 28, 2026 · 5 min read ### How Wearable Data Flows From Device to Your API: A Complete Architecture Guide Wearable data does not go directly from device to your API. It flows through the provider cloud, then Open Wearables, then PostgreSQL, then your application. Here is what each step looks like. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/how-to-use-oura-ring-data-in-your-app # How to use Oura ring data in your app [All posts](https://openwearables.io/blog) [Oura](https://openwearables.io/blog/category/oura) Open Wearables Team · May 3, 2026 · 5 min read ## Key takeaways - Readiness Score and HRV trend are the most actionable Oura signals for coaching and wellness products - Body temperature deviation is a unique signal for illness detection, female health tracking and recovery monitoring that competitors largely do not offer - Oura's 5-minute HRV resolution during sleep supports more granular analysis than a single overnight average - Pairing Oura with GPS activity providers fills the gap where Oura's workout tracking is limited - Open Wearables normalizes Oura data alongside eight other providers for multi-device applications ## Introduction Oura Ring users are a specific type of health consumer. They bought a ring rather than a watch because they care more about sleep quality and recovery than about GPS pace and workout tracking. They tend to be data-literate, motivated by long-term health optimization, and willing to engage with nuanced metrics. Building something valuable for them means going beyond displaying numbers on a dashboard. The products that work best with Oura data do two things: they contextualize the scores (explaining what drove a given Readiness or Sleep Score) and they track trends over time (showing how the user's HRV baseline has shifted over months, or how their deep sleep percentage correlates with their training load). Raw number display is table stakes. Insight is what drives retention. This guide covers how to use Oura's data effectively in a product context, including which metrics matter most, how to compute derived signals, how to handle Oura's distinctive temperature data, and how to fill Oura's gaps with other providers. ## The readiness score and its components Oura's Readiness Score is the starting point for most product features. It is a daily composite of five contributing factors, each scored independently and weighted to produce the 0-100 output. The five contributors are: sleep score from the previous night, HRV balance (today's HRV relative to the 28-day rolling average), resting heart rate balance (today's RHR relative to the rolling trend), body temperature deviation, and previous day activity score. Each contributor is available individually through the API, which means you can build feature-rich explanations rather than just showing the headline score. The most useful product pattern is a waterfall breakdown: this is your Readiness Score, here are the five factors, here is which one is dragging it down, and here is what that typically means. A user with a score of 62 who sees that their HRV balance is 78% of their baseline understands something concrete: their nervous system is more stressed than normal. A user who sees that their body temperature was elevated by 0.6 degrees has an early signal worth paying attention to. Building this breakdown requires fetching the readiness record's contributors object and mapping each field to a user-readable explanation. This is product work, not data work, and it is where most of the value in an Oura integration lives. ## HRV analysis with oura's granular data Most wearable APIs provide a single overnight HRV value: the average or minimum across the full sleep period. Oura provides 5-minute interval HRV readings throughout the night, which enables a level of analysis that a single number cannot support. Sleep stage HRV patterns are physiologically meaningful. HRV is typically highest during deep slow-wave sleep, when the parasympathetic nervous system is most active, and lower during REM sleep and light sleep. A night where HRV spikes during deep sleep and remains elevated through REM indicates healthy autonomic nervous system recovery. A night where HRV stays flat or low across all stages despite adequate sleep duration suggests incomplete physiological recovery despite time in bed. The 28-day rolling baseline that Oura uses internally for HRV balance calculation is the right reference point for individual context. Computing this baseline in your own data layer gives you control over how you use it in features. You can flag days where HRV is more than one standard deviation below the baseline, track baseline drift over months as a fitness indicator, or alert users when the baseline has declined over consecutive weeks. ## Body temperature as a product signal Body temperature deviation is the Oura feature that most apps underutilize. It is also one of the most distinctive signals in the consumer wearable space. Oura reports nightly temperature as deviation from the user's personal baseline, not absolute temperature. Typical deviation values range from -0.5 to +0.5 degrees Celsius on normal nights. For general health monitoring, elevated temperature of more than +0.5 degrees on consecutive nights is worth surfacing to users. It frequently precedes subjective illness symptoms by one to two days. Users who catch this early signal tend to value it highly because it gives them actionable information before they feel unwell. For women's health applications, temperature is a primary fertility signal. Body temperature rises by 0.2 to 0.5 degrees after ovulation due to the thermogenic effect of progesterone and remains elevated through the luteal phase. Oura's nightly temperature deviation is the data foundation for cycle phase detection and fertile window estimation, which is why Oura has partnerships with Natural Cycles and other reproductive health platforms. For performance and recovery applications, unusual temperature elevations on non-illness nights often correlate with high training load, elevated cortisol, or travel and circadian disruption. Flagging temperature deviations alongside recovery score drops helps users understand multi-factor recovery patterns. ## Filling oura's gaps Oura is a recovery and sleep platform. It is not built for workout tracking, GPS or daily activity monitoring. For a complete health product, these gaps need to be filled by other providers. The most natural pairing is Oura plus a GPS activity provider. Strava or Garmin covers training load: what workout did the user do, at what intensity, with what heart rate response. Oura covers recovery: how did the body respond overnight. The combination supports features like training load versus recovery correlation, which is one of the most actionable insights you can give an athlete. For users who wear both Oura and Whoop, showing both recovery signals side by side is valuable rather than trying to merge them. The two devices measure similar constructs via different methodologies. Agreement between them increases confidence in the signal. Divergence is itself informative and worth surfacing. ## Open Wearables Open Wearables is an open-source platform that connects your application to wearable and health data providers through a single API. One normalized data model, multi-provider support in a single self-hosted deployment, no per-user fees, MIT licensed, and health intelligence built in: normalized recovery, sleep, activity and biometric data ready for your product layer. We offer custom deployment and integration support through Momentum. If your team needs help getting to production faster, we can set up and configure Open Wearables as part of a managed engagement. [Let's talk](https://www.themomentum.ai/lets-talk). [Book a demo](https://openwearables.io/book) to see how Open Wearables fits your use case. ## Oura integration View the full [Oura integration documentation](https://openwearables.io/integrations/oura) on Open Wearables. ## See related articles [Oura API: Accessing Ring Data, Sleep, HRV and Readiness](https://openwearables.io/blog/oura-api-accessing-ring-data-sleep-hrv-readiness) [Building a Health App With Whoop API Data](https://openwearables.io/blog/building-a-health-app-with-whoop-api-data) [Garmin Connect API: Developer Guide for Activities and Health Metrics](https://openwearables.io/blog/garmin-connect-api-developer-guide-activities-health-metrics) ## Keep reading Oura · May 3, 2026 · 10 min read ### Oura API: accessing ring data, sleep, HRV and readiness The Oura Ring API provides Sleep Score, Readiness Score, HRV, body temperature deviation and SpO2 through a clean REST interface. Here's what it offers and how to build with it. Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. Guides · Oct 26, 2026 · 9 min read ### Moving from a hosted wearable API to Open Wearables: a migration playbook Moving from a hosted wearable API to Open Wearables is usually a re-integration rather than a data migration. This playbook walks through the decisions, the steps in order, how your users reconnect and what to tell your security team. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/how-wearable-data-flows-device-to-api-architecture # How Wearable Data Flows From Device to Your API: A Complete Architecture Guide [All posts](https://openwearables.io/blog) [Guides](https://openwearables.io/blog/category/guides) Open Wearables Team · Jul 28, 2026 · 5 min read ## Key Takeaways - Wearable data does not flow directly from device to your API. It goes through the provider's cloud first, then to Open Wearables via webhook or polling, then into your PostgreSQL instance, then out through the Open Wearables REST API. - The delivery model varies by provider: Garmin pushes data via webhook stream, Oura and Strava send webhook pings that trigger a follow-up pull, and mobile providers (Apple Health, Google Health Connect) send data through the device SDK. - Open Wearables uses Celery and Redis for background processing. Webhook events are processed asynchronously so your endpoint returns quickly even when data processing takes longer. - The normalized data model sits in PostgreSQL. Every provider's data lands in the same EventRecord, DataPointSeries, and PersonalRecord format before it reaches your application. - Your application never touches raw provider data. It queries the normalized Open Wearables REST API. When developers first integrate wearable data, the mental model is simple: user has a device, device has data, data goes to your app. The actual flow has several more steps, and each step has implications for latency, reliability, and how you architect your application. This article maps the full data flow from a user's wearable device to your application's API call, using Open Wearables as the integration layer. ## The Full Data Flow ow-data-flow.png Each step in this chain has different latency characteristics and failure modes. ## Step 1: Device to Provider Cloud The user wears the device. When the device syncs (via Bluetooth to the provider's mobile app, or via Wi-Fi in some cases), the raw sensor data uploads to the provider's cloud infrastructure. This step happens entirely outside Open Wearables and outside your control. The sync frequency depends on the device and the provider. Most wearables sync automatically when the user opens the provider's app or when the device connects to the phone. ## Step 2: Provider Cloud to Open Wearables This is where provider architectures diverge significantly. - **Webhook stream (Garmin):** Garmin pushes the complete data payload directly to a registered endpoint on your Open Wearables instance. Open Wearables registers this webhook endpoint during the OAuth connection setup. - **Webhook ping with REST pull (Oura, Strava, Polar, Whoop):** The provider sends a lightweight notification to Open Wearables indicating that new data is available. Open Wearables receives the ping, then makes a REST API call to the provider to fetch the actual data. Oura, Strava, and Polar also support programmatic webhook registration through a provider API. - **REST polling (Fitbit, Ultrahuman, and others):** Open Wearables polls the provider's API on a schedule using Celery background tasks to check for new data. - **Mobile SDK (Apple HealthKit, Google Health Connect, Samsung Health):** There is no server-side API. The user's device runs the Open Wearables mobile SDK (Flutter for iOS, Android SDK for Google and Samsung), which reads data from the device and sends it to your Open Wearables instance directly. Your Open Wearables instance exposes a webhook receiver endpoint for each supported provider. Webhook registrations are managed through the Open Wearables API: ``` POST /api/v1/webhooks/subscriptions GET /api/v1/webhooks/subscriptions PUT /api/v1/webhooks/subscriptions/{subscription_id} DELETE /api/v1/webhooks/subscriptions/{subscription_id} ``` ## Step 3: Processing in Open Wearables When data arrives (via webhook or polling), Open Wearables does not process it synchronously in the request handler. It queues the work for Celery background workers backed by Redis. The webhook endpoint receives the payload and returns a 200 response quickly. The actual processing happens asynchronously: the Celery worker normalizes the data, maps it to the Open Wearables data model, handles deduplication, and writes to PostgreSQL. You can also trigger manual syncs for a user and provider through the REST API: ``` POST /api/v1/{provider}/users/{user_id}/sync POST /api/v1/{provider}/users/{user_id}/sync/historical ``` ## Step 4: Normalized Storage in PostgreSQL After processing, all provider data lands in the same normalized format regardless of its origin. The Open Wearables data model uses three primary types: - **EventRecord** (workouts, sleep sessions, menstrual cycle records): start and end timestamps, duration, activity type, aggregated values. Linked to EventRecordDetails for extended fields. - **DataPointSeries** (continuous time series): high or medium frequency sensor data (heart rate, SpO2, HRV, cadence). Each sample has a timestamp, type, value, unit, and source identifier. - **PersonalRecord** (user descriptors): slowly changing user information (birth date, sex, weight, height). Used to calibrate algorithms. Every record carries a source identifier linking it to the provider and device that contributed it. This is how the priority system and deduplication work: the data is always stored per-source, and queries apply priority rules to determine what to return. ## Step 5: Your Application Queries the REST API Your application never interacts with raw provider data. It queries the normalized Open Wearables REST API using an API key generated in the developer portal. ``` # Workouts for a user GET /api/v1/users/{user_id}/events/workouts # Sleep sessions GET /api/v1/users/{user_id}/events/sleep # Daily activity summary GET /api/v1/users/{user_id}/summaries/activity # Time series data GET /api/v1/users/{user_id}/timeseries ``` All endpoints return data in the same format regardless of which provider the user has connected. Your application logic does not branch on provider. ## What This Means for Your Application Architecture - **Latency is not real-time.** The chain from device to your API involves at least two hops before data reaches your system. Plan your application accordingly. - **You do not need to be always-on for data delivery.** Open Wearables stores data in your PostgreSQL instance as it arrives. Your application can query it on demand rather than needing to receive real-time events. - **Outbound webhooks are on the roadmap.** Check the GitHub repository for current implementation status. Until they are available, query the API on a schedule or use Celery tasks for scheduled processing. ## Related articles - [How to Handle OAuth, Webhooks, and Token Refresh Across Multiple Wearable Providers](https://openwearables.io/blog/how-to-handle-oauth-webhooks-token-refresh-wearable-providers) - [How to Add Wearable Support to an Existing Health App in Days, Not Months](https://openwearables.io/blog/how-to-add-wearable-support-existing-health-app) - [How to Structure Health Data for AI: What Your LLM Actually Needs](https://openwearables.io/blog/how-to-structure-health-data-for-ai-llm) - [Wearable Data Deduplication: How to Handle Users With Multiple Devices](https://openwearables.io/blog/wearable-data-deduplication-multiple-devices) ## FAQ ### How quickly does data appear in my API after a user syncs their device? It depends on the provider and delivery model. Garmin uses a webhook stream and data appears shortly after the user syncs. Providers that use webhook pings with REST pull (Oura, Strava, Polar) add a follow-up fetch step. Polling-based providers depend on the polling schedule. Mobile SDK providers (Apple Health) deliver data when the SDK sends it from the device. ### Does Open Wearables handle webhook retries from providers? Webhook endpoints return 200 responses quickly, which prevents providers from treating failed processing as a delivery failure. If the Celery worker encounters an error during processing, the task can be retried without the provider resending the original payload. ### Can I trigger a manual sync for a user? Yes. The API exposes sync endpoints per provider and user: POST /api/v1/{provider}/users/{user_id}/sync and POST /api/v1/{provider}/users/{user_id}/sync/historical. Historical sync availability depends on the provider. ### What happens if Open Wearables is down when a provider sends a webhook? The provider's webhook delivery fails. Provider retry behavior varies. For production deployments, ensure your Open Wearables instance has high availability. Data missed during downtime may need to be recovered through historical sync if the provider supports it. ### Do I need to register webhook endpoints with each provider manually? No. Open Wearables handles webhook registration with providers that support programmatic registration (Oura, Strava, Polar) through its webhook subscription API. For providers that require manual registration, the docs at docs.openwearables.io/provider-setup include setup guides. ## Keep reading Guides · Oct 26, 2026 · 9 min read ### Moving from a hosted wearable API to Open Wearables: a migration playbook Moving from a hosted wearable API to Open Wearables is usually a re-integration rather than a data migration. This playbook walks through the decisions, the steps in order, how your users reconnect and what to tell your security team. Guides · Oct 26, 2026 · 7 min read ### Why teams move from a hosted wearable API to Open Wearables A hosted wearable API is a sensible way to start. As a product grows, the questions change: whose provider apps, whose cloud, whose schema. Here is why teams move to Open Wearables, what they get after the move, and what it asks of them. Guides · Jul 22, 2026 · 5 min read ### How to Build an AI Agent That Reasons Over Health Data An AI agent that reasons over health data is different from one that reads it. Here is how the Open Wearables MCP server works and how to build the reasoning layer on top of it. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/open-wearables-0-10-0-dashboard-nutrition-data # Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks [All posts](https://openwearables.io/blog) [Releases](https://openwearables.io/blog/category/releases) Open Wearables Team · Oct 26, 2026 · 11 min read Open Wearables 0.10.0 is available. It rebuilds the dashboard in SvelteKit and adds nutrition data with 42 new series types. Outgoing webhooks now carry the sync they came from. Calories and data sources are more accurate across providers. The release merges 123 pull requests in total. Several changes are breaking. Most of them touch a specific provider or an edge case, but read the list below before upgrading. ## Key takeaways - New dashboard in SvelteKit with light and dark themes and a mobile layout, plus period presets and provider filters on the user profile - 42 new nutrition series types plus a meal event type, with GET and DELETE endpoints for meals - Every data webhook carries a sync block that tells a backfill from live sync, plus two new per-data-type sync events - New total_energy series for providers that report only a total. Basal energy is now stored for Garmin, Polar, Oura and SensorBio - Data sources are matched by device ID, then by app bundle ID and model, so one device no longer splits into several sources - New personal-record endpoint, so max heart rate no longer defaults to 190 bpm - Sentry stops receiving health data and PII by default - Anonymous daily usage telemetry, off with TELEMETRY_ENABLED=false or DO_NOT_TRACK=1 ## Breaking changes Breaking changes in 0.10.0. Most of them probably don't affect you, since they only touch specific providers or edge cases. Read the list carefully before upgrading. - active_calories_kcal is now null instead of 0 when a day has no active energy, for every provider. total_calories_kcal in /summaries/activity is null when a day has neither total nor basal energy. ( [#1801](https://github.com/the-momentum/open-wearables/pull/1801)) - Whoop cycle energy is stored as the new total_energy series instead of active_energy, because it includes BMR. Webhooks for Whoop cycles now send series.total_energy.created instead of series.active_energy.created. A startup migration relabels stored rows and drops 0 kJ no-wear cycles. ( [#1801](https://github.com/the-momentum/open-wearables/pull/1801)) - Ultrahuman active minutes move from active_time to exercise_time. Outgoing webhooks send series.exercise_time.created instead of series.active_time.created. active_minutes in /summaries/activity falls back to the step-based estimate for Ultrahuman users. A startup migration relabels stored rows. ( [#1765](https://github.com/the-momentum/open-wearables/pull/1765)) - Ultrahuman HRV moves from heart_rate_variability_sdnn to heart_rate_variability_rmssd, as confirmed by Ultrahuman. A startup migration relabels stored rows. ( [#1686](https://github.com/the-momentum/open-wearables/pull/1686)) - Workouts from the mobile SDK and Apple XML import that report no calories now have null calories instead of 0. A startup migration clears the stored zeros. ( [#1874](https://github.com/the-momentum/open-wearables/pull/1874)) - SDK refresh tokens of deleted applications are removed. Their users get a 401 on the next refresh. The SDK reports it as an auth error. See [Handle expired sessions](https://openwearables.io/docs/sdk/integration#handle-expired-sessions). ( [#1841](https://github.com/the-momentum/open-wearables/pull/1841)) - Outgoing webhook payloads are kept in Svix for 7 days instead of 90. Change it with OUTGOING_WEBHOOK_PAYLOAD_RETENTION_DAYS (5 to 90). Payloads already stored keep their 90-day expiry. ( [#1719](https://github.com/the-momentum/open-wearables/pull/1719)) - 24/7 sync results have a new, typed shape. data_247 is now an object with status, item counters and one entry per provider task. It replaces the flat map of task names to row counts along with the success and saved flags. ( [#1501](https://github.com/the-momentum/open-wearables/pull/1501)) The 24/7 change shows up in the sync endpoint response (details.data_247) and in the sync.completed and sync.failed webhooks (metadata.params.data_247). Sync status events use the new shape too. A sync where every 24/7 task fails now returns success: false and emits sync.failed. Error fields carry a short code such as http_401 or IntegrityError instead of the exception text. In params.workouts, error is renamed to error_code. ### Check for SDK users of deleted applications Before upgrading, this query lists deleted applications whose SDK users still hold active refresh tokens: ``` SELECT rt.app_id, count(*) AS active_tokens, count(DISTINCT rt.user_id) AS users, max(coalesce(rt.last_used_at, rt.created_at)) AS last_activity FROM refresh_token rt LEFT JOIN application a ON a.app_id = rt.app_id WHERE rt.token_type = 'sdk' AND rt.revoked_at IS NULL AND a.id IS NULL AND split_part(rt.app_id, ':', 1) NOT IN ('admin', 'invite') GROUP BY rt.app_id ORDER BY last_activity DESC; ``` Apps that handle the SDK auth error by getting new tokens from their backend and passing them to updateTokens() recover on their own. This works as long as that backend uses the credentials of an application that still exists. ### Longer first startup The first startup after upgrading can take longer than usual. Data migrations merge duplicated data sources and relabel the rows listed above. Expensive migrations are now recorded in a new data_migration table and run once per instance. More: [Data migrations](https://openwearables.io/docs/dev-guides/data-migrations) ## New dashboard The dashboard is rewritten in SvelteKit. The layout is cleaner, with light and dark themes or an option to follow the system setting. It also works on phones, with a bottom navigation bar. Heavy pages load faster. Data Summary opens on the last 30 days by default. Tabs on the user profile have period presets (1W, 1M, 3M, 6M, 1Y) and a provider filter. The Sleep tab can show only night sleep or only naps. It can also limit the view to the highest-priority source. Each record shows which provider and device it came from. The user profile also got a Meals tab. The Women's Health tab is always visible, empty when there's no data. Data sources are listed in priority order. ### Configuration The image name stays the same. So do port 3000 and VITE_API_URL, which means no configuration change is needed. Developers sign in again once after the upgrade. VITE_API_URL is now read at runtime, so one image works against any backend without a rebuild. Optionally set API_URL when the frontend can reach the API on an internal address, such as http://app:8000 on the same Docker network. Sign-in sessions live in an HttpOnly cookie, with access tokens refreshed automatically. The frontend needs no Redis. More: [Frontend configuration](https://openwearables.io/docs/deployment/docker#frontend-configuration) ## Nutrition data Open Wearables now stores nutrition data. There are 42 new series types: calories and macronutrients, fat broken down into total, saturated, mono- and polyunsaturated and trans, plus fiber, sugar, cholesterol, caffeine and a full set of vitamins and minerals. Apps that log food as meals also get a new meal event type that carries the meal's title and type along with its nutrients. Nutrition samples logged outside a meal are stored as regular time series. This is most useful with Apple Health. Food trackers such as MyFitnessPal and Cronometer write what users eat into it, as do dozens of other apps. Connecting Apple Health gets you their data without integrating each app separately. Health Connect covers all 42 nutrition types and Apple Health covers 38. Samsung Health covers 17. The Google Health API nutrition log is supported too. ``` GET /api/v1/users/{user_id}/events/meals?start_date=2026-10-05&end_date=2026-10-05 DELETE /api/v1/users/{user_id}/events/meals/{meal_id} ``` The seed generator can create meals too, with a nutrition_focused preset. ### Mobile SDK support For the mobile SDK, nutrition is supported on the backend side only for now. SDK versions that send meals from the phone's health store haven't been released yet. They're coming soon, so follow the [iOS SDK](https://github.com/the-momentum/open_wearables_ios_sdk) and [Android SDK](https://github.com/the-momentum/open_wearables_android_sdk) repos. Google Health API nutrition works with this release. More: [Nutrition data types](https://openwearables.io/docs/providers/coverage#detailed-coverage-matrix) ## Outgoing webhooks know which sync they came from Every data webhook now carries a sync block, so a consumer can tell a historical backfill from live sync: ``` "sync": { "run_id": "backfill_9f3c8ea4", "source": "backfill", "scope": "historical" } ``` source is one of pull, webhook, sdk, backfill, xml_import or linked_account. run_id joins to GET /sync/history/{run_key}. Two new events, sync.data_type.completed and sync.data_type.failed, report the result per data type. Each carries item counts plus the written and covered time ranges. Existing payloads only gain the new key. ## Calories: total, active and basal Providers that report only a total with no active/basal split now write to a new total_energy series, with a series.total_energy.created webhook. Today that's Whoop. Basal energy is now stored for Garmin, Polar, Oura and SensorBio. total_calories_kcal in summaries comes from total_energy first, with active plus basal as the fallback. Whoop cycle metrics are also anchored on the right local day. Users in negative UTC offsets no longer get two cycles summed into one day. ## Stable data sources One device or app no longer splits into several data sources. A source is now matched by device ID first, then by app bundle ID and model. An existing source gets upgraded when better data arrives. In practice, renaming an iPhone no longer creates a new source. Upgrading the phone that relays third-party Apple Health data keeps the same source too, as does Samsung sending steps without IDs. A startup migration merges the duplicates already stored. New device types were added as well, among them chest straps, earbuds, tablets, HR sensors and glucose meters. ## More data from existing providers - exercise_time (moderate plus vigorous minutes) for Garmin, Oura, Withings, Ultrahuman, Polar and Google Health - Skin temperature deviation for Garmin and Ultrahuman, plus Google Health - Per-minute step samples for Polar and Withings, with per-minute distance and active energy from Withings as well - Resting heart rate for Ultrahuman and Withings - Sleep stage timeline for Withings and SensorBio - Overnight HRV from the sleep series - Polar Nightly Recharge HRV and breathing rate stored as time series - HRV RMSSD from HealthKit (iOS 27+) - Step count from Whoop /v2/cycle - Samsung sleep score More: [Data coverage](https://openwearables.io/docs/providers/coverage) ## API additions and fixes - GET and PUT /api/v1/users/{user_id}/personal-record read and set personal details such as birth date and sex. Until now nothing could write them, so the activity summary always assumed a 190 bpm max heart rate. - is_nap filter on GET /events/sleep. - /summaries/sleep and /summaries/recovery page by night or day instead of source row. has_more is now right when several sources recorded the same nights. - Out-of-range numeric dates (inf, 1e20) return 400 instead of 500. - Outgoing webhook endpoints are listed past Svix's first page. ## Privacy and security - Sentry no longer receives health data or PII by default. Request bodies and stack-frame locals are no longer sent. Log breadcrumbs are off too. Emails and query values are filtered. SENTRY_SEND_SENSITIVE_DATA=true turns it back on for dev or staging. - Deleting a user also deletes the payloads of their outgoing webhook messages from Svix. - Signing in to the portal with the public default password now asks you to change it. With ENVIRONMENT=production you can't skip it. More: [Change Password](https://openwearables.io/docs/developer-portal/settings/change-password) - config/.env is no longer copied into locally built backend images. Images on Docker Hub never contained it. ## Self-hosting - SMTP for invitation emails. Set SMTP_HOST to use any mail provider; Resend still works as before. When no email delivery is configured, the portal hands you the invite link instead of pretending it was sent. More: [Email delivery](https://openwearables.io/docs/developer-portal/settings/team#email-delivery) - DATA_LIFECYCLE_ENABLED turns off Data Lifecycle (early access). It defaults to true. - Logs: LOG_FORMAT=legacy|json|text and LOG_LEVEL, both opt-in, plus optional OpenTelemetry log export with OTEL_ENABLED=true. More: [Log export](https://openwearables.io/docs/dev-guides/log-export) - Containers now stop gracefully: SIGTERM is forwarded to the workers. - Throttled provider requests back off instead of failing the sync. Switching a provider from webhooks back to periodic pull now deregisters its webhooks. - Periodic sync skips push-only providers. GET /sync/runs no longer scans every user. - All providers are seeded at startup, so priorities can be set before the first sync. The Priorities tab shows provider logos. - The backend runs on Python 3.14. If you build images locally, rebuild them. - Extension point for add-on modules: separately packaged Python packages can register Celery tasks (periodic ones included) and routers under /api/v1/ext/. ## Anonymous usage telemetry Self-hosted instances now send one small anonymous usage ping a day, plus one on startup. It helps the team decide what to build next and what's safe to deprecate. Counts are sent as order-of-magnitude buckets and endpoints as route templates. There's no health data or user data in the ping. It also contains no credentials, hostnames, IPs or URLs. Turn it off with either setting: ``` TELEMETRY_ENABLED=false DO_NOT_TRACK=1 ``` More: [Telemetry](https://openwearables.io/docs/dev-guides/telemetry) ## Upgrading ``` docker compose pull docker compose up -d ``` Migrations run automatically on startup. The first startup can take longer while they merge data sources and relabel rows. Before you upgrade, read the breaking changes and run the SDK token query if you have SDK users. After you deploy, update webhook consumers that filter on series.active_energy.created for Whoop or series.active_time.created for Ultrahuman. Check any client that reads data_247 or expects 0 instead of null for calories. Clients relying on 90-day payload retention in Svix need the retention setting raised. We recommend the official Docker images: - backend: [themomentum/open-wearables-backend](https://hub.docker.com/r/themomentum/open-wearables-backend) - frontend: [themomentum/open-wearables-frontend](https://hub.docker.com/r/themomentum/open-wearables-frontend) Full changelog: [github.com/the-momentum/open-wearables/releases/tag/0.10.0](https://github.com/the-momentum/open-wearables/releases/tag/0.10.0) ## What's next 0.11 is coming soon and focuses on further data model improvements on the way to [Open Wearables 1.0](https://openwearables.io/docs/roadmap#the-road-to-1-0). If there's something you think 1.0 should include, tell us on [Discord](https://discord.gg/qrcfFnNE6H) or in [Discussions](https://github.com/the-momentum/open-wearables/discussions). Feedback from teams that have run Open Wearables for a while is especially welcome. ## Frequently asked questions ### Do I need to change frontend configuration for the new dashboard? No. The image name, port 3000 and VITE_API_URL are unchanged. Developers sign in again once after the upgrade. API_URL is optional, for when the frontend can reach the API on an internal address. ### Why does my Whoop webhook consumer stop receiving active energy events? Whoop cycle energy now goes to the total_energy series, because it includes BMR. Subscribe to series.total_energy.created instead of series.active_energy.created for Whoop cycles. ### Can the mobile SDK send meals yet? Not yet. Nutrition is supported on the backend. SDK versions that send meals are coming soon in the iOS and Android SDK repos. Google Health API nutrition works with 0.10.0. ### Why do some calorie fields return null after upgrading? A null means no data was recorded, a case that 0 used to hide. active_calories_kcal is null when a day has no active energy. Workouts without reported calories have null calories as well. Treat null as missing data in your client. ### How do I turn off telemetry? Set TELEMETRY_ENABLED=false or DO_NOT_TRACK=1. The ping contains no health data, user data, credentials, hostnames, IPs or URLs. For questions or feedback, open an issue on GitHub or join the Discord community. ## Open Wearables Open Wearables is an open-source platform that connects your application to wearable and health data providers through a single API. One normalized data model, multi-provider support in a single self-hosted deployment, no per-user fees, MIT licensed, and health intelligence built in: normalized recovery, sleep, activity and biometric data ready for your product layer. We offer custom deployment and integration support through Momentum. If your team needs help getting to production faster, we can set up and configure Open Wearables as part of a managed engagement. [Let's talk](https://www.themomentum.ai/lets-talk). [Book a demo](https://openwearables.io/book) to see how Open Wearables fits your use case. ## See related articles [Open Wearables 0.9.0: Google split into two providers, energy renamed, and a long list of API corrections](https://openwearables.io/blog/open-wearables-0-9-0-google-split-active-energy) [Open Wearables 0.8.0: Withings, sync history, and faster ingestion](https://openwearables.io/blog/open-wearables-0-8-0-withings-sync-history) [Getting Apple Health data into your backend](https://openwearables.io/blog/getting-apple-health-data-into-your-backend) ## Keep reading Releases · Sep 23, 2026 · 13 min read ### Open Wearables 0.9.0: Google split into two providers, energy renamed, and a long list of API corrections Open Wearables 0.9.0 splits Google into google_health and health_connect, renames energy to active_energy, disables the Google Health API rollup that wrote duplicated rows, and fixes date bounds, filters and pagination across the API. Contains breaking changes. Releases · Sep 15, 2026 · 10 min read ### Open Wearables 0.8.0: Withings, sync history, and faster ingestion Open Wearables 0.8.0 adds Withings, database-backed sync history with two new endpoints, a 3.7x faster bulk upsert path, 5 GiB Apple Health XML uploads with MinIO parity, and four account takeover fixes. Releases · Aug 13, 2026 · 7 min read ### Open Wearables 0.7.0: Google Health API, Sensor Bio, and a faster Admin UI Open Wearables 0.7.0 adds a Google Health API integration ahead of the Fitbit Web API sunset, a new Sensor Bio provider, finer Oura sleep granularity, and Admin UI and logging improvements. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/open-wearables-0-5-1-oura-strava-webhooks-live-sync-status # Open Wearables 0.5.1: Oura & Strava Webhooks, Live Sync Status, RMSSD HRV [All posts](https://openwearables.io/blog) [Releases](https://openwearables.io/blog/category/releases) Open Wearables Team · May 8, 2026 · 2 min read Open Wearables 0.5.1 is out. This release ships webhook support for Oura and Strava, live sync status via SSE, RMSSD HRV in Body Summary, and a redesigned Admin Panel dashboard. No breaking changes. Upgrade with `docker compose pull && docker compose up -d`. ## Webhooks for Oura and Strava Both providers previously synced on a periodic pull schedule. 0.5.1 adds webhook support as an opt-in alternative. Enable it per provider in Settings > Providers. Periodic pull remains the default and continues to work independently of webhook configuration. Webhooks are useful when data freshness matters. A user finishes an Oura sleep session or logs a Strava activity, the provider fires an event, Open Wearables processes and stores it. No waiting for the next pull cycle. Oura's webhook implementation was refactored to align with the new internal webhook pattern. Strava was built on the same pattern. Both should behave consistently. Requirements: - Your deployment needs a publicly reachable endpoint - The provider developer portal must be pointed at your webhook URL - Webhook delivery is per-provider, not global [Docs: docs.openwearables.io](https://docs.openwearables.io) ## Live Sync Status Sync status is now available in three places: the Admin Panel, outgoing webhook events, and the API. Admin Panel: There's a new global Syncs tab. Per-user sync history is also visible in individual user profiles. Useful for debugging data gaps or answering support questions. API (SSE): Subscribe to the sync status stream to get real-time updates as syncs progress. Integration guide: [openwearables.io/docs/api-reference/guides/sync-status-stream](https://openwearables.io/docs/api-reference/guides/sync-status-stream) Outgoing webhook events: Sync statuses are also dispatched as outgoing webhook events. Use this if you need to persist sync state beyond 24 hours. The Redis-backed status store clears after 24 hours; outgoing webhooks allow saving sync logs in your database. ## RMSSD HRV in Body Summary RMSSD is now included in the /body-summary endpoint. It sits alongside the existing metrics. No endpoint change required on your side, just an additional field in the response. Recovery scores were also migrated from data_point_series to health_score in this release. If you're querying recovery data directly, check your queries against the updated docs before upgrading. ## Redesigned Admin Panel Dashboard The dashboard layout has been rebuilt. The new design surfaces sync state across users and integrations more clearly. If you use the Admin Panel to investigate sync issues, the new layout makes that faster. No API changes, frontend only. ## Other Changes - Sleep score is recalculated after session merge (previously it reflected only the first segment) - Apple Health percent-based metrics: the x100 unit conversion is now scoped to Apple only, not applied globally - TypeScript upgraded to 6.0.2 ## Getting Started Existing deployments: ``` docker compose pull docker compose up -d ``` After upgrading, enable webhooks in Settings > Providers if you want them. They are off by default. New to Open Wearables? Start at [docs.openwearables.io/quickstart](https://docs.openwearables.io/quickstart). Docker Compose setup takes under 15 minutes. ## Community 1,631 stars on GitHub. 258 forks. 40 contributors. The full changelog is on [GitHub](https://github.com/the-momentum/open-wearables/releases/tag/0.5.1). Open issues and feature requests: [github.com/the-momentum/open-wearables/issues](https://github.com/the-momentum/open-wearables/issues). If you run into anything after upgrading, open an issue or find us on [Discord](https://discord.gg/openwearables). ## Keep reading Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. Releases · Sep 23, 2026 · 13 min read ### Open Wearables 0.9.0: Google split into two providers, energy renamed, and a long list of API corrections Open Wearables 0.9.0 splits Google into google_health and health_connect, renames energy to active_energy, disables the Google Health API rollup that wrote duplicated rows, and fixes date bounds, filters and pagination across the API. Contains breaking changes. Releases · Sep 15, 2026 · 10 min read ### Open Wearables 0.8.0: Withings, sync history, and faster ingestion Open Wearables 0.8.0 adds Withings, database-backed sync history with two new endpoints, a 3.7x faster bulk upsert path, 5 GiB Apple Health XML uploads with MinIO parity, and four account takeover fixes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/open-wearables-0-5-2-polar-webhooks-sport-type-expansion-hrv-score-integrity # Open Wearables 0.5.2: Polar Webhooks, Sport Type Expansion, and HRV Score Integrity [All posts](https://openwearables.io/blog) [Releases](https://openwearables.io/blog/category/releases) Open Wearables Team · May 20, 2026 · 3 min read Open Wearables 0.5.2 is out. This release focuses on a full Polar refactor with webhook support, expanded sport type coverage across providers, new Garmin fields, and a stricter HRV-CV scoring policy. Full release notes are on [GitHub](https://github.com/the-momentum/open-wearables/releases/tag/0.5.2). If you want to see Open Wearables running in your stack, [book a Discovery call](https://openwearables.io/). ## Key takeaways - Polar now syncs sleep and timeseries data, with optional webhook support - WorkoutType enum expanded: 70+ provider-specific mappings updated across Apple, Garmin, Suunto, and WHOOP - Garmin now fetches allDayRespiration and moveIQActivities - HRV-CV Resilience Score returns null instead of a fallback SDNN value when RMSSD data is missing - New recovery summary endpoint added - Two new contributors, bringing the total to 36 ## Polar refactor and webhook support The Polar integration has been reworked to synchronise sleep and timeseries data. By default, **Periodic Pull** remains the active sync method. Webhooks are opt-in: enable them in `Settings > Providers`. Once enabled, Polar pushes data to your Open Wearables instance rather than waiting for the next pull cycle. A few things worth knowing before you enable webhooks. Your instance needs to be publicly reachable. Polar webhook delivery has the same retry behavior as other providers, so handle duplicate event delivery gracefully. The fix for duplicate `EventRecordDetail` inserts in this release (using savepoints to handle conflicts) covers exactly this kind of scenario. If you are building a wellness or fitness app where Polar data timeliness matters, the webhook path is now viable. If you are running batch analytics, Periodic Pull is still the simpler option. ## Expanded sport type support Before 0.5.2, a lot of provider-specific activity types ended up mapped to `WorkoutType.OTHER`. That made sense as a placeholder, but it became a problem when you needed to differentiate activities in your application logic or analytics pipeline. This release expands the `WorkoutType` enum and adds explicit support for activities that were previously swallowed by `OTHER`. Over 70 provider-specific mappings have been updated across Apple, Garmin, Suunto, and WHOOP. New named types include cricket, lacrosse, racquetball, bowling, archery, fencing, fishing, wakeboarding, parkour, curling, and more. This is a non-breaking expansion since new enum values are additive. Existing records mapped to `OTHER` will not be retroactively updated, but new syncs will use the correct types. ## New Garmin fields Two fields have been added to Garmin-specific attributes: `allDayRespiration` and `moveIQActivities`. `allDayRespiration` provides continuous respiration rate data across the day, not just during tracked workouts. `moveIQActivities` exposes Garmin automatic activity detection: walking, running, cycling, and swimming identified without requiring the user to manually start a workout. ## Strict RMSSD enforcement for HRV-CV Resilience Score Previously, when overnight RMSSD data was missing for a user, the HRV-CV Resilience Score calculation would automatically fall back to SDNN. RMSSD and SDNN measure different aspects of heart rate variability. They are correlated but not equivalent, and using one as a silent substitute for the other produces scores that look valid but are computed on different underlying data. 0.5.2 disables the SDNN fallback pending further validation. Users without overnight RMSSD data will now receive a `null` score instead of a fallback value. A null score is honest. A score computed from a different metric without disclosure is not. If your application currently displays HRV-CV scores, add handling for null values and consider surfacing a message to users explaining why the score is unavailable when RMSSD data is missing. The fallback may be re-enabled once the relationship between RMSSD and SDNN in this specific calculation has been validated more rigorously. ## Other fixes and changes - New recovery summary endpoint - Fix: commit each data type individually and rollback session on exception for Oura and Whoop - Fix: cast to local date for summary endpoints - Fix: validation for date parameters in OpenAPI specs - Fix: skip invalid user rows during email validation - Fix: handle duplicate EventRecordDetail inserts gracefully with savepoint - Updated all Python and TypeScript dependencies ## Upgrading ``` docker compose pull && docker compose up -d ``` Full changelog: [github.com/the-momentum/open-wearables/releases/tag/0.5.2](https://github.com/the-momentum/open-wearables/releases/tag/0.5.2) Docs: [docs.openwearables.io](https://docs.openwearables.io) Questions or feedback: join the [Discord](https://discord.gg/openwearables) or open an issue on GitHub. ## Keep reading Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. Releases · Sep 23, 2026 · 13 min read ### Open Wearables 0.9.0: Google split into two providers, energy renamed, and a long list of API corrections Open Wearables 0.9.0 splits Google into google_health and health_connect, renames energy to active_energy, disables the Google Health API rollup that wrote duplicated rows, and fixes date bounds, filters and pagination across the API. Contains breaking changes. Releases · Sep 15, 2026 · 10 min read ### Open Wearables 0.8.0: Withings, sync history, and faster ingestion Open Wearables 0.8.0 adds Withings, database-backed sync history with two new endpoints, a 3.7x faster bulk upsert path, 5 GiB Apple Health XML uploads with MinIO parity, and four account takeover fixes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/open-wearables-0-6-0-womens-health-fit-files # Open Wearables 0.6.0: Women's Health & FIT Files [All posts](https://openwearables.io/blog) [Releases](https://openwearables.io/blog/category/releases) Open Wearables Team · Jun 13, 2026 · 4 min read ## Key takeaways - Garmin menstrual cycle tracking is now supported. The Women's Health tab appears only when related data has been synced. - A FIT file parser extracts training segments, HR zones, and power zones automatically. Running dynamics and air temperature require INGEST_WORKOUT_SAMPLES=true. - Second-by-second workout sample ingestion is opt-in via INGEST_WORKOUT_SAMPLES=true. Adds approximately 170 MB per user per month. - Oura HRV is now stored as RMSSD instead of SDNN. Existing values are automatically migrated on startup. - Multi-account sync allows the same device to sync across multiple Open Wearables accounts for testing. No configuration required. Open Wearables 0.6.0 is available. This release adds menstrual cycle tracking for Garmin, a FIT file parser with second-by-second workout sample ingestion, several Oura reliability fixes, and multi-account sync support. No breaking changes to the API. ## Women's Health: Garmin menstrual cycle tracking Garmin menstrual cycle tracking is now supported. The Women's Health tab in the admin panel appears only when related data has been synced; if no data exists for a user, the tab is hidden. Data arrives through the existing Garmin webhook pipeline and is normalized into the standard data model. Available through the API once synced. ## FIT file parser FIT files are Garmin's native workout recording format. 0.6.0 ships a parser for them and a new pipeline that extracts structured data from the files. Data extracted from FIT files (always available): - Training segments (laps, swim lengths, etc.) - Time in heart rate zones - Time in power zones Requires INGEST_WORKOUT_SAMPLES=true: - Air temperature - Running dynamics: vertical oscillation, vertical ratio, stride length, ground contact time, stance time balance FIT files are processed automatically via Garmin webhooks. There is no manual upload path. To save raw FIT files to S3, set STORE_FIT_FILES=true. Disabled by default. Adds a few to several MB per user per month. See the S3 configuration guide at openwearables.io/docs/dev-guides/raw-payload-storage. The parser is provider-agnostic and will eventually support FIT files from other devices. ## Second-by-second workout samples With INGEST_WORKOUT_SAMPLES=true, Garmin workout data is ingested at second-by-second granularity for: heart rate, speed, cadence, power, latitude, longitude, elevation, air temperature, and running dynamics. Disabled by default. Estimated additional database usage: approximately 170 MB per user per month. Enable only when your use case requires this resolution. ## Oura fixes Several bugs in the Oura integration have been resolved: - Time zone offset is now saved to the database - Sleep summary metrics are now correctly captured - Current day polling no longer drops data for daily metrics - HRV is now stored as RMSSD instead of SDNN The RMSSD migration runs automatically when the application starts. Existing SDNN values will be migrated. If you have downstream logic that depends on Oura HRV values, review this before upgrading. ## Multi-account sync Users who need to synchronise the same device with several Open Wearables accounts for testing purposes can now do this without workarounds. Pair the relevant accounts with the wearable; data is synced once from the source and copied to linked accounts. Linked accounts display a badge showing linked status and sync state. No configuration required. Full documentation: [openwearables.io/docs/architecture/multi-account-sync](https://openwearables.io/docs/architecture/multi-account-sync) ## Other changes - Redis TLS: set REDIS_SSL=true to enable rediss:// connections. - Sleep start time display: sessions beginning before midnight are now prefixed with the previous day's name, adjusted to the user's time zone. - Webhook management endpoints: new API endpoints for programmatic webhook configuration. - Suunto resting heart rate: now emitted from sleep HRMin data. - Polar sport types: indoor cycling, jump rope, and kickboxing/martial arts added. - Version display: current Open Wearables version visible in the admin panel under the logout button. ## Upgrading ``` docker compose pull docker compose up -d ``` Database migrations run automatically on startup, including the Oura HRV RMSSD migration. Full changelog: [github.com/the-momentum/open-wearables/releases/tag/0.6.0](https://github.com/the-momentum/open-wearables/releases/tag/0.6.0) Questions or feedback? Open an issue on [GitHub](https://github.com/the-momentum/open-wearables) or join the [Discord community](https://discord.gg/openwearables). ## Frequently asked questions ### What is new in Open Wearables 0.6.0? 0.6.0 adds Garmin menstrual cycle tracking, a FIT file parser with second-by-second workout sample ingestion, several Oura reliability fixes including RMSSD HRV migration, multi-account sync support, and Redis TLS. No breaking changes to the API. ### What data does the FIT file parser extract? The parser always extracts training segments (laps, swim lengths), time in heart rate zones, and time in power zones. With INGEST_WORKOUT_SAMPLES=true enabled, it additionally extracts air temperature and running dynamics: vertical oscillation, vertical ratio, stride length, ground contact time, and stance time balance. ### What is INGEST_WORKOUT_SAMPLES and should I enable it? INGEST_WORKOUT_SAMPLES=true enables second-by-second granularity for Garmin workout data: heart rate, speed, cadence, power, GPS coordinates, elevation, air temperature, and running dynamics. It is disabled by default because it adds approximately 170 MB of database usage per user per month. Enable it only when your use case requires this resolution. ### Does the Oura HRV change require manual action when upgrading? No manual action required. Oura HRV is now stored as RMSSD instead of SDNN. Existing SDNN values in the database are automatically migrated when the application starts after upgrading. If you have downstream logic that depends on Oura HRV values, review those before upgrading as the values will differ. ### What is multi-account sync in Open Wearables? Multi-account sync allows the same physical wearable device to sync data across multiple Open Wearables accounts for testing purposes. No configuration is required. Pair the relevant accounts with your wearable account and data will be synced once from the source and copied to linked accounts. ### How do I upgrade to Open Wearables 0.6.0? Run docker compose pull followed by docker compose up -d. Database migrations run automatically on startup, including the Oura HRV RMSSD migration. Review any downstream logic that depends on Oura HRV values before upgrading. ## Related articles - [Garmin Connect API: developer guide for activities and health metrics](https://openwearables.io/blog/garmin-connect-api-developer-guide-activities-health-metrics) - [How to normalize wearable data across providers](https://openwearables.io/blog/how-to-normalize-wearable-data-across-providers) - [How to sync wearable data from multiple devices](https://openwearables.io/blog/how-to-sync-wearable-data-from-multiple-devices) - [How to build an AI health coaching app with wearable data](https://openwearables.io/blog/how-to-build-ai-health-coaching-app-with-wearable-data) - [Wearable API integration: comparing SaaS, custom build, and open source](https://openwearables.io/blog/wearable-api-integration-saas-custom-build-open-source) ## Keep reading Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. Releases · Sep 23, 2026 · 13 min read ### Open Wearables 0.9.0: Google split into two providers, energy renamed, and a long list of API corrections Open Wearables 0.9.0 splits Google into google_health and health_connect, renames energy to active_energy, disables the Google Health API rollup that wrote duplicated rows, and fixes date bounds, filters and pagination across the API. Contains breaking changes. Releases · Sep 15, 2026 · 10 min read ### Open Wearables 0.8.0: Withings, sync history, and faster ingestion Open Wearables 0.8.0 adds Withings, database-backed sync history with two new endpoints, a 3.7x faster bulk upsert path, 5 GiB Apple Health XML uploads with MinIO parity, and four account takeover fixes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/open-wearables-0-6-1-data-coverage-observability # Open Wearables 0.6.1: Data coverage & observability [All posts](https://openwearables.io/blog) [Releases](https://openwearables.io/blog/category/releases) Open Wearables Team · Jun 23, 2026 · 3 min read ## Key takeaways - A new Data Coverage tab in the admin panel shows which data types each connected provider supports, with always-up-to-date information. - PULL_SYNC_LOOKBACK adds safeguard functionality for periodic pull syncs using human-readable duration strings. - Webhook logs are now linked to users and traces, including failed delivery attempts. - Sync metadata now distinguishes between inserted and updated records. - Provider-specific fixes across multiple integrations, with nine contributors including three first-time contributors. ## Introduction Version 0.6.1 is released. The release adds a Data Coverage tab to the admin panel and ships observability and logging improvements. It also introduces PULL_SYNC_LOOKBACK as a safeguard for periodic pull syncs, and provider-specific bug fixes. ## Data Coverage tab A new admin panel tab displays supported data for each connected provider, with always-up-to-date information. Everything is available in one place, giving you a full overview of which data types Open Wearables covers for each provider. The tab shows Open Wearables capabilities, not synchronized data status. ## Lookback for pull syncs Although we recommend using webhooks, PULL_SYNC_LOOKBACK is available as a safeguard against data gaps if you need to use periodic pull syncs for any reason. When set, it extends the start of the sync window backwards by the specified duration. This addresses situations where data gaps occur because users haven't opened their wearables app recently. The variable accepts human-readable duration strings: 2d (2 days), 3h (3 hours), 15m (15 minutes). Disabled by default. ## Observability and logging Webhook logs are now linked to users and traces, including failed delivery attempts. Sync metadata now distinguishes inserted from updated records, subdividing items into inserted and updated categories. The application version is now included in Sentry logs. A new "skipped" sync status is added for syncs that complete with no new data to process. ## Provider-specific fixes Suunto: sleep sync statistics are now reported correctly. A webhook edge case in workout handling has been resolved. Garmin: body composition and blood pressure data arriving via webhook now persists correctly. Previously these records were received but not stored. Polar: training load fields now correctly accept float values. A validation error caused Polar's float data to be rejected on ingestion. Whoop: UTC-aware datetime construction has been fixed. Fitbit: date string-to-datetime conversion has been fixed. Webhook delivery: non-retriable webhook responses no longer retry indefinitely. ## Other changes Docker Hub image publishing has been added to the CI/CD workflow. Official images are now published automatically on each release. An ORM object downgrade issue that caused a "this session is in committed state" error has been fixed. ## Upgrading ``` docker compose pull docker compose up -d ``` No breaking changes. Database migrations run automatically on startup. ## Community Nine contributors participated in this release, including three making their first contributions. Full source code, contribution guidelines, and issue tracking are at [github.com/the-momentum/open-wearables](https://github.com/the-momentum/open-wearables). ## Frequently asked questions ### What does the Data Coverage tab show? It shows which data types each connected provider supports within Open Wearables, with real-time updates. It reflects integration capability, not whether a specific user has synced that data. ### Does the lookback variable affect all providers? It applies to providers using periodic pull. ### Will the Garmin body composition fix surface historical records retroactively? No. The fix addresses persistence going forward. ### What does the "skipped" sync status mean? A sync that completed with no new data to process. ### How do I contribute? The GitHub repository at [github.com/the-momentum/open-wearables](https://github.com/the-momentum/open-wearables) contains contribution guidelines. Three new contributors joined with this release. ## See related articles [Open Wearables 0.6.0: Women's Health & FIT Files](https://openwearables.io/blog/open-wearables-0-6-0-womens-health-fit-files) [Open Wearables 0.5.2: Polar Webhooks, Sport Type Expansion, and HRV Score Integrity](https://openwearables.io/blog/open-wearables-0-5-2-polar-webhooks-sport-type-expansion-hrv-score-integrity) [Open Wearables 0.5.1: Oura & Strava Webhooks and Live Sync Status](https://openwearables.io/blog/open-wearables-0-5-1-oura-strava-webhooks-live-sync-status) ## Keep reading Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. Releases · Sep 23, 2026 · 13 min read ### Open Wearables 0.9.0: Google split into two providers, energy renamed, and a long list of API corrections Open Wearables 0.9.0 splits Google into google_health and health_connect, renames energy to active_energy, disables the Google Health API rollup that wrote duplicated rows, and fixes date bounds, filters and pagination across the API. Contains breaking changes. Releases · Sep 15, 2026 · 10 min read ### Open Wearables 0.8.0: Withings, sync history, and faster ingestion Open Wearables 0.8.0 adds Withings, database-backed sync history with two new endpoints, a 3.7x faster bulk upsert path, 5 GiB Apple Health XML uploads with MinIO parity, and four account takeover fixes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/open-wearables-0-6-2-data-integrity # Open Wearables 0.6.2: data integrity for multi-source health apps [All posts](https://openwearables.io/blog) [Releases](https://openwearables.io/blog/category/releases) Open Wearables Team · Jun 30, 2026 · 5 min read Some providers send the same data in more than one format at the same time. Garmin and Oura, for example, each send both a daily total and granular intraday records for the same period. Before 0.6.2, the platform summed all records together, which inflated daily step and energy totals for users on affected providers. Apple Health sends only intraday data and was not affected by this issue. This is the class of problem 0.6.2 addresses. ## What shipped ### is_daily_total: authoritative daily values The data_point_series table has a new is_daily_total boolean column. When a provider sends a daily aggregate alongside granular intraday records for steps or energy, the platform marks the daily record with is_daily_total = true and uses it as the authoritative value. When no daily total exists, the platform sums the intraday records as before. Applications using the summary API get corrected values without any changes on their side. Migration behavior: on the next startup after upgrading, an automated script sets is_daily_total = true for existing daily records. Intraday aggregates are not flagged as false during migration for performance reasons. Any null value in is_daily_total should be treated as equivalent to false. New records written after the upgrade will be handled correctly from the point of ingestion. ### Active minutes as a native series type Active minutes were previously derived from step cadence: any minute with 30 or more steps counted as active. Garmin, Oura, Polar, and Ultrahuman supply active minutes directly from the device. From 0.6.2, Open Wearables retrieves them as a first-class series type from these four providers. For providers that do not report active minutes natively, the 30+ steps/minute fallback remains in place. The platform's science team is working on an improved calculation method, which will be released in a future version. This change applies to new syncs only. Data already stored in the database is not updated automatically. To get correct active minutes for historical data: - Garmin: delete the stored data first, then resynchronize. - Oura, Polar, Ultrahuman: existing records are overwritten during a historical sync. No deletion required. If you surface active time in coaching recommendations, fitness goals, or health summaries, the values will reflect what the device actually recorded rather than a step-cadence approximation, for users on these four providers, going forward. ### Sleep session priority filtering Some devices connect to Open Wearables through more than one path. Oura, for example, can connect directly to Open Wearables and also via Apple Health. When both connections are active, sleep sessions arrive through both paths and produce duplicate records for the same night. The /users/{user_id}/events/sleep endpoint now accepts an optional filter_by_priority flag. When enabled, duplicate sleep sessions are filtered out. The flag is disabled by default, so existing integrations are unaffected unless they explicitly enable it. The filtering option is also available as a toggle in the hosted data summary UI. ### Garmin respiratory rate Garmin respiratory rate was not being saved to the database at all. The platform was searching for the parameter under the wrong field name in Garmin's raw payload. The lookup is now corrected, and respiratory rate will be stored on each sync going forward. Historical data is not available because nothing was stored before this fix. If historical respiratory rate values matter, a resync is needed. ### Data summary: time-based filtering Data summaries now support filtering by a specific day or a custom time period. The visual design has also been updated. ## Bug fixes - [#1114](https://github.com/the-momentum/open-wearables/pull/1114) Apple Health: convert walking units from HealthKit - [#1232](https://github.com/the-momentum/open-wearables/pull/1232) Aggregation fix: take daily data or sum intraday data (Garmin 15-minute chunk conflict) - [#1235](https://github.com/the-momentum/open-wearables/pull/1235) Garmin respiratory rate: fix field name lookup in raw payload - [#1203](https://github.com/the-momentum/open-wearables/pull/1203) Mark connection as revoked on failed token refresh; fire connection.revoked outgoing webhook - [#1242](https://github.com/the-momentum/open-wearables/pull/1242) Active minutes series implementation fixes - [#1249](https://github.com/the-momentum/open-wearables/pull/1249) Sleep session priority filtering implementation fixes ## Additional changes - connection.revoked webhook: a new outgoing webhook event fires when a provider connection is revoked. Applications can update connection state without polling the status endpoint. - Manual invitation links: the connection invitation flow now supports copying the link manually. Useful when email is not configured. Contributed by edsammy in their first contribution to the project. - iOS/Android coverage: the platform now tracks iOS and Android coverage separately. ## Upgrading ``` docker pull ghcr.io/the-momentum/open-wearables:0.6.2 ``` The is_daily_total migration runs on startup. Before deploying, check: 1. If you query data_point_series directly, treat null in is_daily_total as false. 2. If you use the /users/{user_id}/events/sleep events endpoint, decide whether to enable filter_by_priority=true. Summary endpoint users already had sleep deduplication and see no change here. 3. If active minutes matter for your application, plan a resync for Garmin users after upgrading. For Garmin, delete existing data before resyncing. For Oura, Polar, and Ultrahuman, historical sync overwrites the values. New to the platform: ``` git clone https://github.com/the-momentum/open-wearables.git cd open-wearables cp .env.example .env docker-compose up -d ``` Quickstart guide: [docs.openwearables.io/quickstart](https://docs.openwearables.io/quickstart). ## Contributors Six contributors shipped this release. Welcome to edsammy, who contributed for the first time with PR #1230. The project is at 1,997 GitHub stars, 361 forks, and 31 contributors. ## What's next The issue tracker and Discussions reflect what the community needs next. If a data integrity scenario for a specific provider or metric affects your application, open an issue or start a GitHub Discussion. - [GitHub: github.com/the-momentum/open-wearables](https://github.com/the-momentum/open-wearables) - [Release notes: github.com/the-momentum/open-wearables/releases/tag/0.6.2](https://github.com/the-momentum/open-wearables/releases/tag/0.6.2) - [Documentation: docs.openwearables.io](https://docs.openwearables.io) ## Open Wearables Open Wearables is an open-source platform that connects your application to wearable and health data providers through a single API. One normalized data model, multi-provider support in a single self-hosted deployment, no per-user fees, MIT licensed, and health intelligence built in: normalized recovery, sleep, activity and biometric data ready for your product layer. We offer custom deployment and integration support through Momentum. If your team needs help getting to production faster, we can set up and configure Open Wearables as part of a managed engagement. [Let's talk](https://www.themomentum.ai/lets-talk). [Book a demo](https://openwearables.io/book) to see how Open Wearables fits your use case. ## See related articles [Garmin Connect API: developer guide for activities and health metrics](https://openwearables.io/blog/garmin-connect-api-developer-guide-activities-health-metrics) [Oura API: accessing ring data, sleep, HRV and readiness](https://openwearables.io/blog/oura-api-accessing-ring-data-sleep-hrv-readiness) [Apple HealthKit API: what data you can access and how](https://openwearables.io/blog/apple-healthkit-api-what-data-you-can-access-and-how) ## Keep reading Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. Releases · Sep 23, 2026 · 13 min read ### Open Wearables 0.9.0: Google split into two providers, energy renamed, and a long list of API corrections Open Wearables 0.9.0 splits Google into google_health and health_connect, renames energy to active_energy, disables the Google Health API rollup that wrote duplicated rows, and fixes date bounds, filters and pagination across the API. Contains breaking changes. Releases · Sep 15, 2026 · 10 min read ### Open Wearables 0.8.0: Withings, sync history, and faster ingestion Open Wearables 0.8.0 adds Withings, database-backed sync history with two new endpoints, a 3.7x faster bulk upsert path, 5 GiB Apple Health XML uploads with MinIO parity, and four account takeover fixes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/open-wearables-0-6-3-nap-detection-http-logs-middleware # Open Wearables 0.6.3: nap detection and HTTP logs middleware [All posts](https://openwearables.io/blog) [Releases](https://openwearables.io/blog/category/releases) Open Wearables Team · Jul 16, 2026 · 5 min read ## Key takeaways 1. Nap detection is now supported for Apple and Oura. The is_nap field appears on the existing sleep session record with no changes to how you query sleep data. 2. HTTP logs are now structured JSON and controlled via a new ACCESS_LOG_LEVEL variable. Production deployments default to errors-only after this upgrade. 3. Outgoing webhooks were previously always active. Version 0.6.3 introduces OUTGOING_WEBHOOKS_ENABLED, the default is false, so set it to true to keep them running after the upgrade. 4. High-frequency workout sample ingestion is now available for Strava via INGEST_WORKOUT_SAMPLES=true, matching the mechanism introduced for Garmin in 0.6.0. 5. Six new contributors made their first contribution in this release. ## Introduction Version 0.6.3 is released. The main additions are nap detection for Apple and Oura, a structured HTTP logging middleware with configurable log levels, an explicit enable/disable flag for outgoing webhooks, and Strava workout samples. The release also includes provider-specific fixes across Apple, Oura, Suunto, Garmin, and Fitbit. ## Nap detection for Apple and Oura Sleep data is not uniform. A 25-minute afternoon nap and an 8-hour overnight session are both sleep records, but treating them the same way adds noise to any downstream calculation that uses sleep as a signal, recovery scores, sleep debt, readiness metrics. Apple and Oura both include an explicit nap flag in their sleep data. Open Wearables now reads that flag and surfaces it as is_nap on the normalized sleep session record. Your application queries the same sleep endpoints as before, is_nap is an additional boolean field on the record. For providers that do not themselves flag which sleep sessions are naps, we will develop our own detection algorithms in a future release. ## HTTP logs middleware In most Open Wearables deployments, HTTP request logs account for over 80% of total log volume. Until now, those logs were plain-text strings emitted by uvicorn with no structured fields, which made them difficult to filter or query in log aggregation tools. Version 0.6.3 replaces this with a JSON middleware. Each HTTP log entry now includes timestamp, level, message, provider, method, path, status, and duration_ms. A new ACCESS_LOG_LEVEL environment variable controls what gets logged: - ACCESS_LOG_LEVEL=all, all HTTP requests - ACCESS_LOG_LEVEL=errors, 4xx and 5xx only - ACCESS_LOG_LEVEL=off, no HTTP logs If the variable is not set, the level is inferred from ENVIRONMENT: production defaults to errors, everything else defaults to all. If you run with ENVIRONMENT=production and do not set ACCESS_LOG_LEVEL, your deployment will stop logging most HTTP requests after upgrading. Add ACCESS_LOG_LEVEL=all to retain the previous behavior. This change covers uvicorn HTTP logs only. Application-level logs from Open Wearables are not affected. ## Outgoing webhooks enable flag Outgoing webhooks, events that Open Wearables sends to your backend when health data arrives, were previously always active. Version 0.6.3 introduces OUTGOING_WEBHOOKS_ENABLED, which gives you explicit control over this behavior. The default is false. If your deployment relies on outgoing webhooks, set OUTGOING_WEBHOOKS_ENABLED=true before upgrading, otherwise webhook delivery will stop. This flag has no effect on incoming webhooks from providers. Data arriving from Strava, Garmin, or any other provider continues to be ingested regardless of this setting. This release also fixes an event emission issue: the Disconnect button in the Open Wearables frontend was not generating a connection revoked event. This has been fixed. Svix startup logs are now silenced. ## Strava workout samples High-frequency workout sample ingestion was introduced for Garmin in 0.6.0 via the INGEST_WORKOUT_SAMPLES variable. Version 0.6.3 extends that to Strava. When the variable is set to true, Strava will start ingesting workout data at a high frequency. The variable defaults to false because the additional data volume is substantially higher than summary-only ingestion. The full mechanism is described in the "Ingest workout samples" entry for Garmin in the 0.6.0 release notes. ## Provider fixes Apple: Blood glucose values from Health Connect are now converted from mmol/L to mg/dL on ingestion. Oura: Resting heart rate derived from sleep data now persists correctly. Suunto: Float values for totalDistance in the workout schema are now accepted. Garmin: Dead sleep parameters have been removed. Fitbit: Workout distance is now correctly converted from kilometers to meters on ingestion. ## Data coverage tab Women's Health has been added to the Data Coverage tab in the admin panel. The tab shows which data types each connected provider supports within Open Wearables. ## Redis: AOF persistence Redis has been switched from RDB to AOF mode to avoid errors in certain edge cases. Details are in [PR #1188](https://github.com/the-momentum/open-wearables/pull/1188). Existing data stored in Redis is preserved during the upgrade. ## Docker dev image The development Docker image is approximately 40% smaller after tightening the.dockerignore file and removing unused layers from the Dockerfile. This applies only to the local development image. The production build is unchanged. ## Upgrading Official Docker images are available on Docker Hub and are updated on every release: - Backend: [https://hub.docker.com/r/themomentum/open-wearables-backend](https://hub.docker.com/r/themomentum/open-wearables-backend) - Frontend: [https://hub.docker.com/r/themomentum/open-wearables-frontend](https://hub.docker.com/r/themomentum/open-wearables-frontend) ``` docker compose pull docker compose up -d ``` Two environment variables require attention before upgrading: - If ENVIRONMENT=production is set and ACCESS_LOG_LEVEL is not, HTTP logging will default to errors-only after the upgrade. Set ACCESS_LOG_LEVEL=all to retain full logging. - Outgoing webhooks were previously always active. Version 0.6.3 defaults them to false. Set OUTGOING_WEBHOOKS_ENABLED=true to keep them running. All other changes are backward compatible. Database migrations run automatically on startup. ## Community Six contributors made their first contribution in this release. Full source, issue tracker, and contribution guidelines are at [github.com/the-momentum/open-wearables](https://github.com/the-momentum/open-wearables). ## Open Wearables Open Wearables is an open-source platform that connects your application to wearable and health data providers through a single API. One normalized data model, multi-provider support in a single self-hosted deployment, no per-user fees, MIT licensed, and health intelligence built in: normalized recovery, sleep, activity and biometric data ready for your product layer. We offer custom deployment and integration support through Momentum. If your team needs help getting to production faster, we can set up and configure Open Wearables as part of a managed engagement. [Let's talk](https://www.themomentum.ai/lets-talk). [Book a demo](https://openwearables.io/book) to see how Open Wearables fits your use case. ## See related articles [Apple HealthKit API: what data you can access and how](https://openwearables.io/blog/apple-healthkit-api-what-data-you-can-access-and-how) [How to use Oura ring data in your app](https://openwearables.io/blog/how-to-use-oura-ring-data-in-your-app) [How to integrate Strava without building OAuth from scratch](https://openwearables.io/blog/how-to-integrate-strava-without-building-oauth-from-scratch) ## Frequently asked questions ### Which providers support nap detection? Apple and Oura. Both providers include an explicit nap flag in their data. Detection for additional providers will follow in a future release. ### Does OUTGOING_WEBHOOKS_ENABLED affect incoming provider webhooks? No. It only controls events that Open Wearables sends to client backends. Incoming data from providers is unaffected. ### I was using outgoing webhooks before 0.6.3. Do I need to do anything? Yes. Outgoing webhooks were previously always active. Version 0.6.3 defaults them to off. Set OUTGOING_WEBHOOKS_ENABLED=true in your environment before upgrading to retain the previous behavior. ### What is the ACCESS_LOG_LEVEL default? If not set, it is inferred from ENVIRONMENT. Production defaults to errors. All other environments default to all. ### Does the Redis change affect my stored data? No. Existing data is preserved during the upgrade. ## Keep reading Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. Releases · Sep 23, 2026 · 13 min read ### Open Wearables 0.9.0: Google split into two providers, energy renamed, and a long list of API corrections Open Wearables 0.9.0 splits Google into google_health and health_connect, renames energy to active_energy, disables the Google Health API rollup that wrote duplicated rows, and fixes date bounds, filters and pagination across the API. Contains breaking changes. Releases · Sep 15, 2026 · 10 min read ### Open Wearables 0.8.0: Withings, sync history, and faster ingestion Open Wearables 0.8.0 adds Withings, database-backed sync history with two new endpoints, a 3.7x faster bulk upsert path, 5 GiB Apple Health XML uploads with MinIO parity, and four account takeover fixes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/open-wearables-0-7-0-google-health-api-sensorbio # Open Wearables 0.7.0: Google Health API, Sensor Bio, and a faster Admin UI [All posts](https://openwearables.io/blog) [Releases](https://openwearables.io/blog/category/releases) Open Wearables Team · Aug 13, 2026 · 7 min read ## Key takeaways - New: Google Health API integration. OAuth 2.0, aggregates data from every source connected to a user's Google Health account (Fitbit, Google Fit, and more), delivered via polling or notify-only webhooks. - Fitbit integration is now feature-frozen. Google is turning down the legacy Fitbit Web API in September 2026; the Google Health API is the path forward and already surfaces Fitbit as a source. - New: Sensor Bio integration. Workouts, sleep with stages, recovery scores, and continuous 24/7 biometrics via OAuth 2.0 (polling only — Sensor Bio's own API doesn't offer webhooks yet). - Oura sleep stages now sync at 30-second granularity, up from 5-minute. - Admin UI dashboard loads noticeably faster and shows more detail on stored data volume and type. - More data provenance detail: original provider and source device now shown per data point, where available. - New: delete all data for a specific provider from the user profile (auto-disconnects that provider). - New: SDK application management directly in Admin UI Settings. - Logging: a bad row in an SDK sync batch no longer drops the whole batch; more diagnostic fields added to HTTP and Celery worker logs. ## Introduction Open Wearables 0.7.0 is out. This release adds two new provider integrations, Google Health API and Sensor Bio, along with a round of improvements to the Admin UI, data source visibility, and backend logging. ## Google Health API Open Wearables now integrates with the Google Health API, a server-side OAuth 2.0 flow that lets you connect a user's Google account and pull their health data over REST, plus receive notify-only webhooks. Google Health data reaches Open Wearables through two independent paths that share a single google provider identity: - Health Connect (mobile SDK) – data pushed from an Android device via the Sync SDK. - Google Health API (cloud OAuth) – a server-side OAuth 2.0 flow against the Google Health API. These two paths don't feed into each other. The Google Health API doesn't pull data from the Health Connect SDK path; rather, both draw from the same underlying Google Health account, just through different mechanisms. On the cloud OAuth side, the Google Health API acts as an aggregation layer: it surfaces data from every source connected to a user's Google Health account, including Fitbit, Google Fit, and other connected apps, not just one device. Supported data types include steps, distance, calories, hydration, heart rate, resting heart rate, HRV (RMSSD and SDNN), VO₂ max, respiratory rate, SpO₂, weight, body fat, core body temperature, blood glucose, workouts, and sleep with stages. Data delivery works two ways: polling via Celery Beat, and notify-only webhooks where Google sends a lightweight ping naming the changed data type and time interval, and Open Wearables then fetches the changed data over REST. A notable detail is how Open Wearables handles overlapping data from multiple sources. The Health API exposes the same data through three operations, controlled by a DEFAULT_DATA_GRANULARITY setting and, at the finest granularity, a GOOGLE_USE_RECONCILE flag: - Reconcile (default) returns one merged, deduplicated stream across all sources, matching what the native Google Health or Fitbit app displays. Reconciled points carry no device attribution. - List returns raw per-source points tagged with their originating device, preserving device attribution. Open Wearables deduplicates on read by source priority rather than summing values. Reconcile is the default because it produces app-accurate totals: in a documented example where a user's phone and Fitbit MobileTrack both tracked the same day, list-mode dedup would pick a single source (1,919 steps), while reconcile merges the overlap and returns 2,560 steps, matching the native health app exactly. Since Google is deprecating the legacy Fitbit Web API in September 2026, the Google Health API is positioned as its replacement going forward, as it already surfaces Fitbit as one of its aggregated sources. ## Sensor Bio Open Wearables also adds a new integration with Sensor Bio, connected via OAuth 2.0 with pull-based syncing. Sensor Bio's own API does not currently offer webhooks, so this integration is polling-only. Supported data types: - Workouts / activities - Sleep, including stage breakdown (deep, light, REM, awake) - Recovery (score, resting heart rate, HRV, SpO2) - Continuous 24/7 biometric timeseries (heart rate, HRV, SpO2, respiratory rate) - Daily step details (steps, distance, calories) Body measurements are not available via the Sensor Bio API. A few integration-specific quirks documented for this provider: - The continuous biometrics endpoint (/v1/biometrics) uses cursor-based pagination and can return hundreds of timestamped samples per poll window, unlike day-aggregated providers. - Biometric timeseries timestamps are in milliseconds since epoch, while sleep endpoint timestamps are in seconds since epoch. - Sleep and recovery data are fetched one day at a time, since the Sensor Bio API requires a single date parameter rather than supporting a multi-day range. - Sensor Bio does not label naps; sessions are stored with is_nap=false. ## Oura: finer sleep stage granularity Open Wearables now uses Oura's 30-second sleep stage granularity instead of the previous 5-minute granularity, giving more precise sleep stage data for Oura users. ## Admin UI dashboard improvements The Admin UI dashboard has been optimized for faster loading. On less efficient infrastructure, the dashboard could previously take several seconds to load data. Improvements to React and the removal of unnecessary information mean the dashboard should now load instantly, even with large volumes of data and limited RAM. The dashboard also now shows more detail about the volume and type of stored data, and displays large numbers correctly (previously, values in the millions were shown in thousands). ## More detail on data sources On the frontend, each piece of data (workouts, sleep sessions, menstrual cycles, activity) now displays more information. Previously, only the provider from which the data was saved was shown. Now, the original provider is also displayed where applicable (for example, Apple allows data to be synced from devices belonging to other providers), along with the device the data was retrieved from. Open Wearables notes that gaps in this information are expected for now, since fully populating it requires further changes to how data is fetched from sources; this is planned for a future release. ## Delete data by provider The user profile now includes an option to delete data associated with a selected provider. This also automatically disconnects that provider's connection. ## SDK application management in Settings SDK applications can now be managed directly from the Admin UI's Settings section. ## Logging improvements Two changes improve reliability and debuggability of the SDK sync process. Partial batch failures. Previously, a single incorrect row in an SDK sync batch caused the entire batch to be lost. Now, Open Wearables reports the sync status for the problematic rows individually and logs their exact errors to Sentry, so the rest of the batch is no longer discarded. Richer log data. HTTP logs now include additional fields: response_body, request_bytes, error_cause_type, error_cause_msg, content_type, and content_encoding. Celery worker logs for SDK syncs now include fields such as first_error_loc, data_type, success, record_count, task_type, low_power, thermal_state, and types, useful for diagnosing sync issues in production. ## Also in this release - Support for deregistering providers that use a Cloud API. - A fix so that webhook-fetched Oura payloads are correctly stored to raw storage. - Documentation updates: a note on the Fitbit Web API sunset, provider setup guides for Oura and Suunto, clarification of invitation code vs. backend token onboarding flows, and a description of supported providers without a fixed count (the provider list keeps growing). ## Upgrading Official Docker images are available for both backend and frontend: - Backend: themomentum/open-wearables-backend - Frontend: themomentum/open-wearables-frontend See the [0.7.0 release notes](https://github.com/the-momentum/open-wearables/releases/tag/0.7.0) for the full changelog, and the [documentation](https://openwearables.io/docs) for setup guides for Google Health API and Sensor Bio. ## Frequently asked questions ### Does this replace the existing Fitbit integration? Not automatically. The Fitbit integration stays available and supported as-is, but it's feature-frozen: no new data types or features will be added. The Google Health API is the recommended path forward, and it already surfaces Fitbit as one of its aggregated sources. ### Do existing Fitbit connections carry over to the Google Health API automatically? No. Existing Fitbit access and refresh tokens cannot be reused. Each user needs to go through the Google OAuth flow again to reconnect. ### What's the difference between reconcile and list fetch modes for Google Health? reconcile (the default) returns one merged, deduplicated stream across all of a user's connected sources, matching what the native Google Health or Fitbit app shows, but without per-device attribution. list returns raw per-source data points tagged with their originating device, preserving device attribution, and Open Wearables deduplicates on read by source priority. ### Does the Sensor Bio integration support webhooks? No. Sensor Bio's own API doesn't currently offer webhooks, so this integration is polling-only. ### What data can't Sensor Bio provide? Body measurements are not available through the Sensor Bio API. ### How do I upgrade? Pull the official Docker images: themomentum/open-wearables-backend and themomentum/open-wearables-frontend. ## See related articles [Google Health API: A Practical Guide to Getting Started](https://openwearables.io/blog/google-health-api-practical-guide-getting-started) [Google Health API and Google Health Connect: What's the Difference](https://openwearables.io/blog/google-health-api-and-google-health-connect-difference) [Fitbit Web API Shutdown 2026: Migration Guide](https://openwearables.io/blog/fitbit-web-api-shutdown-2026-migration-guide) ## Keep reading Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. Releases · Sep 23, 2026 · 13 min read ### Open Wearables 0.9.0: Google split into two providers, energy renamed, and a long list of API corrections Open Wearables 0.9.0 splits Google into google_health and health_connect, renames energy to active_energy, disables the Google Health API rollup that wrote duplicated rows, and fixes date bounds, filters and pagination across the API. Contains breaking changes. Releases · Sep 15, 2026 · 10 min read ### Open Wearables 0.8.0: Withings, sync history, and faster ingestion Open Wearables 0.8.0 adds Withings, database-backed sync history with two new endpoints, a 3.7x faster bulk upsert path, 5 GiB Apple Health XML uploads with MinIO parity, and four account takeover fixes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/open-wearables-0-8-0-withings-sync-history # Open Wearables 0.8.0: Withings, sync history, and faster ingestion [All posts](https://openwearables.io/blog) [Releases](https://openwearables.io/blog/category/releases) Open Wearables Team · Sep 15, 2026 · 10 min read Open Wearables 0.8.0 is available. This release adds Withings, a `sync_run` tracking table with two new history endpoints, a rewritten bulk upsert path that benchmarks 3.7x faster, 5 GiB Apple Health XML uploads with MinIO parity, four account takeover fixes, and multi-arch Docker images. Two things need attention before you upgrade: a manual migration check if you track `nightly`, and the removal of the Garmin backfill cancel and retry endpoints. Both are covered at the bottom. ## Key Takeaways - **New: Withings integration.** OAuth 2.0, polling the Withings Measure and Sleep APIs by default. Body, activity, sleep, and workouts. Webhooks are optional and created per user, not per application. - **New: `sync_run` and `sync_run_data_type` tables.** One row per data type per run, across provider pulls and pushes, SDK uploads, SDK logs, Apple XML imports, and Garmin backfills. Exposed via `GET /users/{id}/sync/history` and `GET /sync/history/{run_key}`. Historical syncs only and API-only in this release. - **Bulk upsert rewritten** to COPY into a staging table and merge: 3.7x faster on a 50,000-row batch locally, 6.10s down to 1.67s. XML imports moved to a dedicated Celery queue. - **Apple Health XML uploads raised to 5 GiB**, with S3 and MinIO parity. The hard-coded AWS client and SNS dependency are gone, so AWS-free deployments can ingest multi-gigabyte exports. - **Optional SDK payload offload** via `SDK_PAYLOAD_S3_OFFLOAD`: enqueue an S3 reference instead of the body, keeping broker messages at roughly 1 KB. Off by default. - **Four account takeover fixes**, all backwards-compatible: hashed API keys, refresh token revocation on password change, `PATCH /developers/{id}` scoped to the caller, and `garmin-client-id` header verification. - **Workout provenance** (`entry_source`, `intensity`, `label`) from Oura, Strava, Garmin, and Apple. **New series:** Oura intraday MET, previously not stored at all, now parsed into timestamped samples as `physical effort`. - **Multi-arch images** for `linux/amd64` and `linux/arm64` under the same tags. - **Removed:** Garmin backfill cancel and retry endpoints. **Deprecated:** Garmin backfill `GET status`, and Whoop `recovery_score` in the recovery summaries endpoint. ## Withings Withings is now a supported provider. All data categories are available straight away, along with the methods for integrating them: body, activity, sleep, and workouts. The integration introduces new elements to the platform's architecture. Per the provider docs, auth is OAuth 2.0 with comma-separated scopes, and the default sync path polls the Withings Measure and Sleep APIs. Webhook push is optional: subscriptions are created per user with that user's own token rather than once per application, and an application without compliant webhooks is capped by Withings at 10 linked users. The application-wide rate limit is 120 requests per minute. Not supported: sleep stage timeline (hypnogram), ECG, and HRV. ## Sync History Sync completion status was already tracked in Redis, with a 24-hour retention window. This release moves it into the database. Three problems, all specific to historical syncs: - **Redis is not durable.** After 24 hours the record is gone. - **No completion signal on long runs.** The Redis status was written when a sync *started*, not when it finished. A historical sync covering a year of Apple data runs for a long time, and there was no way to distinguish one still in progress from one that died. The table now records when a historical sync ended. - **No resume point after a drop.** When a historical sync broke partway through a large range, nothing recorded how far it had got. The per-data-type rows now show where it stopped, so it can be continued from that range instead of restarted. A new `sync_run` table stores provider, scope, status, timing, item counts, and errors for each run. A companion `sync_run_data_type` table gives one row per data type per run, so a sync that succeeded on sleep and failed on workouts records both outcomes separately instead of an opaque blob. **Live syncs are deliberately not persisted.** The data model supports them, but writing every live sync would flood the table. Historical syncs are the case where durability and resumability matter. A stale sweep closes runs that stopped reporting. It checks Redis for liveness first, so a slow backfill is not cut off prematurely. Tracking covers these ingestion paths: - Provider pulls and pushes - SDK uploads - SDK logs - Apple Health XML imports - Garmin backfills Two endpoints expose the data: ``` GET /users/{id}/sync/history GET /sync/history/{run_key} ``` Use the first to answer "what happened for this user and when," the second to inspect a specific run by key. This is API-only in 0.8.0. The frontend picks it up in its next iteration. ## SDK Uploads Queue a Reference Instead of the Payload Passing the full SDK upload body as a Celery task argument serialized it into the Redis broker queue. Large uploads meant multi-megabyte broker messages. With the new `SDK_PAYLOAD_S3_OFFLOAD` env variable enabled, the sync endpoint enqueues only an S3 reference and the worker loads the body when the task runs. Each broker message stays at roughly 1 KB. The payload was already being written to S3, so this removes a duplicate copy rather than adding a write. **Off by default.** Nothing changes for deployments that leave it that way. ## Bulk Upsert Rewritten The `DataPointSeries` bulk upsert previously issued chunked `INSERT... VALUES` statements carrying an enormous number of bind parameters. A batch is now COPY-ed into a temporary staging table and merged into the target with a single statement. Locally that is a 3.7x speedup on a 50,000-row batch: 6.10s down to 1.67s. XML imports also moved to a dedicated Celery queue, so large Apple exports no longer compete with routine provider syncs for worker capacity. ## Apple Health XML: 5 GiB and MinIO Parity The Apple Health XML upload limit went from 1 GiB to 5 GiB, with a progress dialog on the frontend. The multipart upload flow now works identically against AWS S3 and self-hosted MinIO. Previously the XML path used a hard-coded AWS client and depended on SNS, which MinIO cannot emit. A fully local, AWS-free deployment can now ingest multi-gigabyte Apple exports through the portal. ## Workout Provenance Three providers were already sending per-workout provenance and the platform was discarding it. Workouts now carry three fields: - `entry_source` - `intensity` - `label` Populated by Oura, Strava, Garmin, and Apple. These let you tell a measured workout from a manually entered one, and see the name the user gave it. ## Oura Intraday MET **This is a new series, not a granularity change.** Oura MET was not stored at all before this release, so nothing you already have is affected and there is no daily-to-intraday conversion. Oura sends an intraday MET (metabolic equivalent of task) series alongside daily activity. It is now parsed into individual timestamped samples at the provider's own interval and stored as `physical effort`, giving a continuous picture of movement intensity across the day. Oura is the only provider exposing MET at this granularity today, so this is currently Oura-only. Also in this release: the invalid `activity` OAuth scope has been removed from the Oura defaults. Parsed Oura MET data is exposed through the workouts API. ## Security Four ways to take over an account or a deployment are now closed. All fixes are backwards-compatible. **API keys are stored hashed.** The raw value is shown only once, on create or rotate. The migration hashes existing keys in place, so current integrations keep working. **Changing a password revokes every refresh token** the developer holds. Refresh tokens have no expiry, so a leaked token previously worked forever. **`PATCH /developers/{id}` is restricted to the caller's own account.** Before, any team member could set another developer's password. **Garmin webhooks compare the `garmin-client-id` header** against the configured value, instead of just checking that it is present. A `SECURITY.md` vulnerability reporting policy has been added to the repo. ## Multi-Arch Docker Images Backend and frontend images now publish for both `linux/amd64` and `linux/arm64` under the same tags as before. They are built via native arm64 runners. Recommended images: - `themomentum/open-wearables-backend` - `themomentum/open-wearables-frontend` Tag scheme: - `latest`: newest stable image - `0.8.0`, `0.8`: pinned stable release - `nightly`: unstable, rebuilt nightly from main ## Provider Fixes **Suunto:** pause-aware `stopTime` and gear from `SummaryExtension`; missing sleep windows recovered safely; awake time fetching implemented; SpO2Max and AvgHRV extracted from sleep. **Whoop:** `/v2/cycle` endpoint support added; HRV split into RMSSD and SDNN with `recovery_score` deprecated in the recovery summaries endpoint; recovery endpoint fixed and `cycle_id` resolved for `recovery.updated`; workout type mappings updated and additional sport names mapped. **Ultrahuman:** real synced item counts now reported; skin temperature stored under the `skin_temperature` series; granular sleep stages parsed from `sleep_graph`. **Garmin:** webhook `garmin-client-id` verification; backfill GC task, cancel and retry endpoints removed. ## Other Changes **Token refresh race condition** resolved using a distributed lock. **SDK connections:** `connection.created` and `connection.revoked` events are now emitted. SDK tokens can disconnect their own connections. "Sync SDK" is renamed to "Mobile SDK." **Outgoing webhooks:** `connection.created` and `connection.revoked` emitted; sleep data delivery unified between API and webhook; webhook sent after seeding sleep data; webhook event filters can now be removed. **Scores:** duplicate sleep score calculation prevented. **MCP:** `get_menstrual_cycles` tool added. FastMCP upgraded from 2 to 3. **Admin panel:** metric descriptions with tooltip hints on the coverage matrix; responsive sidebar on mobile; Tanstack menu position fixed; "Device info not available" label cleared when the source has no device details. **Platform:** DB connection released before the SSE stream starts; `GET /users` improved; `handle_duplicates` decorator removed from `event_record_detail_service`; old data migrations removed from startup; migration chain guarded against re-pointed migrations; admin seed clarified to run only on an empty developer table. **Docs:** production compose setup replaced with a Docker deployment guide; provider and webhook docs refreshed; Historical Data Availability page added for providers; developer portal settings and access model documented; structured logging documented as the backend default; Samsung Health production requirements documented; data migrations moved to Developer Guides; contributing guidelines and PR template rewritten. ## Deprecations and Removals **Removed:** Garmin backfill cancel and retry endpoints. Garmin allows one request per timeframe per type and answers 409 afterwards, so retry could never do anything useful. The periodic GC task is gone too: it accounted for roughly 15% of worker log lines and in practice never cleared anything, since the per-type timeout and the lock TTL already cover those cases. **Deprecated:** Garmin backfill `GET status`. Stop using it; it will be removed in a future release. **Deprecated:** Whoop `recovery_score` in the recovery summaries endpoint, superseded by the RMSSD and SDNN split. ## Upgrading ``` docker compose pull docker compose up -d ``` Migrations run automatically on startup. **Nightly users, read this.** If you updated between 2026-09-07T17:46:43Z and 2026-09-08T14:55:55Z, you may have pulled a version containing a faulty migration. Check whether your `workout_details` table has the `entry_source`, `intensity`, and `label` columns. If not, add them manually: ``` ALTER TABLE workout_details ADD COLUMN IF NOT EXISTS entry_source VARCHAR(32), ADD COLUMN IF NOT EXISTS intensity VARCHAR(10), ADD COLUMN IF NOT EXISTS label VARCHAR(255); ``` API keys are hashed by a migration that runs in place, so existing integrations keep working without action. From this release onward, a newly created or rotated key is shown once and cannot be read back afterwards. Full changelog: [github.com/the-momentum/open-wearables/releases/tag/0.8.0](https://github.com/the-momentum/open-wearables/releases/tag/0.8.0) ## Frequently Asked Questions ### Do I need to do anything about the hashed API keys before upgrading? No. The migration hashes existing keys in place, so current integrations keep working. The change applies going forward: a key created or rotated after this release is displayed once and cannot be read back afterwards. ### Why is my Withings integration capped at 10 users? That cap comes from Withings, not Open Wearables. Withings creates notification subscriptions per user rather than once per application, and applications without compliant webhooks are limited to 10 linked users. Webhook endpoints must use HTTPS on a public hostname, ports 80 or 443 only. The default sync path polls the Measure and Sleep APIs, so polling works without the webhook setup. ### Does Withings give me sleep stages and HRV? Sleep totals yes, including duration, efficiency, and deep, light, REM and awake totals. The sleep stage timeline (hypnogram) is not supported, and neither are ECG or HRV. ### Should I turn on `SDK_PAYLOAD_S3_OFFLOAD`? Only if SDK upload volume is putting pressure on your Redis broker. It is off by default and nothing changes for deployments that leave it that way. The payload was already being written to S3, so enabling it removes a duplicate copy rather than adding a write. ### Where do I see sync history in the UI? Nowhere yet. 0.8.0 exposes it through the API only. The frontend picks it up in its next iteration. ### I used the Garmin backfill retry endpoint. What replaces it? Nothing, and nothing needs to. Garmin allows one backfill request per timeframe per type and answers 409 afterwards, so retry could never do anything useful. The per-type timeout and lock TTL cover the cases the removed controls were handling. `GET status` still works but is deprecated. ### Is the 3.7x ingestion speedup something I need to configure? No. The bulk upsert rewrite applies automatically. The dedicated Celery queue for XML imports is part of the same change. ### My Whoop integration reads `recovery_score`. Is it gone? Not gone, deprecated in the recovery summaries endpoint. HRV is now split into RMSSD and SDNN as distinct metrics, and those are what to build on going forward. Questions or feedback? Open an issue on GitHub or join the Discord community. ## Keep reading Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. Releases · Sep 23, 2026 · 13 min read ### Open Wearables 0.9.0: Google split into two providers, energy renamed, and a long list of API corrections Open Wearables 0.9.0 splits Google into google_health and health_connect, renames energy to active_energy, disables the Google Health API rollup that wrote duplicated rows, and fixes date bounds, filters and pagination across the API. Contains breaking changes. Releases · Aug 13, 2026 · 7 min read ### Open Wearables 0.7.0: Google Health API, Sensor Bio, and a faster Admin UI Open Wearables 0.7.0 adds a Google Health API integration ahead of the Fitbit Web API sunset, a new Sensor Bio provider, finer Oura sleep granularity, and Admin UI and logging improvements. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/open-wearables-0-9-0-google-split-active-energy # Open Wearables 0.9.0: Google split into two providers, energy renamed, and a long list of API corrections [All posts](https://openwearables.io/blog) [Releases](https://openwearables.io/blog/category/releases) Open Wearables Team · Sep 23, 2026 · 13 min read Open Wearables 0.9.0 is available. It splits the Google integration into two providers, renames the `energy` series to `active_energy`, disables the Google Health API rollup that was writing duplicated rows, and fixes a long list of API inconsistencies around date bounds, filters, and pagination. ## Key takeaways - Three new Google Health API series: RMSSD heart rate variability, VO2 max, and oxygen saturation - Zero-valued samples are no longer stored, so averages stop being dragged toward zero - `resolution` on `/timeseries` now aggregates into buckets instead of being ignored - Source filters on `/timeseries` reach the query, plus optional priority selection per series type - Workouts expose heart rate and power zones and segments on request; sleep exposes stage intervals the same way - Sleep sessions carry a new time-in-bed figure taken from the provider rather than inferred - Two optional settings: `PROVIDER_REQUEST_TIMEOUT_SECONDS` and `LINKED_SYNC_PULL_LEASE_SECONDS`, both with defaults that preserve current behaviour - Maximum page size across paginated endpoints is now 1000 ## Breaking changes **Breaking changes in 0.9.0.** Read this list before upgrading. - **Google is now two providers.** `google` is replaced by `google_health` (cloud OAuth, Google Health API) and `health_connect` (Android SDK). Outgoing webhooks carry the new slugs in `source.provider`, `connection.created` / `connection.revoked` and sync events, so anything filtering on `provider == "google"` stops matching. A data migration runs automatically on startup. - `energy` **is renamed to** `active_energy` in every response body, and the granular webhook event `series.energy.created` becomes `series.active_energy.created`. Requests still accept `types=energy` until 1.0. Webhook subscribers need the migration script below. - **Google Health API rollup is disabled.** A provider with `data_granularity` set to anything other than `raw` now fails those data types with `UnsupportedGranularityError` instead of writing duplicated, inflated rows. - **Existing Google Health API energy data is wrong** and has to be purged with an optional script, then re-synced. - **Date-only** `end_date` **/** `end_time` **now includes the whole end day.** If you compensated by passing the next day, you will get one extra day back. - `/events/sleep` **no longer returns** `sleep_stage_intervals` **by default.** Pass `?include=stages`. Unreported stages are now `null` instead of `0`. - `/timeseries` **returns** `total_count: null` **on cursor pages** and on every aggregated (`resolution!= raw`) read. - `resolution` **on** `/timeseries` **is no longer ignored.** Requests that passed it and silently got raw samples now get aggregated buckets. ## Google Health and Health Connect are now two providers `google` covered two unrelated integrations under one slug. The cloud integration, with its server-side OAuth, REST pulls and notify-only webhooks, becomes `google_health`. Health Connect data uploaded through the mobile SDK becomes `health_connect`. Both appear separately in a user's connections and work as filter values under their own names. ### What keeps working Webhooks already registered against the `/google/` path still deliver, since that path is aliased to the cloud provider; new registrations use `/google_health/`. Existing connections with periodic sync keep running. The mobile SDK still sends `google` in its payload body, and that alias is permanent rather than a migration window, so deployed app versions do not break. ### What breaks Outgoing webhooks now send `google_health` or `health_connect` in the provider field, across connection events, data event sources, and sync events. There is no alias here, because telling the two apart is the entire point of the split. The alias covers the webhook path only. Passing `provider=google` as a data filter, or calling a sync route under the old slug, is rejected with a 400 naming `google_health` rather than silently resolving to one half of the split. Raw payload storage in S3 also splits into two paths, which matters only if you read raw payloads for debugging. ### The OAuth path and `GOOGLE_LEGACY_OAUTH_PATH` The OAuth redirect URI must match what is registered in Google Cloud, so the path sits behind a flag: ``` GOOGLE_LEGACY_OAUTH_PATH=true # default, sends the old /api/v1/oauth/google/callback GOOGLE_LEGACY_OAUTH_PATH=false # sends /api/v1/oauth/google_health/callback ``` Existing deployments need no change: the default keeps your registered client working, and both inbound paths are served either way. New integrations should register the `google_health` callback in Google Cloud and set the flag to false; Google accepts several redirect URIs, so both can coexist. The legacy path and the flag are removed in 1.0. ## Google Health API data corrections ### Rollup is disabled The windowed rollUp operation anchors its buckets to the requested range start rather than a fixed wall-clock grid, so the same hour requested from two different starting points comes back stamped at two different timestamps. Every lookback and every manual sync wrote another copy. It is now off. With the default `data_granularity = raw` nothing changes. Set to `hourly` or `daily`, the affected types are skipped, the run is marked partial, and this lands in the logs and in Sentry: ``` UnsupportedGranularityError Google Health data_granularity 'hourly' needs the windowed rollUp operation, which is disabled (#1577). Its data types were skipped; set the provider's granularity to 'raw' to resume them. Sleep and derived daily totals are unaffected. ``` If your Google settings have `data_granularity` set to anything other than `raw`, change it back before upgrading. Sleep sessions and derived daily totals sync either way. ### Active and basal energy Total calories used to be written into the `energy` series, which means active energy, so values were inflated by basal metabolic rate and multiplied by repeated syncs over the same window. Active energy now comes from the native active-energy-burned intervals and is tagged with an external id so it can be identified later. Basal energy is derived per civil day as total calories minus active energy, and stored as a daily total. ### Migration: purge the bad energy rows (optional, manual) Run once after deploying and before any historical re-sync. It deletes untagged legacy rows in the live table, plus every archived Google Health API energy bucket, since the archive carries no per-row marker. ``` uv run python scripts/data_migrations/purge_google_total_calories_energy.py --dry-run uv run python scripts/data_migrations/purge_google_total_calories_energy.py ``` The `--batch` flag defaults to 50000 and commits per batch, so no single transaction holds locks; add `--skip-archive` if archival already ran over re-synced data. It is not wired into startup, because it removes data only a re-sync can bring back. ### New data types and other fixes Three series previously not stored at all are now ingested: RMSSD heart rate variability, VO2 max, and oxygen saturation, the first and last from Google's daily endpoints. Webhook subscriptions should include those two daily types. Zero-valued samples are no longer stored, so HRV and saturation averages stop being pulled toward zero. Daily series are now written without the daily-total flag, in line with every other provider, so they appear in bucketed reads; rows written before this release keep the old flag and stay excluded. Live pulls import overnight sleep sessions matched on session end rather than start, plus the previous day's totals, so the first pull may bring one extra night and day. Each data type commits on its own, and a malformed page from Google fails that metric and marks the run partial instead of reporting success on an empty window. ### Sync reliability and new settings Two optional settings become configurable, both with defaults that preserve current behaviour: `PROVIDER_REQUEST_TIMEOUT_SECONDS` (30) for the per-request provider timeout, previously hard coded, and `LINKED_SYNC_PULL_LEASE_SECONDS` (120) for the linked-account pull lock, renewed while the sync runs. That lock now expires around two minutes after its holder dies rather than up to four hours, so clearing it by hand after a worker restart is no longer necessary. The Garmin backfill lock keeps its four hour lifetime. A linked-account pull that finds another profile already syncing the same account records a run marked skipped instead of reporting success, and does not advance the last-synced timestamp, so the primary sync still covers the full gap. ## `energy` is now `active_energy` `energy` sat next to `basal_energy` and looked like the total. It was active energy only, so it is renamed. The rename applies throughout: the series type name in the database updates itself via the existing startup seed, and the stored series id is unchanged, so no data moves. Requests keep a `types=energy` alias until 1.0, but it is not recommended and you should migrate off it. The breaking part is responses. Anything matching the literal string `energy` in a response body breaks: the type field on time series reads, the keys in the data summary and timeline, and the code in the coverage endpoint. The granular webhook event is renamed alongside it. The group event covering calories is unchanged, so broad subscriptions keep receiving active energy whether or not you run the migration. ### Migration: webhook subscriptions (optional, manual, two phases) A Svix endpoint filters on event-type names, so a subscription to the old event survives the rename intact and simply stops matching. No error on either side, just silence. Note that the release notes place both phases after the deploy, while the script's own documentation places the first phase before it, so that no window exists where the dispatched name is missing from a subscriber's filter. The script only patches endpoint filters; the event type itself is registered with Svix at application startup. If your Svix instance rejects a filter naming an unregistered event type, run the first phase after the deploy, otherwise before. Either way, run the second phase afterwards. ``` uv run python scripts/data_migrations/rename_energy_webhook_event.py --phase=add --dry-run uv run python scripts/data_migrations/rename_energy_webhook_event.py --phase=add uv run python scripts/data_migrations/rename_energy_webhook_event.py --phase=remove ``` The add phase only appends; the remove phase refuses to empty a filter list rather than turning that endpoint into a firehose. Only one event name is ever dispatched, so nobody receives duplicates while both sit on an endpoint, `--sleep` throttles against Svix rate limits, and the whole thing is idempotent. If you manage Svix endpoints from your own infrastructure-as-code, rename the filter there instead, since a redeploy would undo the patch. ## API corrections and new filters ### Date-only end bounds now include the whole day A bare `end_date` or `end_time` resolves to the start of the next day, so the end day is included. Asking for a single day by passing the same date twice previously returned nothing; now it returns that day. An explicit midnight timestamp still stops at midnight, for anyone who wants an exclusive bound. This applies across events, summaries, the data timeline, time series and health scores, the last of which also stops returning a server error when start and end are equal. Bucketed time series reads accept date-only bounds too, which also used to fail. ### `resolution` on `/timeseries` now works `resolution` was accepted and silently ignored, and the endpoint always returned raw samples. Buckets are now aggregated in the database per bucket, data source and series type: averaged for rates such as heart rate, summed for counters such as steps, so four samples of fifteen steps within one minute return sixty rather than fifteen. Valid values are `raw`, `1min`, `5min`, `15min` and `1hour`; anything else returns a 400. Cursors carry the bucket start, so a bucket is never split across pages. Aggregated reads exclude rows flagged as daily totals, since bucketing a whole day's total inside one minute would be wrong; per-day aggregation stays in the summaries endpoints. The resolution field in response metadata is now populated, where it was always null before. ### Source filters and priority selection Provider, source, device model and data source id now all reach the query. Data source id was declared in the API but applied nowhere, so it silently returned every source, which is worse than an error. The filters narrow the query itself, so the total count reflects them, and they compose with `resolution`. Data source id never widens past the user check: another user's source returns an empty list. Priority selection, off by default and matching how sleep already behaves, keeps a single data source per series type using the same ranking sleep sessions use, so a user wearing both a watch and a band no longer produces a sawtooth between two calibrations. Selection runs per series type, so a watch that outranks a band still loses on the one series only the band records. ### Pagination totals are computed once Reading time series ran a full count over the largest table in the system on every page, always returning the same number. It is now taken on the first page only and comes back null on cursor pages and aggregated reads, so hold the first value client side. ### Sleep stage intervals are opt-in The interval timeline is no longer returned by default. Pass `include=stages` to get it, the same way workouts expose zones and segments. More consequentially, stages a provider does not measure now come back as null rather than zero. A device that does not track deep sleep used to read as zero minutes of deep sleep, which is a different claim entirely, and anything built on top inherited that error. Sleep sessions also carry a new time-in-bed figure taken from the provider rather than inferred, and the four source filters work on sleep and menstrual cycle events too. ### Workouts: zones, segments and filters Workouts expose heart rate and power zones on request, each carrying per-zone durations plus the thresholds they were computed against, and segments the same way. Two filters distinguish a broad from an exact match: `record_type=running` also returns trail running, while `type=running` returns running only. Filtering by provider is available too. ### Data timeline: provider filter and workout heatmap Grouping the timeline by workout type adds a second heatmap. Workouts and data points share a table, so a metric field distinguishes the two without changing the response shape; sleep sessions are excluded, and a workout counts in the bucket it started in. A provider filter is now available and applies to the archive query too. ### Auth, status codes and limits Deleting and updating a user now accept an API key as well as a developer token: the same key that creates a user could not delete it, which broke the usual flow of removing a user on both sides at once. Both connection deletion endpoints now declare a 204 in OpenAPI, matching wire behaviour that was already 204. Maximum page size is 1000 across paginated endpoints, sleep summaries included. ## Dashboard The sleep and workout summary widgets on the user profile read one page and ignored the cursor, so any range with more than a hundred items showed wrong totals with no hint of truncation: on the year-long range, nights tracked read 100 for a window holding 353 nights. They now fetch every item they aggregate. ## Other changes Shared SDK ingestion moved out of the Apple namespace, and an MCP HTTP transport with bearer and OAuth auth was added and then reverted within this release. On the documentation side: the quick reference table was removed from the API introduction, the public roadmap refreshed, Withings plan limits documented, official release images recommended for production in the README, and GitHub issue templates added. Svix was upgraded to v2 alongside the usual dependency bumps. ## Upgrading ``` docker compose pull docker compose up -d ``` Migrations run automatically on startup, including the Google provider split. Before you upgrade, check whether your Google settings have `data_granularity` set to anything other than `raw`, and change it back if so. After you deploy: update any webhook consumer filtering on the old `google` value; run the energy purge script before any historical re-sync if you ingested Google Health API energy data; run the two-phase webhook rename if you subscribe to the granular energy event; and check clients that worked around exclusive end bounds, read sleep stage intervals by default, or relied on a total count past the first page. Full changelog: [github.com/the-momentum/open-wearables/releases/tag/0.9.0](https://github.com/the-momentum/open-wearables/releases/tag/0.9.0) ## Frequently asked questions ### Do my existing Google connections stop working after the split? No. Connections with periodic sync keep running, webhooks registered against the old path still deliver, and the mobile SDK can keep sending `google` because that alias is permanent. What breaks is outgoing webhooks, which now carry `google_health` or `health_connect` with no alias. ### Do I have to run the energy purge script? Only if you ingested Google Health API energy data before this release, in which case those values are inflated by basal metabolic rate and multiplied by repeated syncs. It is optional and manual, deliberately not wired into startup, because it removes data only a re-sync can bring back. ### My integration reads `energy` in responses. Does it break? Yes. Responses are the breaking part: time series reads, the data summary, the timeline and the coverage endpoint all return `active_energy` now. Requests keep a `types=energy` alias until 1.0, but it is not recommended, so treat it as time to migrate rather than a setting to rely on. The series type name in the database updates itself on startup, and the series id is unchanged, so no data moves. ### Why is my Google Health API sync reporting partial after upgrading? Because `data_granularity` is set to something other than `raw`. The rollUp operation those types needed is disabled, so they are skipped and the run is marked partial, with `UnsupportedGranularityError` in the logs. Set granularity back to `raw` to resume them. Questions or feedback? Open an issue on GitHub or join the Discord community. ## Open Wearables Open Wearables is an open-source platform that connects your application to wearable and health data providers through a single API. One normalized data model, multi-provider support in a single self-hosted deployment, no per-user fees, MIT licensed, and health intelligence built in: normalized recovery, sleep, activity and biometric data ready for your product layer. We offer custom deployment and integration support through Momentum. If your team needs help getting to production faster, we can set up and configure Open Wearables as part of a managed engagement. [Let's talk](https://www.themomentum.ai/lets-talk). [Book a demo](https://openwearables.io/book) to see how Open Wearables fits your use case. ## See related articles [Open Wearables 0.8.0: Withings, sync history, and faster ingestion](https://openwearables.io/blog/open-wearables-0-8-0-withings-sync-history) [Open Wearables 0.7.0: Google Health API, Sensor Bio, and a faster Admin UI](https://openwearables.io/blog/open-wearables-0-7-0-google-health-api-sensorbio) [Google Health Connect integration for Android developers](https://openwearables.io/blog/google-health-connect-integration-android-developers) ## Keep reading Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. Releases · Sep 15, 2026 · 10 min read ### Open Wearables 0.8.0: Withings, sync history, and faster ingestion Open Wearables 0.8.0 adds Withings, database-backed sync history with two new endpoints, a 3.7x faster bulk upsert path, 5 GiB Apple Health XML uploads with MinIO parity, and four account takeover fixes. Releases · Aug 13, 2026 · 7 min read ### Open Wearables 0.7.0: Google Health API, Sensor Bio, and a faster Admin UI Open Wearables 0.7.0 adds a Google Health API integration ahead of the Fitbit Web API sunset, a new Sensor Bio provider, finer Oura sleep granularity, and Admin UI and logging improvements. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/open-wearables-release-0-1-workout-data-oauth-developer-portal # Open Wearables Release 0.1: Workout Data, OAuth, Developer Portal [All posts](https://openwearables.io/blog) [Releases](https://openwearables.io/blog/category/releases) Open Wearables Team · Dec 10, 2025 · 1 min read ## Key takeaways - First public release. Covers workout data from Garmin, Suunto, and Polar through a unified data model. - OAuth flows are built in per provider. No custom auth logic needed. - Developer portal for user management, auth link generation, and data inspection. - Seed script (make init) for local dev without real device connections. Open Wearables 0.1 is available on GitHub. ## What's in 0.1 Workout data from Garmin, Suunto, and Polar. Each provider uses a different data format. The platform normalizes everything into one schema before it hits your API. You query workout metrics the same way regardless of the source device. OAuth is handled per provider. Users authenticate with their wearable accounts through built-in flows. You don't write OAuth logic for each provider. ## Developer portal Web interface for managing the platform: add users, generate authentication links, preview incoming workout data, manage API credentials. Interactive API docs are included, so you can test endpoints and inspect response shapes without writing code first. ## Local development Docs at [docs.openwearables.io](https://docs.openwearables.io). Run **make init** to seed the database with sample workout data for development without real device connections. ## What's next 0.2 adds Sleep, Workouts, and Timeseries endpoints (59 data types). [GitHub](https://github.com/the-momentum/open-wearables) | [Docs](https://docs.openwearables.io) | [Discord](https://discord.gg/openwearables) Want to see it in action? [Book a demo](https://openwearables.io/book) ## Keep reading Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. Releases · Sep 23, 2026 · 13 min read ### Open Wearables 0.9.0: Google split into two providers, energy renamed, and a long list of API corrections Open Wearables 0.9.0 splits Google into google_health and health_connect, renames energy to active_energy, disables the Google Health API rollup that wrote duplicated rows, and fixes date bounds, filters and pagination across the API. Contains breaking changes. Releases · Sep 15, 2026 · 10 min read ### Open Wearables 0.8.0: Withings, sync history, and faster ingestion Open Wearables 0.8.0 adds Withings, database-backed sync history with two new endpoints, a 3.7x faster bulk upsert path, 5 GiB Apple Health XML uploads with MinIO parity, and four account takeover fixes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/open-wearables-release-0-2-1-whoop-mobile-sdk-authentication # Open Wearables Release 0.2.1: Whoop, Mobile SDK Authentication [All posts](https://openwearables.io/blog) [Releases](https://openwearables.io/blog/category/releases) Open Wearables Team · Jan 8, 2026 · 1 min read ## Key takeaways - Whoop is now the fourth supported provider, alongside Garmin, Polar, and Suunto. Sleep and workout data included. - User-scoped SDK tokens let mobile apps connect users directly to their wearables without routing through your backend for every request. - Sleep summaries endpoint aggregates daily sleep data across all connected providers into a single response. - Apple Health Flutter SDK enters final testing. Backend E2E integration guide is live. Open Wearables 0.2.1 is available on GitHub. ## Whoop integration Whoop joins Garmin, Polar, and Suunto as the fourth supported provider. The integration covers recovery scores, strain metrics, sleep stages, and workout data. Everything flows through the same normalized API structure as existing providers. ## User-scoped SDK tokens Mobile apps can now generate individual tokens per user. The SDK uses these tokens to connect directly to wearable accounts without requiring a server round-trip for each operation. Necessary for background sync and offline scenarios. ## Sleep summaries New endpoint that returns consolidated daily sleep metrics across all connected devices: total sleep time, efficiency scores, sleep stage breakdown (REM, deep, light). One query, all providers, consistent format. ## What's next 0.2.2 fixes critical sync issues across Apple Health, Whoop, and Suunto for production stability. [GitHub](https://github.com/the-momentum/open-wearables) | [Docs](https://docs.openwearables.io) | [Discord](https://discord.gg/openwearables) Want to see it in action? [Book a demo](https://openwearables.io/book) ## Keep reading Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. Releases · Sep 23, 2026 · 13 min read ### Open Wearables 0.9.0: Google split into two providers, energy renamed, and a long list of API corrections Open Wearables 0.9.0 splits Google into google_health and health_connect, renames energy to active_energy, disables the Google Health API rollup that wrote duplicated rows, and fixes date bounds, filters and pagination across the API. Contains breaking changes. Releases · Sep 15, 2026 · 10 min read ### Open Wearables 0.8.0: Withings, sync history, and faster ingestion Open Wearables 0.8.0 adds Withings, database-backed sync history with two new endpoints, a 3.7x faster bulk upsert path, 5 GiB Apple Health XML uploads with MinIO parity, and four account takeover fixes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/open-wearables-release-0-2-2-production-stability-extended-provider-support # Open Wearables Release 0.2.2: Production Stability, Extended Provider Support [All posts](https://openwearables.io/blog) [Releases](https://openwearables.io/blog/category/releases) Open Wearables Team · Jan 12, 2026 · 1 min read ## Key takeaways - Critical sync issues fixed across Apple Health, Whoop, and Suunto. Platform is now stable for production deployments. - Apple Health SDK fully operational: workouts and data points sync without manual intervention. XML import supported. - Whoop OAuth scopes fixed for automatic token refresh. Async sync issues resolved. - Sleep Summary endpoint returns daily aggregations across all providers. N+1 query bottlenecks eliminated in workout endpoints. Open Wearables 0.2.2 is available on GitHub. ## Apple Health SDK Sync now handles workouts and data points without manual intervention. XML import uses the same scope as SDK sync. An AWS setup guide covers production deployment for XML import: S3 bucket configuration, Lambda processing, and IAM permissions. ## Whoop stability OAuth scopes fixed to include offline access, enabling automatic token refresh without user re-authentication. Async sync issues that caused inconsistent data delivery are resolved. Whoop workout and sleep data is now fully reliable. ## Garmin defaults API requests without a date range now default to the last 24 hours instead of returning empty responses. A complete Garmin Developer Program setup guide is included in the docs. ## Sleep Summary endpoint Daily sleep aggregations across all connected providers. Returns consolidated metrics ready for dashboard use: total sleep time, efficiency, stage breakdown. Reduces API calls for analytics-focused use cases. ## API performance N+1 query bottlenecks eliminated in workout endpoints. Relevant for applications querying large datasets across many users. ## What's next 0.3 alpha ships the Flutter SDK for Apple Health and the MCP Server for LLM integration. [GitHub](https://github.com/the-momentum/open-wearables) | [Docs](https://docs.openwearables.io) | [Discord](https://discord.gg/openwearables) Want to see it in action? [Book a demo](https://openwearables.io/book) ## Keep reading Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. Releases · Sep 23, 2026 · 13 min read ### Open Wearables 0.9.0: Google split into two providers, energy renamed, and a long list of API corrections Open Wearables 0.9.0 splits Google into google_health and health_connect, renames energy to active_energy, disables the Google Health API rollup that wrote duplicated rows, and fixes date bounds, filters and pagination across the API. Contains breaking changes. Releases · Sep 15, 2026 · 10 min read ### Open Wearables 0.8.0: Withings, sync history, and faster ingestion Open Wearables 0.8.0 adds Withings, database-backed sync history with two new endpoints, a 3.7x faster bulk upsert path, 5 GiB Apple Health XML uploads with MinIO parity, and four account takeover fixes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/open-wearables-release-0-2-sleep-workouts-timeseries # Open Wearables Release 0.2: Sleep, Workouts, Timeseries [All posts](https://openwearables.io/blog) [Releases](https://openwearables.io/blog/category/releases) Open Wearables Team · Dec 22, 2025 · 1 min read ## Key takeaways - Three new endpoints: Timeseries (59 data types), Workouts, and Sleep. - 870 tests, 80% code coverage across 5,129 lines. Test suite runs in 26 seconds. - AI agent configuration rules added for Cursor, Copilot, and similar tools. Open Wearables 0.2 is available on GitHub. ## New endpoints Timeseries handles 59 data types: heart rate variability, blood oxygen, stress, and more. The full list is in the documentation. Use make init to seed realistic data locally before connecting real devices. Workouts cover duration, calories, GPS tracks, cadence, and power zones. Sleep provides the full breakdown: REM cycles, sleep efficiency, time in bed vs. actual sleep time. The data structure matches what Apple Health and Garmin export. ## Test coverage 870 tests with 80% code coverage across 5,129 lines of code. The suite runs in 26 seconds, making it practical for development workflows. All endpoints are covered. ## AI agent configuration Universal configuration rules for AI coding agents (Cursor, Copilot, etc.) are now included in the repo. Drop them into your project to give your coding assistant accurate context about Open Wearables API structure. ## What's next 0.2.1 adds Whoop as the fourth provider and SDK user-scoped authentication for mobile apps. [GitHub](https://github.com/the-momentum/open-wearables) | [Docs](https://docs.openwearables.io) | [Discord](https://discord.gg/openwearables) Want to see it in action? [Book a demo](https://openwearables.io/book) ## Keep reading Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. Releases · Sep 23, 2026 · 13 min read ### Open Wearables 0.9.0: Google split into two providers, energy renamed, and a long list of API corrections Open Wearables 0.9.0 splits Google into google_health and health_connect, renames energy to active_energy, disables the Google Health API rollup that wrote duplicated rows, and fixes date bounds, filters and pagination across the API. Contains breaking changes. Releases · Sep 15, 2026 · 10 min read ### Open Wearables 0.8.0: Withings, sync history, and faster ingestion Open Wearables 0.8.0 adds Withings, database-backed sync history with two new endpoints, a 3.7x faster bulk upsert path, 5 GiB Apple Health XML uploads with MinIO parity, and four account takeover fixes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/open-wearables-release-0-3-alpha-flutter-sdk-mcp-server # Open Wearables Release 0.3 Alpha: Flutter SDK, MCP Server [All posts](https://openwearables.io/blog) [Releases](https://openwearables.io/blog/category/releases) Open Wearables Team · Jan 23, 2026 · 1 min read ## Key takeaways - First mobile SDK: Flutter package (health_bg_sync) for Apple Health. Handles background sync, historical backfill, and token-based authentication via iOS Keychain. - MCP Server connects Open Wearables to Claude and ChatGPT. Query health data in natural language directly from an LLM. - Redesigned developer dashboard with dedicated views for workouts, activity, sleep, and body measurements. - Extended Garmin support, XML uploads, Sentry error handling added. Open Wearables 0.3 alpha is available on GitHub. ## Flutter SDK for Apple Health The health_bg_sync Flutter package handles the full Apple Health integration lifecycle: permission flows, background sync, historical backfill, and incremental data transfer. Authentication uses token-based auth stored in iOS Keychain. Sessions restore automatically on app restart. Data arrives in Open Wearables in the same normalized format used by Garmin, Polar, and other providers. No separate parsing logic needed on the application side. Note: this is an alpha. The Apple Health SDK is functional but the onboarding flow and data source prioritization have known rough edges being addressed in the beta. ## MCP Server The MCP Server exposes wearable data as tools for LLMs. Connect it to Claude or ChatGPT and query health metrics in natural language: ask about last week's HRV trend, compare sleep across devices, or list recent workouts. The server translates natural language queries into Open Wearables API calls and returns structured results. ## Developer dashboard Redesigned with dedicated views for workouts, activity, sleep, and body measurements. Improved data visibility across connected providers. ## What's next 0.3 beta matures the Apple Health SDK with invitation code onboarding, refresh token support, and adds Strava as a provider. [GitHub](https://github.com/the-momentum/open-wearables) | [Docs](https://docs.openwearables.io) | [Discord](https://discord.gg/openwearables) Want to see it in action? [Book a demo](https://openwearables.io/book) ## Keep reading Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. Releases · Sep 23, 2026 · 13 min read ### Open Wearables 0.9.0: Google split into two providers, energy renamed, and a long list of API corrections Open Wearables 0.9.0 splits Google into google_health and health_connect, renames energy to active_energy, disables the Google Health API rollup that wrote duplicated rows, and fixes date bounds, filters and pagination across the API. Contains breaking changes. Releases · Sep 15, 2026 · 10 min read ### Open Wearables 0.8.0: Withings, sync history, and faster ingestion Open Wearables 0.8.0 adds Withings, database-backed sync history with two new endpoints, a 3.7x faster bulk upsert path, 5 GiB Apple Health XML uploads with MinIO parity, and four account takeover fixes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/open-wearables-release-0-3-android-google-health-connect-samsung-health # Open Wearables Release 0.3: Android, Google Health Connect, Samsung Health [All posts](https://openwearables.io/blog) [Releases](https://openwearables.io/blog/category/releases) Open Wearables Team · Mar 9, 2026 · 1 min read ## Key takeaways - Google Health Connect and Samsung Health are now supported. Android platform coverage is complete. - One unified SDK payload format shared across Apple HealthKit, Samsung Health, and Google Health Connect. - One-click Railway deployment. No local Docker environment required for evaluation or demos. - Garmin reliability overhaul: backfill rebuilt, user permissions corrected, deregistration webhooks added. Open Wearables 0.3 is available on GitHub. This is the first stable release in the 0.3 line, consolidating the alpha (Flutter SDK, MCP Server) and beta (Strava, Apple Health SDK maturation, data source priority). ## Android platform support Google Health Connect and Samsung Health are the two primary health aggregators on Android. Both are now supported. The SDK payload format was redesigned to be shared across Apple HealthKit, Samsung Health, and Google Health Connect, which made adding both Android aggregators possible in a single release. Open Wearables now covers all three major health aggregators: Apple Health on iOS, Google Health Connect and Samsung Health on Android. One API, one data model, regardless of platform. ## Railway deployment One-click deployment on Railway. Useful for evaluation, demos, and teams that prefer managed infrastructure over running Docker locally. The existing Docker Compose path is still the recommended option for production self-hosting. ## Garmin overhaul The Garmin integration received a comprehensive reliability pass: historical backfill rebuilt from scratch, user permissions corrected, deregistration webhooks added to handle account disconnects cleanly. ## What's next 0.4 adds Oura Ring, React Native SDK, raw payload storage, and production infrastructure improvements. [GitHub](https://github.com/the-momentum/open-wearables) | [Docs](https://docs.openwearables.io) | [Discord](https://discord.gg/openwearables) Want to see it in action? [Book a demo](https://openwearables.io/book) ## Keep reading Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. Releases · Sep 23, 2026 · 13 min read ### Open Wearables 0.9.0: Google split into two providers, energy renamed, and a long list of API corrections Open Wearables 0.9.0 splits Google into google_health and health_connect, renames energy to active_energy, disables the Google Health API rollup that wrote duplicated rows, and fixes date bounds, filters and pagination across the API. Contains breaking changes. Releases · Sep 15, 2026 · 10 min read ### Open Wearables 0.8.0: Withings, sync history, and faster ingestion Open Wearables 0.8.0 adds Withings, database-backed sync history with two new endpoints, a 3.7x faster bulk upsert path, 5 GiB Apple Health XML uploads with MinIO parity, and four account takeover fixes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/open-wearables-release-0-3-beta-strava-apple-health-sdk-data-source-priority # Open Wearables Release 0.3 Beta: Strava, Apple Health SDK, Data Source Priority [All posts](https://openwearables.io/blog) [Releases](https://openwearables.io/blog/category/releases) Open Wearables Team · Feb 16, 2026 · 1 min read ## Key takeaways - Strava joins as the seventh supported provider. Activity data flows through the same normalized API. - Apple Health SDK now uses invitation codes instead of manual SDK tokens. Refresh token support added for persistent sessions. - Data source priority is configurable at provider and device type level. Controls which value wins when multiple devices report the same metric. - MCP Server updated with workout data retrieval and activity listing tools. Open Wearables 0.3 beta is available on GitHub. ## Strava Strava is now a full provider. Activity and workout data normalizes into the same schema as Garmin, Polar, Whoop, and other supported providers. No separate query logic needed for Strava users. ## Apple Health SDK maturation Onboarding now uses invitation codes. Generate a code through the API, give it to the user, the SDK handles authentication from there. Removes the need to build a custom token-passing flow in your mobile app. Refresh token support means sessions persist across app restarts. Background sync continues without re-authentication. Structured logging with batch tracking added for debugging sync operations in production. ## Data source priority When multiple devices report the same metric (Apple Watch and iPhone both tracking steps, or Garmin and Apple Health both recording an activity), you now control which source wins. Configurable at provider level and device type level. ## MCP Server updates New tools for workout data retrieval and activity listing. Health data presentation prompts added for common LLM query patterns. ## What's next 0.3 stable adds Android platform support: Google Health Connect and Samsung Health. [GitHub](https://github.com/the-momentum/open-wearables) | [Docs](https://docs.openwearables.io) | [Discord](https://discord.gg/openwearables) Want to see it in action? [Book a demo](https://openwearables.io/book) ## Keep reading Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. Releases · Sep 23, 2026 · 13 min read ### Open Wearables 0.9.0: Google split into two providers, energy renamed, and a long list of API corrections Open Wearables 0.9.0 splits Google into google_health and health_connect, renames energy to active_energy, disables the Google Health API rollup that wrote duplicated rows, and fixes date bounds, filters and pagination across the API. Contains breaking changes. Releases · Sep 15, 2026 · 10 min read ### Open Wearables 0.8.0: Withings, sync history, and faster ingestion Open Wearables 0.8.0 adds Withings, database-backed sync history with two new endpoints, a 3.7x faster bulk upsert path, 5 GiB Apple Health XML uploads with MinIO parity, and four account takeover fixes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/open-wearables-release-0-4-3-health-scores-webhooks # Open Wearables Release 0.4.3: Health Scores, Webhooks [All posts](https://openwearables.io/blog) [Releases](https://openwearables.io/blog/category/releases) Open Wearables Team · Apr 15, 2026 · 1 min read ## Key takeaways - Sleep Score and Resilience Score now compute natively inside the platform. First release where Open Wearables produces scored health output from the data it holds. - Both scoring algorithms are open source. Every calculation is in the codebase, versioned and auditable. Open algorithms. Zero black boxes. - Outgoing webhooks deliver real-time events to any HTTPS endpoint. No polling required. - Both scores are in beta. Algorithms will change as data is gathered. Open Wearables 0.4.3 is available on GitHub. ## Health Scores (beta) Sleep Score evaluates sleep quality across duration, consistency, and stage composition. Resilience Score uses HRV-CV (Heart Rate Variability Coefficient of Variation) as a readiness and recovery stability metric. Both scores return through the existing API alongside the underlying wearable data. Use them as-is, build custom logic on top, or fork the algorithm and tune it for your population. The algorithms are open source. If a score produces a surprising result, you can trace it to the exact inputs and formulas in the repo. This is the practical difference from closed-source scoring: Whoop and Oura deliver a number with no method attached. Open Wearables ships the coefficients. ## Outgoing webhooks (beta) Register an HTTPS endpoint and subscribe it to event types. When matching data arrives, Open Wearables delivers a POST with the full normalized payload. Processing happens in the background so webhook delivery does not block data ingestion. Dashboard shows delivery history and lets you retry failed deliveries. ## What's next 0.5.0 completes the webhook infrastructure with incoming webhook support for Whoop and Suunto, and adds granular time-series queries to the MCP Server. [GitHub](https://github.com/the-momentum/open-wearables) | [Docs](https://docs.openwearables.io) | [Discord](https://discord.gg/openwearables) Want to see it in action? [Book a demo](https://openwearables.io/book) ## Keep reading Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. Releases · Sep 23, 2026 · 13 min read ### Open Wearables 0.9.0: Google split into two providers, energy renamed, and a long list of API corrections Open Wearables 0.9.0 splits Google into google_health and health_connect, renames energy to active_energy, disables the Google Health API rollup that wrote duplicated rows, and fixes date bounds, filters and pagination across the API. Contains breaking changes. Releases · Sep 15, 2026 · 10 min read ### Open Wearables 0.8.0: Withings, sync history, and faster ingestion Open Wearables 0.8.0 adds Withings, database-backed sync history with two new endpoints, a 3.7x faster bulk upsert path, 5 GiB Apple Health XML uploads with MinIO parity, and four account takeover fixes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/open-wearables-release-0-4-oura-ring-react-native-sdk # Open Wearables Release 0.4: Oura Ring, React Native SDK [All posts](https://openwearables.io/blog) [Releases](https://openwearables.io/blog/category/releases) Open Wearables Team · Mar 23, 2026 · 1 min read ## Key takeaways - Oura Ring is now a supported provider. First integration contributed entirely by a community member (@vikohone via PR #454). - React Native SDK is live. Cross-platform mobile option alongside the existing iOS, Android, and Flutter SDKs. - Raw payload storage: archive incoming provider data to S3 for debugging, auditing, and reprocessing. - Production infrastructure: dedicated docker-compose config, archive and retention policies, provider disconnect API. - Community milestone: 1,094 GitHub stars, 150 forks, 23 contributors. Open Wearables 0.4 is available on GitHub. ## Oura Ring Oura Ring support was contributed by @vikohone through PR #454. This is the first provider integration built entirely by someone outside the Momentum engineering team. Oura data flows through the unified API, normalized into the standard data model. If you're already querying sleep or activity data through Open Wearables, Oura users work without any changes on your side. ## React Native SDK Completes the mobile SDK coverage: iOS, Android, Flutter, and now React Native. Same authentication pattern and data flow as the other SDKs. ## Raw payload storage Enable S3 archival of incoming provider payloads before normalization. Useful for debugging data discrepancies, auditing what providers actually sent, and reprocessing historical data without asking users to re-sync. ## Production infrastructure Dedicated docker-compose config for production deployments separates concerns from the development setup. Archive and retention policies let you control how long raw and normalized data is stored. Provider disconnect API handles the full lifecycle of a user removing their wearable connection. ## What's next 0.4.3 ships Sleep Score and Resilience Score computed natively inside the platform. First release where Open Wearables produces scored health output from the data it holds. [GitHub](https://github.com/the-momentum/open-wearables) | [Docs](https://docs.openwearables.io) | [Discord](https://discord.gg/openwearables) Want to see it in action? [Book a demo](https://openwearables.io/book) ## Keep reading Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. Releases · Sep 23, 2026 · 13 min read ### Open Wearables 0.9.0: Google split into two providers, energy renamed, and a long list of API corrections Open Wearables 0.9.0 splits Google into google_health and health_connect, renames energy to active_energy, disables the Google Health API rollup that wrote duplicated rows, and fixes date bounds, filters and pagination across the API. Contains breaking changes. Releases · Sep 15, 2026 · 10 min read ### Open Wearables 0.8.0: Withings, sync history, and faster ingestion Open Wearables 0.8.0 adds Withings, database-backed sync history with two new endpoints, a 3.7x faster bulk upsert path, 5 GiB Apple Health XML uploads with MinIO parity, and four account takeover fixes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/open-wearables-release-0-5-0-webhooks-sleep-fixes-mcp-updates # Open Wearables Release 0.5.0: Webhooks, Sleep Fixes, MCP Updates [All posts](https://openwearables.io/blog) [Releases](https://openwearables.io/blog/category/releases) Open Wearables Team · May 7, 2026 · 2 min read ## Key takeaways - Outgoing webhooks are complete. Register HTTPS endpoints, subscribe to event types, receive normalized payloads in near real-time. Management UI included. Powered by Svix, marked beta. - Incoming webhooks for Whoop and Suunto. Providers push data to Open Wearables instead of waiting for the next scheduled pull. Requires switching sync mode in admin panel and registering the webhook URL with the provider. - Sleep calculations significantly more accurate: UTC grouping bugs, awake time inclusion, and duplication during merge all fixed. - HRV-CV now includes a normalized 0-100 score. MCP Server gets a new get_timeseries tool for granular sample queries. Open Wearables 0.5.0 is available on GitHub. ## Webhooks Open Wearables has two sync modes. The default is periodic pull: the platform fetches new data from each provider on a configured schedule. 0.5.0 adds the second mode: webhook-based sync. ### Outgoing webhooks Register one or more HTTPS endpoints in the dashboard and subscribe them to event types. When matching data arrives, Open Wearables delivers a POST with the full normalized payload. Delivery runs in the background so it does not block data ingestion. The management UI shows delivery history and lets you retry failed deliveries without touching config files. ### Incoming webhooks: Whoop and Suunto Instead of waiting for the next scheduled pull, Whoop and Suunto can now push data to Open Wearables as soon as it is available. Latency drops from hours to seconds or minutes. Enabling this requires two steps: switch the sync mode in the Open Wearables admin panel, then register the webhook URL in your developer account on the provider side. ## Sleep calculation fixes Three bugs fixed: UTC grouping that incorrectly split sessions across midnight boundaries, awake time incorrectly included in total sleep duration, and record duplication when merging data from multiple sources. All fixes apply to new calculations going forward. ## HRV-CV score HRV-CV now returns a normalized 0-100 score alongside the raw coefficient of variation value. Storage precision improved. ## MCP Server: get_timeseries New tool that returns raw time-series samples rather than aggregated session summaries. Useful for AI features that need to analyze patterns within a session, not just session-level stats. [GitHub](https://github.com/the-momentum/open-wearables) | [Docs](https://docs.openwearables.io) | [Discord](https://discord.gg/openwearables) Want to see it in action? [Book a demo](https://openwearables.io/book) ## Keep reading Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. Releases · Sep 23, 2026 · 13 min read ### Open Wearables 0.9.0: Google split into two providers, energy renamed, and a long list of API corrections Open Wearables 0.9.0 splits Google into google_health and health_connect, renames energy to active_energy, disables the Google Health API rollup that wrote duplicated rows, and fixes date bounds, filters and pagination across the API. Contains breaking changes. Releases · Sep 15, 2026 · 10 min read ### Open Wearables 0.8.0: Withings, sync history, and faster ingestion Open Wearables 0.8.0 adds Withings, database-backed sync history with two new endpoints, a 3.7x faster bulk upsert path, 5 GiB Apple Health XML uploads with MinIO parity, and four account takeover fixes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/oura-api-accessing-ring-data-sleep-hrv-readiness # Oura API: accessing ring data, sleep, HRV and readiness [All posts](https://openwearables.io/blog) [Oura](https://openwearables.io/blog/category/oura) Open Wearables Team · May 3, 2026 · 10 min read ## Key takeaways - The Oura API is a REST API that surfaces data Oura's cloud collects from the ring. There is no direct oura ring api endpoint at the device level. - All data flows from ring to phone to Oura cloud to developer API. Plan for sync delays of up to several hours. - Authentication uses OAuth 2.0 with personal access tokens for single-user projects and a full OAuth flow for multi-user apps. - Scopes control which data types you can access. Request all required scopes during the OAuth flow, not incrementally after. - Date range queries use start_date and end_date in YYYY-MM-DD format, evaluated in the user's local timezone. - SpO2 data is only available for Oura Ring 3 and later. Build graceful fallbacks for users on older hardware. - Open Wearables normalizes Oura data into a unified schema alongside other wearables, handles OAuth and token management, and exposes consistent endpoints regardless of which device the user has connected. - Self-hosted and MIT-licensed, Open Wearables gives you full control over user data without routing it through a third-party service. ## Introduction The Oura Ring has become a reference device in the consumer wearable space for a specific reason: it measures consistently and at unusually high fidelity because of where it sits on the body. The finger has dense capillary networks and relatively little motion artifact compared to the wrist, which gives Oura's optical sensors more reliable access to the pulse signal. The result is sleep staging and HRV data that health researchers and biohackers tend to trust more than wrist-based alternatives. For developers, the Oura API is one of the more approachable in the wearable space. OAuth 2.0 is standard, access tokens are long-lived, the REST endpoints are clean and well-documented, and the data model is coherent. The main conceptual shift is understanding that Oura is a sleep and recovery platform, not an activity platform. Its workout tracking is limited. Its GPS coverage is nonexistent. But for sleep quality, readiness, HRV detail and body temperature, it is among the best sources available from a consumer device. This guide covers what the API provides, how the core metrics work, authentication, and how to structure an integration that gets the most out of Oura's distinctive data. ## What the Oura API provides Oura's API is organized around several resource types, each mapped to specific physiological measurements. Daily sleep is the most data-rich resource. Each sleep record includes: Sleep Score (0-100), total time in bed, total sleep time, sleep efficiency, sleep latency, number of disturbances, time spent in each sleep stage (awake, light, deep and REM), respiratory rate during sleep, average heart rate during sleep, and 5-minute interval HRV readings across the full sleep period. The HRV resolution is one of Oura's standout features: rather than a single overnight average, you get a time series of HRV values that lets you see how HRV evolves across different sleep stages. Daily readiness aggregates multiple signals into Oura's Readiness Score. The contributing factors are exposed individually: sleep score from the previous night, HRV balance (today's HRV compared to the user's 28-day rolling average), resting heart rate trend (whether RHR is trending up or down relative to baseline), body temperature deviation, and previous day activity score. Each contributor is scored and weighted to produce the composite. Body temperature is recorded nightly as deviation from the user's personal baseline. Oura does not report absolute skin temperature; it reports how much last night's temperature differed from the user's established mean. A deviation of more than +0.5 degrees Celsius typically indicates an immune response, elevated stress or, for users who track it, the luteal phase of the menstrual cycle. A deviation of -0.5 or below can indicate unusual physiological suppression. This signal is available on all Oura Ring 3 devices. SpO2 (blood oxygen saturation) is available on Oura Ring 3, reported as an average nightly value with a low reading for the night. Significant drops in SpO2 during sleep can indicate sleep apnea or other respiratory issues, though Oura is not a clinical device. Daily activity provides steps, active calories, sedentary time, low, medium and high activity minutes, and MET minutes for the day. Heart rate is available as a time series with readings at 5-minute intervals during sleep and at lower frequency during the day. ## Authentication Oura uses standard OAuth 2.0 with the authorization code flow. A notable difference from providers like Strava is that Oura access tokens are long-lived and do not expire on a short cycle. Refresh tokens are provided but you do not need to refresh proactively before every API call the way you do with Strava's 6-hour tokens. The available scopes map to data categories: personal for profile, daily for daily summaries including readiness and activity, heartrate for the heart rate time series, workout for workout records, session for rest and meditation sessions, spo2 for blood oxygen, and ring_configuration for device information. Request only the scopes your product actually uses. ## Oura Ring API: what changes between the API and the ring itself Developers searching "oura ring api" are often asking a slightly different question than those searching "oura api." They want to know whether they're interfacing with the ring directly, or with something in between. The answer matters for how you design your sync logic. The Oura Ring has no developer-facing API of its own. The ring collects data locally and syncs it to Oura's cloud when the user opens the Oura app on their phone. From there, the developer API surfaces that data. You are always pulling from Oura's cloud layer, not from the device itself. The practical consequence: there is no real-time data stream from the ring during sleep or activity. A user wakes up, their ring syncs with their phone, the data lands in Oura's cloud, and only then is it available via the API. Depending on how often a user syncs, this can mean a gap of several hours between when the data was recorded and when you can retrieve it. When you build on top of Open Wearables, this architecture is already accounted for. OW handles the OAuth flow and token management for each user, and its unified endpoints return data once it has propagated through Oura's cloud. You write the same query regardless of which wearable your user has connected. ``` GET /api/v1/users/{user_id}/events/sleep GET /api/v1/users/{user_id}/summaries/ ``` ## Understanding oura's core metrics Readiness Score is Oura's most important output for coaching and wellness applications. It is a composite of multiple signals and reflects the body's preparedness for the demands of the day. High readiness (85+) suggests the user is well-recovered and physiologically primed. Low readiness (below 60) suggests the body is under stress and would benefit from lighter activity or additional recovery. The Readiness Score's value in a product context comes from its contributing factors. A user with a score of 65 wants to know whether that score is driven by poor sleep (actionable: improve sleep hygiene), elevated resting heart rate (possible: overtraining or early illness), below-average HRV (possible: high training load or stress), or elevated body temperature (possible: illness or luteal phase). Exposing these contributors gives users context that a single number cannot. HRV balance is the most sensitive leading indicator in Oura's data. It compares today's HRV against the user's rolling 28-day average. When HRV balance is below 100 (meaning today's HRV is below the rolling average), recovery is incomplete relative to the user's normal state. Sustained below-average HRV balance over multiple days indicates cumulative fatigue, overtraining, or systemic stress. Body temperature deviation is a signal most wearable APIs do not provide, which makes it distinctive for certain use cases. For illness detection, elevated temperature often precedes subjective symptoms by 24-48 hours. For female health tracking, temperature rises predictably after ovulation and stays elevated through the luteal phase. For general recovery, unusual temperature deviations correlate with elevated inflammatory markers. Applications in women's health, longevity or clinical monitoring can build meaningful features around this signal that competitors cannot easily replicate. ## Data timing and sync strategy Oura processes sleep data after the ring syncs with the user's phone. Processing typically completes by mid-morning. Data is not available in real time during the night, and there is no API endpoint that streams live sensor readings. The practical implication: schedule your daily sync to run between 7 AM and 10 AM in the user's local time zone. Data from the previous night will be processed and available in that window for most users. Some users sync late or have unusual sleep schedules, so build tolerance for missing data on any given day rather than treating it as an error. For historical backfill when a user first connects, the API supports date-range queries. Oura typically provides up to two years of historical data. This means a user who has been wearing the ring for a year arrives with substantial sleep and recovery history that your product can use immediately to establish baselines and surface trends. ## Common issues when building with the Oura API Most problems developers run into with the Oura API fall into a small set of patterns. Here are the ones worth knowing before you ship. ### Sync delay and missing data windows The most common confusion is treating Oura data as real-time. It is not. After a user's sleep session ends, the ring needs to sync with the Oura mobile app before any data appears in the API. Depending on the user's phone usage patterns, this can take anywhere from minutes to several hours. Build your sync logic to tolerate latency and poll on a schedule rather than expecting immediate availability. ### Token scope mismatches The Oura API uses OAuth scopes to gate access to different data types. If you request tokens with insufficient scope, endpoints will return empty arrays rather than errors, which can be hard to debug. Make sure your OAuth flow requests all the scopes your app needs upfront. ### Date range and timezone handling The start_date and end_date query parameters accept dates in YYYY-MM-DD format and are evaluated against the user's local timezone as recorded by Oura. If your server is in UTC and your user is in UTC+9, a query for start_date=2025-01-15 will return data anchored to their local midnight, not yours. Always store and display dates relative to the user's timezone. ### SpO2 availability by ring generation Blood oxygen (SpO2) data is only collected by Oura Ring 3 and later. If your user base includes Ring 2 users, SpO2 endpoints will return no data for those accounts. Handle this gracefully at the application layer rather than treating an empty response as an error. ### Data gaps from non-wear days Users skip wearing the ring. When they do, the API returns no records for those dates rather than a zero-value record. Any aggregation or streak logic in your app needs to distinguish between "ring not worn" and "data not yet synced." ## Open Wearables and Oura Open Wearables handles Oura's OAuth flow, token management and data normalization. Daily readiness, sleep, HRV, body temperature, SpO2 and activity data are available through a unified schema shared with Whoop, Garmin, Polar and other supported providers. For multi-provider apps, this means a user with Oura and a user with Whoop can both use your product's recovery features. The underlying provider difference is abstracted away by Open Wearables' normalization layer. Self-hosted and MIT-licensed. ## Faq ### Which Oura ring generations does the API support? Oura Ring Generation 3 and later. Gen 2 had limited API support for certain data types. Body temperature deviation, SpO2 and some advanced metrics require Gen 3 or later. ### Is Oura data available in real time during sleep? No. Oura syncs data when the ring is near the user's phone via Bluetooth and processes it server-side. Data is generally available by mid-morning the following day. ### How is oura's readiness score different from whoop's recovery score? Both are 0-100 daily readiness indicators but use different sensor inputs and algorithms. Oura weighs sleep heavily and uses body temperature as a distinctive input. Whoop emphasizes HRV during slow-wave sleep and cumulative training strain. They are correlated but not identical, and the values are not interchangeable. ### Does Oura ring have GPS? No. The ring has no GPS. Workout tracking is based on accelerometer and heart rate data. For GPS-based activity data, pair Oura with a GPS-capable device. ### Can i access historical Oura data when a user first connects? Yes. The API allows querying by date range and Oura typically provides up to two years of historical data. Backfilling on first connection gives your product immediate baseline data for trend analysis. ## Open Wearables Open Wearables is an open-source platform that connects your application to wearable and health data providers through a single API. One normalized data model, multi-provider support in a single self-hosted deployment, no per-user fees, MIT licensed, and health intelligence built in: normalized recovery, sleep, activity and biometric data ready for your product layer. We offer custom deployment and integration support through Momentum. If your team needs help getting to production faster, we can set up and configure Open Wearables as part of a managed engagement. [Let's talk](https://www.themomentum.ai/lets-talk). [Book a demo](https://openwearables.io/book) to see how Open Wearables fits your use case. ## Oura integration View the full [Oura integration documentation](https://openwearables.io/integrations/oura) on Open Wearables. ## See related articles - [What wearable app development actually looks like in 2026](https://openwearables.io/blog/what-wearable-app-development-actually-looks-like-in-2026) - [The wearable app development checklist: what you actually need to build (and what you don't)](https://openwearables.io/blog/wearable-app-development-checklist) [How to Use Oura Ring Data in Your App](https://openwearables.io/blog/how-to-use-oura-ring-data-in-your-app) [Whoop API: Recovery, Strain and Sleep Data for Developers](https://openwearables.io/blog/whoop-api-recovery-strain-sleep-data-for-developers) [Ultrahuman API: Ring Data, CGM and Recovery Metrics](https://openwearables.io/blog/ultrahuman-api-ring-data-cgm-recovery-metrics) ## Keep reading Oura · May 3, 2026 · 5 min read ### How to use Oura ring data in your app Readiness Score, HRV trends and body temperature deviation are Oura's most actionable signals. Here's how to use them effectively in a coaching or wellness product. Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. Guides · Oct 26, 2026 · 9 min read ### Moving from a hosted wearable API to Open Wearables: a migration playbook Moving from a hosted wearable API to Open Wearables is usually a re-integration rather than a data migration. This playbook walks through the decisions, the steps in order, how your users reconnect and what to tell your security team. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/page/2 # What shipped, and how to build with it. Blog Release notes every couple of weeks, guides to the provider APIs and their quirks, and the occasional longer piece on getting health data into a shape you can work with. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) ## Posts Guides · Jul 22, 2026 · 5 min read ### How to Build an AI Agent That Reasons Over Health Data An AI agent that reasons over health data is different from one that reads it. Here is how the Open Wearables MCP server works and how to build the reasoning layer on top of it. Guides · Jul 22, 2026 · 5 min read ### How to Add Wearable Data to a Corporate Wellness Platform Corporate wellness platforms need wearable data from multiple providers without requiring employees to switch devices. Here is what Open Wearables handles and what your application builds on top. Guides · Jul 22, 2026 · 5 min read ### Wearable Data Deduplication: How to Handle Users With Multiple Devices Users with multiple wearables produce overlapping data. Here is how Open Wearables handles within-provider deduplication automatically and how the priority system resolves cross-provider conflicts. Guides · Jul 22, 2026 · 6 min read ### How to Structure Health Data for AI: What Your LLM Actually Needs Raw wearable data breaks LLMs. Consistent structure does not. Here is what the Open Wearables data model looks like and how to decide what to pass to your model for each type of health question. Guides · Jul 22, 2026 · 5 min read ### What Is an Open Source Wearable API and When Does It Make Sense An open source wearable API gives you the integration code itself, not just an endpoint. Here is what that means in practice, what Open Wearables provides, and when this approach fits your product. Guides · Jul 22, 2026 · 5 min read ### How to Add Wearable Support to an Existing Health App in Days, Not Months Adding wearable support to an existing app does not require rebuilding your data layer. Open Wearables sits alongside your backend. Here is what the integration looks like and how long each step actually takes. Garmin · Jul 21, 2026 · 8 min read ### Garmin Connect API: What You Can Fetch and How to Do It Faster The Garmin API gives you access to workouts, health metrics, and device data. Here is what you can retrieve, how the OAuth 1.0 flow works, and when it makes sense to use a ready-made integration layer instead of building from scratch. Guides · Jul 21, 2026 · 6 min read ### How to Handle OAuth, Webhooks, and Token Refresh Across Multiple Wearable Providers Every wearable provider implements OAuth differently, delivers data through a different mechanism, and has different token lifecycle rules. Here is how Open Wearables abstracts all of it and what your application still needs to handle. Guides · Jul 21, 2026 · 8 min read ### How to Give Your LLM Access to Wearable Data Most LLM integrations with health data dump raw numbers into context and hope for the best. Here is how to use the Model Context Protocol with Open Wearables so your LLM queries the right data and reasons about it. Guides · Jul 21, 2026 · 4 min read ### How to Build a HIPAA-Compliant Health App That Uses Wearable Data HIPAA compliance starts with where data lives. Open Wearables is self-hosted: wearable data stays on your infrastructure. Here is what the platform provides and what you need to configure yourself. Releases · Jul 16, 2026 · 5 min read ### Open Wearables 0.6.3: nap detection and HTTP logs middleware Open Wearables 0.6.3 adds nap detection for Apple and Oura, structured HTTP logs, an outgoing webhooks flag, and Strava workout samples. Guides · Jul 15, 2026 · 8 min read ### What wearable app development actually looks like in 2026 Most tutorials about wearable app development skip the hard parts. This article shows where the complexity actually lives: OAuth flows, token refresh, normalization, webhook-only providers. And what you can take off the shelf with Open Wearables. The platform ## Looking for the product rather than the post? ### [Platform](https://openwearables.io/platform) ### [Integrations](https://openwearables.io/integrations) ### [Pricing](https://openwearables.io/pricing) --- Source: https://openwearables.io/blog/page/3 # What shipped, and how to build with it. Blog Release notes every couple of weeks, guides to the provider APIs and their quirks, and the occasional longer piece on getting health data into a shape you can work with. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) ## Posts Guides · Jul 15, 2026 · 7 min read ### The wearable app development checklist: what you actually need to build (and what you don't) Scoping a wearable feature is harder than it looks. This checklist maps what you actually need to build, what Open Wearables handles for you, and what you will still own no matter what. Releases · Jun 30, 2026 · 5 min read ### Open Wearables 0.6.2: data integrity for multi-source health apps Open Wearables 0.6.2 fixes step and energy double-counting for Garmin and Oura, retrieves active minutes natively from four providers, adds sleep session deduplication to the events endpoint, and resolves a Garmin respiratory rate storage bug. Releases · Jun 23, 2026 · 3 min read ### Open Wearables 0.6.1: Data coverage & observability Open Wearables 0.6.1 adds a Data Coverage tab to the admin panel, introduces PULL_SYNC_LOOKBACK as a safeguard for periodic pull syncs, ships observability and logging improvements, and includes provider-specific bug fixes. Releases · Jun 13, 2026 · 4 min read ### Open Wearables 0.6.0: Women's Health & FIT Files Open Wearables 0.6.0 adds Garmin menstrual cycle tracking, a FIT file parser with second-by-second workout data, Oura reliability fixes, and multi-account sync support. No breaking changes to the API. Google Health Connect · Jun 7, 2026 · 4 min read ### Google Health Connect integration for Android developers Google Health Connect is not a cloud API. It requires on-device Android SDK integration. Learn how Open Wearables handles the full Health Connect lifecycle. Samsung Health · Jun 6, 2026 · 4 min read ### Samsung Health API integration guide for Android developers Samsung Health API is not a cloud API. It requires an on-device SDK. Learn how Open Wearables Android SDK handles permissions, background sync, and normalization. Apple Health · Jun 5, 2026 · 4 min read ### How to integrate Apple Health API into your backend There is no Apple Health API in the traditional sense. Learn how Open Wearables SDK-based approach gets HealthKit data into your backend with token-based auth and XML import. Whoop · Jun 2, 2026 · 4 min read ### How to integrate Whoop API data into your health app The Whoop API requires a paid membership and OAuth setup. Learn how Open Wearables handles authentication, polling, and normalization so you query one endpoint. Suunto · Jun 2, 2026 · 6 min read ### How to integrate Suunto data into your health app The Suunto API provides workouts and 24/7 continuous monitoring. Open Wearables handles OAuth, polling, and normalization so you query one endpoint instead of building provider logic. Guides · Jun 1, 2026 · 4 min read ### Strava API integration guide for health and fitness apps The Strava API requires OAuth, token refresh, and normalization. Learn how Open Wearables abstracts all of that into one sync endpoint alongside other providers. Polar · May 30, 2026 · 5 min read ### How to integrate Polar data into your health app The Polar API (AccessLink) requires OAuth, token management, and polling. Open Wearables abstracts all of that into a single sync endpoint with normalized output. Guides · May 27, 2026 · 6 min read ### How to build an AI health coaching app with wearable data Learn how to build an AI health coaching app that turns wearable health scores into personalized coaching responses using Open Wearables and its MCP server. The platform ## Looking for the product rather than the post? ### [Platform](https://openwearables.io/platform) ### [Integrations](https://openwearables.io/integrations) ### [Pricing](https://openwearables.io/pricing) --- Source: https://openwearables.io/blog/page/4 # What shipped, and how to build with it. Blog Release notes every couple of weeks, guides to the provider APIs and their quirks, and the occasional longer piece on getting health data into a shape you can work with. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) ## Posts Guides · May 24, 2026 · 6 min read ### How to normalize wearable data across providers If you are looking for a Terra API alternative, Open Wearables normalizes data from all major wearable providers into a unified schema. Self-hosted, open source, no per-user fees. Guides · May 21, 2026 · 3 min read ### How to sync wearable data from multiple devices Garmin API uses webhook-only delivery, not REST polling. Learn how Open Wearables handles Garmin alongside Polar, Suunto, Whoop, and Apple Health in a unified normalized API. Apple Health · May 20, 2026 · 4 min read ### How to integrate Apple Health data into your app A practical apple health integration guide using Open Wearables. Learn the two paths: mobile SDK for real-time background sync and XML import for historical HealthKit exports. Releases · May 20, 2026 · 3 min read ### Open Wearables 0.5.2: Polar Webhooks, Sport Type Expansion, and HRV Score Integrity Open Wearables 0.5.2 adds Polar webhook support, expands workout type mappings, new Garmin fields, and stricter HRV scoring. Guides · May 14, 2026 · 7 min read ### Wearable API integration: comparing SaaS, custom build, and open source A technical founder’s guide to choosing a wearable health data API. Compare SaaS vendors, in-house builds, and self-hosted open source by cost, compliance, and engineering effort. Guides · May 14, 2026 · 4 min read ### How to customize Open Wearables for your product Open Wearables is built to be adapted. Learn how to customize health scoring, add provider integrations, and deploy enterprise-grade infrastructure with Momentum's engineering team. Releases · May 8, 2026 · 2 min read ### Open Wearables 0.5.1: Oura & Strava Webhooks, Live Sync Status, RMSSD HRV Open Wearables 0.5.1 ships webhook support for Oura and Strava, live sync status via SSE, RMSSD HRV in Body Summary, and a redesigned Admin Panel dashboard. No breaking changes. Releases · May 7, 2026 · 2 min read ### Open Wearables Release 0.5.0: Webhooks, Sleep Fixes, MCP Updates Open Wearables 0.5.0 ships complete webhook infrastructure, incoming webhooks for Whoop and Suunto, sleep calculation fixes, HRV-CV scoring, and a new MCP Server time-series tool. Garmin · May 6, 2026 · 11 min read ### Garmin Connect API: developer guide for activities and health metrics Garmin's Health API uses push-based delivery and OAuth 1.0a, covering 100+ sport types, GPS, Body Battery, HRV, sleep and more. Here's what building with it actually requires. Samsung Health · May 6, 2026 · 6 min read ### How to connect Samsung Health to your app The Samsung Health integration pipeline covers developer program application, OAuth 2.0, token management, data querying and normalization before you ship a single product feature. Samsung Health · May 6, 2026 · 5 min read ### Samsung Health API: Galaxy Watch data for developers Samsung Health Platform provides server-side API access to Galaxy Watch data including heart rate, sleep stages, workouts, stress score, SpO2, HRV and body composition. Strava · May 6, 2026 · 11 min read ### Strava API 2026: developer guide to activities, heart rate and GPS data A practical guide to connecting Strava's API in production: OAuth token refresh, rate limits, webhooks, and how to normalize activity data across multiple providers. The platform ## Looking for the product rather than the post? ### [Platform](https://openwearables.io/platform) ### [Integrations](https://openwearables.io/integrations) ### [Pricing](https://openwearables.io/pricing) --- Source: https://openwearables.io/blog/page/5 # What shipped, and how to build with it. Blog Release notes every couple of weeks, guides to the provider APIs and their quirks, and the occasional longer piece on getting health data into a shape you can work with. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) ## Posts Whoop · May 6, 2026 · 9 min read ### Whoop API: recovery, strain and sleep data for developers The Whoop API exposes Recovery Score, HRV, Strain and Sleep Performance through a cycle-based model. Here's how it works in practice and what building with it actually requires. Garmin · May 6, 2026 · 7 min read ### Garmin API push notifications: how callback sync works Garmin's Health API pushes data to your callback URLs when users sync their devices. Here's how the system works end-to-end and what reliable implementation requires. Google Health Connect · May 6, 2026 · 7 min read ### Google Health Connect integration: Android health data for developers Google Health Connect is Android's on-device health data hub, aggregating data from Wear OS, Galaxy Watch, Fitbit, Garmin and third-party apps. Here's how to build with it. Google Health Connect · May 6, 2026 · 7 min read ### How to access Google Health Connect data in your backend There is no Google server-side API for Health Connect. Your Android app must read data on device and upload it. Here's the complete pipeline from setup to production. Whoop · May 6, 2026 · 6 min read ### Building a health app with Whoop API data Getting data out of the Whoop API is one problem. Building something users find valuable is another. Here's how to use Recovery Score, HRV trends and Sleep Performance effectively in a product. Apple Health · May 6, 2026 · 6 min read ### Getting Apple Health data into your backend There is no server-side Apple Health API. Getting data to your backend means building an iOS pipeline: permissions, observer queries, background delivery and reliable upload. Polar · May 5, 2026 · 8 min read ### Polar API: training, HRV and Nightly Recharge data Polar AccessLink API provides training sessions for 100+ sport types, HRV4T nightly HRV tracking, Nightly Recharge, sleep staging and VO2 max. Here's what building with it requires. Ultrahuman · May 5, 2026 · 6 min read ### Ultrahuman API: ring data, CGM and recovery metrics Ultrahuman Ring AIR provides Recovery Score, Sleep Score, HRV, skin temperature and movement data. Its CGM integration adds continuous blood glucose alongside recovery metrics. Ultrahuman · May 5, 2026 · 6 min read ### Building with Ultrahuman data: recovery, sleep and glucose Ultrahuman's combination of ring biometrics and optional CGM glucose data enables product features no other single platform supports. Here's how to build with it effectively. Strava · May 4, 2026 · 5 min read ### How to integrate Strava without building OAuth from scratch Building a production Strava integration means writing OAuth, token refresh, webhooks and rate limit logic before shipping any product. Here's what that actually takes, and a simpler path. Suunto · May 4, 2026 · 6 min read ### How to integrate Suunto data into your training app Suunto's altitude metrics and Training Effect scores enable outdoor sport features no other major wearable API covers with comparable depth. Here's how to use them in a product. Apple Health · May 4, 2026 · 7 min read ### Apple HealthKit API: what data you can access and how HealthKit is an on-device framework, not a remote API. There is no server-side Apple Health endpoint. Here's what's available, how permissions work, and what building an integration really requires. The platform ## Looking for the product rather than the post? ### [Platform](https://openwearables.io/platform) ### [Integrations](https://openwearables.io/integrations) ### [Pricing](https://openwearables.io/pricing) --- Source: https://openwearables.io/blog/page/6 # What shipped, and how to build with it. Blog Release notes every couple of weeks, guides to the provider APIs and their quirks, and the occasional longer piece on getting health data into a shape you can work with. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) ## Posts Oura · May 3, 2026 · 10 min read ### Oura API: accessing ring data, sleep, HRV and readiness The Oura Ring API provides Sleep Score, Readiness Score, HRV, body temperature deviation and SpO2 through a clean REST interface. Here's what it offers and how to build with it. Polar · May 3, 2026 · 7 min read ### How to access Polar watch data in your health app Polar's cardio versus muscle load split and ANS Charge from Nightly Recharge enable coaching features that most wearable APIs cannot support. Here's how to use them effectively. Oura · May 3, 2026 · 5 min read ### How to use Oura ring data in your app Readiness Score, HRV trends and body temperature deviation are Oura's most actionable signals. Here's how to use them effectively in a coaching or wellness product. Suunto · May 2, 2026 · 7 min read ### Suunto API: accessing watch data for developers The Suunto API provides workout data for 80+ sport types with GPS, heart rate, altitude metrics, Training Effect scores and VO2 max. Here's what building with it requires. Releases · Apr 15, 2026 · 1 min read ### Open Wearables Release 0.4.3: Health Scores, Webhooks Open Wearables 0.4.3 ships Sleep Score and Resilience Score with open algorithms. First release where the platform produces scored health output. Outgoing webhooks added. Releases · Mar 23, 2026 · 1 min read ### Open Wearables Release 0.4: Oura Ring, React Native SDK Open Wearables 0.4 adds Oura Ring support contributed by a community member, React Native SDK, raw payload storage to S3, and production infrastructure improvements. Releases · Mar 9, 2026 · 1 min read ### Open Wearables Release 0.3: Android, Google Health Connect, Samsung Health Open Wearables 0.3 adds Google Health Connect and Samsung Health, completing Android platform support. Includes one-click Railway deployment and a Garmin reliability overhaul. Releases · Feb 16, 2026 · 1 min read ### Open Wearables Release 0.3 Beta: Strava, Apple Health SDK, Data Source Priority Open Wearables 0.3 beta adds Strava as a provider, matures the Apple Health SDK with invitation code onboarding and refresh tokens, and introduces configurable data source priority. Releases · Jan 23, 2026 · 1 min read ### Open Wearables Release 0.3 Alpha: Flutter SDK, MCP Server Open Wearables 0.3 alpha ships the first mobile SDK for Flutter with Apple Health integration and an MCP Server connecting wearable data to LLMs. Releases · Jan 12, 2026 · 1 min read ### Open Wearables Release 0.2.2: Production Stability, Extended Provider Support Open Wearables 0.2.2 fixes critical sync issues across Apple Health, Whoop, and Suunto. Adds sleep summaries, AWS XML import guide, and API performance improvements. Releases · Jan 8, 2026 · 1 min read ### Open Wearables Release 0.2.1: Whoop, Mobile SDK Authentication Open Wearables 0.2.1 adds Whoop as the fourth provider, user-scoped SDK tokens for mobile apps, and a sleep summaries endpoint. Releases · Dec 22, 2025 · 1 min read ### Open Wearables Release 0.2: Sleep, Workouts, Timeseries Open Wearables 0.2 adds Sleep, Workout, and Timeseries endpoints with 59 data types and 870 tests. The platform ## Looking for the product rather than the post? ### [Platform](https://openwearables.io/platform) ### [Integrations](https://openwearables.io/integrations) ### [Pricing](https://openwearables.io/pricing) --- Source: https://openwearables.io/blog/page/7 # What shipped, and how to build with it. Blog Release notes every couple of weeks, guides to the provider APIs and their quirks, and the occasional longer piece on getting health data into a shape you can work with. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) ## Posts Releases · Dec 10, 2025 · 1 min read ### Open Wearables Release 0.1: Workout Data, OAuth, Developer Portal First public release of Open Wearables. Workout data from Garmin, Suunto, and Polar, unified data model, built-in OAuth flows, and a developer portal. The platform ## Looking for the product rather than the post? ### [Platform](https://openwearables.io/platform) ### [Integrations](https://openwearables.io/integrations) ### [Pricing](https://openwearables.io/pricing) --- Source: https://openwearables.io/blog/polar-api-training-hrv-nightly-recharge-data # Polar API: training, HRV and Nightly Recharge data [All posts](https://openwearables.io/blog) [Polar](https://openwearables.io/blog/category/polar) Open Wearables Team · May 5, 2026 · 8 min read ## Key takeaways - Polar AccessLink API uses a transaction-based data model: you must open a transaction, fetch data within it, and commit or rollback before new data is available. - HRV4T (Heart Rate Variability for Training) provides nightly HRV recordings taken in a standardized three-minute morning measurement, making the data consistent across users. - Nightly Recharge is Polar's overnight recovery metric combining ANS (autonomic nervous system) charge from HRV analysis with sleep charge from sleep staging. - Training Load Pro splits load into Cardio Load and Muscle Load, enabling coaching apps to understand not just how hard a user trained but what physiological systems were stressed. - Developer access to Polar AccessLink is self-serve but requires users to grant consent through the Polar authorization flow before data is accessible. - Open Wearables normalizes Polar data alongside other supported providers into a unified schema. ## Introduction Polar has been manufacturing heart rate monitors and sports watches since the 1970s and has built one of the most sophisticated training data models in the wearable industry. Their devices are disproportionately popular among endurance athletes, coaches and sports scientists who need precise physiological data rather than general wellness tracking. The Polar AccessLink API exposes this data to developers. Unlike consumer-oriented platforms that abstract away complexity behind simple scores, Polar gives you the underlying measurements: raw RR interval data for HRV analysis, detailed training load breakdowns by cardiovascular and muscular demand, and sleep stages with autonomic nervous system state during recovery. The trade-off is that the API has a non-standard transaction model that requires understanding before you can reliably fetch data, and the depth of available metrics means your normalization layer has real work to do. For apps serving serious athletes or building evidence-based coaching features, Polar is often the richest available data source. ## What Polar AccessLink provides Training and exercise data covers over 100 sport types with detailed session summaries. Each session includes duration, distance for applicable sports, heart rate time series, heart rate zones, cadence for cycling and running, altitude data for GPS-enabled outdoor activities, Training Effect scores for aerobic and anaerobic adaptation, and Cardio Load and Muscle Load from Training Load Pro on supported devices. Daily activity data includes step count, active calories, sedentary time, activity goal progress and activity time by intensity zone. Polar devices track movement throughout the day and report how much time the user spent at low, medium and high activity levels. Sleep data includes total sleep time, sleep stages (light, deep and REM), sleep continuity scores, and breathing metrics on devices that support continuous heart rate monitoring during sleep. Sleep timing, sleep efficiency and wake episodes are also available. Nightly Recharge is Polar's overnight recovery composite. It combines ANS Charge (derived from HRV analysis during the first hours of sleep, when parasympathetic nervous system activity provides the clearest recovery signal) and Sleep Charge (based on sleep staging, duration and continuity). Both components are scored individually and combined into an overall Nightly Recharge status. HRV4T data is available on devices and plans where the user has enabled the morning HRV measurement. This is a standardized three-minute recording taken lying down immediately after waking, producing consistent RR interval data suitable for trend analysis. Polar's approach to HRV measurement reduces the variability that comes from measuring HRV continuously throughout the night. Physical information includes VO2 max estimates, running performance tests, orthostatik test results and maximum heart rate, which are used in Polar's training load calculations and are available via the physical info endpoint. ## Authentication and user registration Polar AccessLink uses OAuth 2.0 with the authorization code flow. Register your application at the Polar developer portal to receive client credentials. The process is self-serve and does not require an approval period. There is a critical step that Polar requires before you can read any data for a user: after completing the OAuth authorization flow, you must explicitly register the user with your application via a POST to the AccessLink users endpoint. This registration step creates the association between the Polar user account and your application in Polar's system. If you skip this step, subsequent data requests will fail even with a valid access token. Polar access tokens are long-lived and do not expire. This simplifies token management significantly compared to providers that require frequent refreshes. Store the access token securely per user and use it for all subsequent requests. If a user revokes access via the Polar Flow app or web service, the token becomes invalid and the user needs to re-authorize. ## The transaction model Polar AccessLink's transaction model is the most significant architectural difference from other wearable APIs. Data is not available via simple GET requests with date range parameters. Instead, you must work through a transaction lifecycle. To fetch new training sessions, you open a transaction for the exercise resource, list the available sessions within the transaction, fetch each session by its transaction-specific ID, and then commit the transaction. Only after committing does Polar mark those sessions as delivered and make subsequent new sessions available in future transactions. If you open a transaction and fail to commit (for example due to a processing error on your side), the same data will be available in the next transaction. This provides a form of at-least-once delivery guarantee. However, if you commit without successfully processing and storing the data, you will not be able to retrieve it again through the standard transaction flow. Separate transactions exist for different resource types: exercises, daily activity, sleep and physical information each have their own transaction streams. You must manage each independently. A robust implementation opens, processes and commits each transaction type as part of a scheduled sync job, handles errors before committing, and stores raw response payloads before processing to enable reprocessing if your parsing logic changes. ## HRV4T in product context The standardized nature of HRV4T measurements makes them unusually valuable for building HRV-based features. Because every measurement is taken using the same protocol (three minutes, lying down, at the same time of day), the data is comparable across days and across users in a way that continuous overnight HRV is not. This enables meaningful population-level analysis for coaching applications that serve multiple users. You can build personalized HRV baseline models using the user's own 60-90 day HRV history, flag days where morning HRV is more than one standard deviation below the user's baseline, and correlate HRV deviations with training load, sleep quality and life stress indicators. For individual user features, HRV4T trend analysis over rolling 7 and 28 day windows is the foundation of readiness-based training recommendations. A declining HRV trend over 7 days against a rising cumulative training load is a strong signal for an unplanned recovery day regardless of how the user reports feeling. ## Open Wearables and Polar Open Wearables implements the Polar AccessLink transaction model, handles the mandatory user registration step, manages long-lived token storage, and normalizes Polar data into the same schema used for Garmin, Whoop, Samsung Health, Suunto, Ultrahuman, Oura, Google Health Connect and Apple HealthKit. Polar-specific metrics like ANS Charge, Nightly Recharge and Training Effect are preserved in the normalized output as provider-specific extensions alongside the common fields (sleep duration, HRV, resting heart rate, workout distance and duration) that appear across all providers. Self-hosted, MIT licensed, no per-user fees. ## Faq ### Which Polar devices support HRV4T? HRV4T is available on Polar Vantage V2, Vantage M2, Ignite 2, Ignite 3, Pacer, Pacer Pro, Grit X2 Pro and other recent Polar devices. Older devices may not support the morning HRV measurement. Check Polar's device compatibility documentation for the current list. ### What happens if a transaction is left open without being committed? Polar will keep the transaction available but will not make new data accessible until the existing transaction is committed or rolled back. In practice, implement a rollback on any processing error, log the failure, and retry the transaction in the next sync cycle rather than leaving transactions open indefinitely. ### Does Polar AccessLink support webhooks? Polar AccessLink supports webhooks for new exercise notifications. When a user syncs a new workout from their device to Polar Flow, Polar can send a webhook to your configured endpoint. This reduces the need for constant polling but does not replace the transaction model: you still need to open and commit a transaction to actually fetch the exercise data after receiving the webhook. ### Can i access historical data for a user who just connected? Polar AccessLink provides access to data from the past 90 days at the time of user registration. Data older than 90 days is not available via the API. Plan your onboarding experience accordingly: inform users that their recent 90 days of data will be synced and do not promise access to older history. ### How is Nightly Recharge different from whoop's recovery score? Both metrics measure overnight physiological recovery using HRV as a primary input, but they differ in methodology and output. Polar's Nightly Recharge separates ANS Charge (HRV-based) and Sleep Charge (sleep staging-based) and reports them as distinct components alongside a combined status. Whoop's Recovery Score is a single composite score combining HRV, resting heart rate, respiratory rate and sleep performance into a percentage. Polar's split gives more diagnostic information; Whoop's single score is simpler to surface in a UI. ## Open Wearables Open Wearables is an open-source platform that connects your application to wearable and health data providers through a single API. One normalized data model, multi-provider support in a single self-hosted deployment, no per-user fees, MIT licensed, and health intelligence built in: normalized recovery, sleep, activity and biometric data ready for your product layer. We offer custom deployment and integration support through Momentum. If your team needs help getting to production faster, we can set up and configure Open Wearables as part of a managed engagement. [Let's talk](https://www.themomentum.ai/lets-talk). [Book a demo](https://openwearables.io/book) to see how Open Wearables fits your use case. ## Polar integration View the full [Polar integration documentation](https://openwearables.io/integrations/polar) on Open Wearables. ## See related articles [How to Access Polar Watch Data in Your Health App](https://openwearables.io/blog/how-to-access-polar-watch-data-in-your-health-app) [Garmin Connect API: Developer Guide for Activities and Health Metrics](https://openwearables.io/blog/garmin-connect-api-developer-guide-activities-health-metrics) [Strava API Developer Guide: Activities, Heart Rate and GPS Data](https://openwearables.io/blog/strava-api-developer-guide-activities-heart-rate-gps-data) ## Keep reading Polar · May 30, 2026 · 5 min read ### How to integrate Polar data into your health app The Polar API (AccessLink) requires OAuth, token management, and polling. Open Wearables abstracts all of that into a single sync endpoint with normalized output. Polar · May 3, 2026 · 7 min read ### How to access Polar watch data in your health app Polar's cardio versus muscle load split and ANS Charge from Nightly Recharge enable coaching features that most wearable APIs cannot support. Here's how to use them effectively. Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/samsung-health-api-galaxy-watch-data-for-developers # Samsung Health API: Galaxy Watch data for developers [All posts](https://openwearables.io/blog) [Samsung Health](https://openwearables.io/blog/category/samsung-health) Open Wearables Team · May 6, 2026 · 5 min read ## Key takeaways - Samsung Health Platform provides server-side API access to Galaxy Watch data including heart rate, sleep stages, workouts, stress score, SpO2, HRV and body composition. - Access requires applying to the Samsung Health Developer Program; approval is not automatic and typically takes one to two weeks. - Galaxy Watch 5 and later adds BIA-based body composition measurements; Galaxy Watch 6 and later adds nightly skin temperature. - Stress score is Samsung's distinctive contribution among Android wearables, using HRV analysis to produce a continuous daily stress indicator. - Open Wearables normalizes Samsung Health data alongside other providers into a unified schema. ## Introduction Samsung Health is one of the largest health data ecosystems in the Android world. Galaxy Watch devices are worn by tens of millions of users globally, and the platform tracks a comprehensive range of biometrics beyond what most wrist-based wearables offer. With Galaxy Watch 5's BIA sensor for body composition and Galaxy Watch 6's skin temperature tracking, Samsung has progressively closed the gap with ring-form-factor devices like Oura and Ultrahuman on recovery-focused metrics. For developers building health apps targeting Android users, Samsung Health is often the primary data source for users who do not have a dedicated fitness wearable. It aggregates from Galaxy Watch, Samsung Health app manual entries, and compatible third-party apps. The Samsung Health Platform API provides server-side access to this data after user authorization. The integration is not frictionless. Developer program approval is required, OAuth implementation is standard but the endpoint URLs are specific to Samsung's ecosystem, and the data schema reflects Samsung's own terminology and organization rather than an industry-standard model. ## What Samsung Health platform provides Exercise and activity data includes workout sessions for over 80 sport types: running, cycling, swimming, walking, strength training, yoga, basketball and many others. For each session you get duration, start and end time, calories burned, heart rate (average, maximum, and per-minute series for supported sessions), distance for sports where it applies, and GPS data where the user was outdoors with the watch. Daily health metrics represent the continuous monitoring data that Samsung Health collects between workouts. This includes step count and distance walked, continuous heart rate readings from the Galaxy Watch, HRV measured at intervals throughout the day, stress score derived from HRV analysis, SpO2 spot checks, and respiratory rate. Sleep records contain total sleep duration, time in each stage (awake, light, deep and REM), sleep score, sleep efficiency, and breathing irregularity detection which can flag potential snoring or sleep apnea indicators. Body composition is available from Galaxy Watch 5 and newer devices that include the BIA (bioelectrical impedance analysis) sensor. Measurements include body weight, BMI, body fat percentage, skeletal muscle mass, body water percentage and basal metabolic rate. Skin temperature is available on Galaxy Watch 6 and newer. Like Oura and Ultrahuman, Samsung records nightly skin temperature deviation from the user's personal baseline. ## The developer program Unlike Garmin, Strava or Whoop which offer self-serve developer access, Samsung Health Platform requires an application to their developer program before you receive API credentials. The application asks about your company, use case, data handling practices and integration plans. Approval typically takes five to fifteen business days. Applications for consumer health apps in well-defined categories tend to move faster than applications for clinical or research use cases. Applying early in your development cycle is recommended. Once approved, you receive a client_id and client_secret tied to your application. API credentials are environment-specific: you receive separate credentials for development and production. ## OAuth 2.0 and data access Samsung Health uses OAuth 2.0 with the standard authorization code flow. The authorization endpoint is on Samsung's account server, and the token endpoint is on Samsung's Health API server. The scopes map to data categories: r:exercise, r:sleep, r:health, r:profile, r:body. Token management is straightforward compared to providers with rotating refresh tokens or short expiry windows. Refresh Samsung tokens using the standard refresh grant when the access token expires. Store refresh tokens securely per user and handle 401 responses as a signal to attempt token refresh before re-authentication. ## Samsung-specific features Samsung's stress monitoring is one of the platform's most distinctive capabilities. The Galaxy Watch measures HRV continuously throughout the day when the user is stationary and not exercising. It translates HRV into a stress score on a 0-100 scale, categorized as low (0-25), normal (26-50), high (51-75) and very high (76-100). This continuous stress monitoring is not available from most wearable APIs. Whoop measures recovery overnight; Oura measures readiness as a morning composite. Samsung measures stress dynamically throughout the day, which enables different product features: intraday stress pattern tracking, correlation of stress peaks with specific activities or times of day, and long-term stress trend analysis. ## Open Wearables and Samsung Health Open Wearables handles Samsung Health developer program credentials, OAuth 2.0 token management and data normalization. Galaxy Watch metrics are mapped to a schema shared with Garmin, Whoop, Polar and other supported providers. For multi-provider apps targeting Android users, this means a user with a Galaxy Watch and a user with a Garmin Forerunner both produce normalized daily health summaries through the same API endpoint. Self-hosted, MIT licensed, $0 per user. ## Faq ### How long does Samsung developer program approval take? Typically five to fifteen business days. Apply early in your development cycle rather than waiting until implementation is ready. ### Is Samsung Health platform available in all countries? Samsung Health Platform availability varies by region. Check the Samsung developer portal for the current list of supported countries and any regional restrictions on data types. ### Can i access Samsung Health data from non-galaxy Android devices? The Samsung Health app runs on non-Samsung Android devices, but Galaxy Watch-specific metrics require Samsung hardware. Standard metrics like steps and heart rate from the phone's sensors may be available. ### How does samsung's stress score compare to other providers' recovery metrics? Samsung stress score and Whoop Recovery Score measure related but different constructs. Samsung measures intraday stress throughout the day using HRV. Whoop measures overnight recovery. They are complementary rather than competing metrics. ### Does Open Wearables support Samsung Health's body composition data? Open Wearables normalizes Samsung body composition data including body fat, muscle mass and BMI where available from Galaxy Watch 5+ measurements. ## Open Wearables Open Wearables is an open-source platform that connects your application to wearable and health data providers through a single API. One normalized data model, multi-provider support in a single self-hosted deployment, no per-user fees, MIT licensed, and health intelligence built in: normalized recovery, sleep, activity and biometric data ready for your product layer. We offer custom deployment and integration support through Momentum. If your team needs help getting to production faster, we can set up and configure Open Wearables as part of a managed engagement. [Let's talk](https://www.themomentum.ai/lets-talk). [Book a demo](https://openwearables.io/book) to see how Open Wearables fits your use case. ## Samsung Health integration View the full [Samsung Health integration documentation](https://openwearables.io/integrations/samsung-health) on Open Wearables. ## See related articles [How to Connect Samsung Health to Your App](https://openwearables.io/blog/how-to-connect-samsung-health-to-your-app) [Google Health Connect Integration: Android Health Data for Developers](https://openwearables.io/blog/google-health-connect-integration-android-health-data-for-developers) [How to Access Google Health Connect Data in Your Backend](https://openwearables.io/blog/how-to-access-google-health-connect-data-in-your-backend) ## Keep reading Samsung Health · Jun 6, 2026 · 4 min read ### Samsung Health API integration guide for Android developers Samsung Health API is not a cloud API. It requires an on-device SDK. Learn how Open Wearables Android SDK handles permissions, background sync, and normalization. Samsung Health · May 6, 2026 · 6 min read ### How to connect Samsung Health to your app The Samsung Health integration pipeline covers developer program application, OAuth 2.0, token management, data querying and normalization before you ship a single product feature. Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/samsung-health-api-integration-guide-android-developers # Samsung Health API integration guide for Android developers [All posts](https://openwearables.io/blog) [Samsung Health](https://openwearables.io/blog/category/samsung-health) Open Wearables Team · Jun 6, 2026 · 4 min read ## Key Takeaways - The Samsung Health API is not a cloud REST API. It is a device-side SDK that reads data stored locally on Samsung devices. - Samsung Health and Health Connect solve similar problems but cover different device populations. Use Samsung Health (`"samsung"`) for Samsung-specific deployments, and Health Connect (`"google"`) for broader Android 10+ coverage. - Open Wearables Android SDK handles the Samsung Health SDK connection, permission flow, background sync scheduling, token management, and data normalization. - Samsung Health coverage includes 20+ data types: steps, heart rate, HRV, SpO2, blood pressure, blood glucose, energy expenditure, body composition, temperature, workouts, and sleep. - Background sync is WorkManager-backed, surviving app restarts and respecting battery optimization. - Samsung Health is only available on Samsung devices. For non-Samsung Android devices, use the Health Connect provider. - The SDK requires Android 10 (API 29+), compile SDK 36, Kotlin 2.1.0+. ## The Core Problem: Samsung Health Is Not a Cloud API When developers first look for a Samsung Health API, they often expect something similar to other health platforms: an OAuth flow, a set of REST endpoints, a way to pull data server-side. Samsung Health does not work that way. Samsung Health stores data locally on the device. Access happens through the Samsung Health SDK, which communicates with the Samsung Health app via a local IPC connection. There is no cloud endpoint you can call. Your code needs to run on the device, with the user's explicit permission, and the Samsung Health app must be installed. This creates a specific integration pattern: you ship native Android code, that code syncs data to your backend, your backend reads the normalized data through your API. Every piece of complexity lives in step one. Open Wearables handles that entire step. ## Samsung Health vs Health Connect: Which One to Use **Health Connect** works on any Android 10+ device and covers 30+ data types. Provider ID in Open Wearables: `"google"`. **Samsung Health** works on Samsung devices only, covers 20+ data types. Provider ID: `"samsung"`. For most apps targeting a broad Android audience, Health Connect is the more practical starting point. Samsung Health makes sense when your user base is Samsung-specific. Open Wearables supports both through a unified interface. ## What Open Wearables Android SDK Does for You Without Open Wearables, Samsung Health API integration involves: adding the Samsung Health SDK, setting up the connection, handling connection state, building per-type permission flows, writing WorkManager background sync, normalizing Samsung-specific formats, implementing token refresh, and storing credentials securely. With Open Wearables, you add one dependency, generate a backend token, and call three SDK methods. ## Backend Setup: Generating a User Token ``` POST /api/v1/users/{user_id}/token X-Open-Wearables-API-Key: your_api_key ``` Returns `access_token` and `refresh_token`. Pass these to the Android client. Never embed `app_id` or `app_secret` in the mobile app. ## Android SDK: Installation and Setup **Add the dependency:** ``` // settings.gradle.kts maven { url = uri("https://jitpack.io") } // build.gradle.kts implementation("com.github.the-momentum:open-wearables-android-sdk:0.5.0") ``` Requirements: `minSdk = 29`, `compileSdk = 36`, Kotlin 2.1.0+. **Initialize in Application class:** ``` OpenWearables.init(context = this, baseUrl = "https://your-backend.com") ``` **Sign in and request Samsung Health permissions:** ``` sdk.signIn(accessToken = accessToken, refreshToken = refreshToken, userId = "user_123") sdk.requestAuthorization( activity = this, provider = "samsung", dataTypes = listOf("steps", "heart_rate", "hrv", "oxygen_saturation", "workout", "sleep") ) ``` **Start background sync:** ``` sdk.startBackgroundSync(provider = "samsung", syncDaysBack = 7) ``` ## Reading Data From Your Backend ``` GET /api/v1/users/{user_id}/timeseries GET /api/v1/users/{user_id}/events/workouts GET /api/v1/users/{user_id}/events/sleep ``` All timestamps are UTC. Units are canonical. Data from Samsung Health and Health Connect look identical in the response. ## Limitations Samsung Health is Samsung devices only. The SDK will not connect to Samsung Health on non-Samsung Android devices. The Samsung Health app must be installed and up to date. Older versions expose fewer data types. ## Quickstart ``` git clone https://github.com/the-momentum/open-wearables cd open-wearables docker compose up -d ``` API at `http://localhost:8000`. Auth via `X-Open-Wearables-API-Key`. MIT license, $0 per user. Note: Samsung Health requires a physical Samsung device. The SDK does not work on emulators. ## See Related Articles - [How to connect Samsung Health to your app](https://openwearables.io/blog/how-to-connect-samsung-health-to-your-app) - [How to access Google Health Connect data in your backend](https://openwearables.io/blog/how-to-access-google-health-connect-data-in-your-backend) - [How to integrate Apple Health data into your app](https://openwearables.io/blog/how-to-integrate-apple-health-data-into-your-app) - [How to sync wearable data from multiple devices](https://openwearables.io/blog/how-to-sync-wearable-data-from-multiple-devices) - [How to normalize wearable data across providers](https://openwearables.io/blog/how-to-normalize-wearable-data-across-providers) ## FAQ **Is there an official Samsung Health REST API I can call from my server?** No. Samsung Health does not expose a cloud API for third-party developers. Data access goes through the Samsung Health SDK on the device. **What happens if the user has both Samsung Health and Health Connect installed?** You can request authorization from both providers independently. The SDK treats `"samsung"` and `"google"` as separate data sources. If the user connects both, your backend may receive overlapping data for the same time window. **Does Open Wearables work on non-Samsung Android devices?** The Open Wearables Android SDK works on any Android 10+ device. Samsung Health specifically requires a Samsung device. On non-Samsung devices, use the `"google"` provider for Health Connect. **How does automatic token refresh work?** The SDK catches 401 responses, uses the stored refresh token to call the token endpoint, updates EncryptedSharedPreferences with the new token pair, and retries the failed request. This happens transparently. **How far back can I backfill Samsung Health data?** The `syncDaysBack` parameter in `startBackgroundSync()` controls the historical backfill depth. A value between 7 and 30 days is a reasonable starting point. ## Keep reading Samsung Health · May 6, 2026 · 6 min read ### How to connect Samsung Health to your app The Samsung Health integration pipeline covers developer program application, OAuth 2.0, token management, data querying and normalization before you ship a single product feature. Samsung Health · May 6, 2026 · 5 min read ### Samsung Health API: Galaxy Watch data for developers Samsung Health Platform provides server-side API access to Galaxy Watch data including heart rate, sleep stages, workouts, stress score, SpO2, HRV and body composition. Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/strava-api-developer-guide-activities-heart-rate-gps-data # Strava API 2026: developer guide to activities, heart rate and GPS data [All posts](https://openwearables.io/blog) [Strava](https://openwearables.io/blog/category/strava) Open Wearables Team · May 6, 2026 · 11 min read ## Key takeaways - **Strava API rate limits** are 100 requests per 15 minutes and 1,000 per day per athlete. Production apps with many users hit these limits quickly. - **App approval is required** for higher rate limits and detailed activity streams including GPS and granular sensor data. - **Strava access tokens expire after six hours**. You need an active token refresh strategy in your backend. - **Webhooks are the right sync model**: Strava pushes new activity events to your endpoint. Polling burns through rate limits. - **Strava does not provide sleep, HRV, or recovery data**. It is an activity platform, not a health monitoring platform. - **API dependency is a product risk**: Strava has tightened its developer program over time. Building on a single provider exposes your product to policy changes outside your control. - **Open Wearables** handles OAuth, token refresh, rate limit tracking, and webhooks for Strava, exposing data through the same unified endpoints as other providers. ## Introduction Strava has over 100 million users logging runs, rides, swims and hikes every day. For developers building fitness apps, coaching platforms or health dashboards, that volume of activity data is genuinely valuable. A user who logs every workout on Strava has months or years of structured training history: pace progression, power output, elevation trends, heart rate zones. For a coaching app, that's the foundation of any meaningful analysis. But connecting to Strava and keeping data flowing reliably in production is more engineering work than it initially appears. OAuth 2.0 is the starting point, not the finish line. Tokens expire every six hours and need to be refreshed proactively. Rate limits are enforced per athlete, not globally, which means you need per-user tracking in your infrastructure. Webhooks need a validated public endpoint before Strava will send you anything. And all of this needs to be running cleanly before you can even think about the product layer. This guide walks through what the Strava API actually provides, how authentication and rate limits work in practice, and what the real operational costs are when you move beyond a basic prototype. ## What the Strava API covers Strava's API is purpose-built for sports activities. It is not a general-purpose health data API. Understanding what it does and doesn't include upfront saves significant time when scoping an integration. Activity data you can access: Strava exposes structured data for every recorded activity. This includes the activity type (Strava supports over 80 sport types, from outdoor runs and rides to indoor rowing and virtual cycling), distance, duration, moving time, and elevation. For activities with heart rate monitors, you get average heart rate and max heart rate per session. For cycling with a power meter, you get watts, normalized power, weighted average power and intensity factor. For running, you get pace, splits per kilometer or mile, and cadence if the user's watch records it. Calories burned are available for all activity types. GPS data is one of Strava's strengths. Every outdoor activity with location tracking includes a full GPS trace encoded as a polyline, which you can decode to a sequence of latitude and longitude coordinates. This enables route visualization, elevation profiling and segment matching. Lap data is available for pool swims, track workouts and any activity where the user manually pressed the lap button. What Strava does not provide: Strava is an activity platform, not a recovery or health monitoring platform. It does not expose resting heart rate, heart rate variability, sleep data, body composition, stress scores or any continuous (non-workout) biometric data. If your app needs those signals, you need additional providers like Garmin, Whoop or Oura alongside Strava. ## Authentication and token management Strava uses OAuth 2.0 with the authorization code flow. Users are redirected to Strava's authorization page, approve access, and are redirected back to your app with a one-time authorization code. You exchange that code for an access token and a refresh token. The critical operational detail: Strava access tokens expire after six hours. This is significantly shorter than most other provider tokens. In practice, it means you cannot store an access token at connection time and use it later. You need a token refresh mechanism that checks expiry before every API call and refreshes automatically when the token is near expiration. Refresh tokens do not expire on a fixed schedule, but they are invalidated if the user deauthorizes your application in Strava's settings. Your code needs to handle 401 responses gracefully, detect deauthorization, and surface the appropriate re-authentication flow to users when it happens. The scopes you need depend on what data you're accessing. For reading non-private activities, request activity:read. For reading all activities including those the user has marked private, request activity:read_all. For basic profile information, request read. Requesting the minimum necessary scope improves authorization conversion rates since users see exactly what your app will access. ## Rate limits in production Strava enforces two rate limit windows: 100 requests per 15-minute window per athlete, and 1000 requests per day per athlete. These are independent limits and both apply simultaneously. Every API response includes X-RateLimit-Limit and X-RateLimit-Usage headers that tell you the current usage against both windows. In development with a single test account, rate limits feel generous. In production with real users who have years of activity history, the constraints become meaningful quickly. Consider the math: if you want to backfill six months of activities for a new user, and each user has been training five days per week, that's roughly 130 activities. Fetching activity summaries, then fetching per-activity stream data for GPS and heart rate, you could easily spend 260 or more API calls on initial sync for a single user. For ongoing sync, webhooks are the answer. Instead of polling for new activities on a schedule (which burns through rate limits), you subscribe to Strava's webhook events and receive a notification whenever a user creates, updates or deletes an activity. Your server fetches only the new or updated activity when notified. This keeps daily API usage low regardless of how active your users are. Strava returns HTTP 429 when a rate limit is exceeded. Implement exponential backoff with jitter for 429 handling, and make sure your webhook processing is asynchronous so a slow downstream operation doesn't time out the webhook delivery. ## Webhook setup Strava's webhook subscription requires a publicly reachable HTTPS endpoint that can respond to a validation challenge. During setup, Strava sends a GET request to your endpoint with a hub.challenge parameter. Your server must respond with that value. Only after successful validation does Strava start sending event notifications. Event payloads are lightweight. They include the activity ID, the athlete ID, the event type (create, update, delete) and a timestamp. They do not include the activity data itself. Your handler receives the notification, identifies which user the athlete ID corresponds to, and then makes a separate API call to fetch the full activity. ``` @app.route('/strava/webhook', methods=['GET', 'POST']) def strava_webhook(): if request.method == 'GET': return jsonify({'hub.challenge': request.args.get('hub.challenge')}) event = request.json if event['aspect_type'] == 'create' and event['object_type'] == 'activity': sync_activity.delay(event['owner_id'], event['object_id']) return '', 200 ``` Keep the webhook handler response time under two seconds. Queue the actual data fetching asynchronously using Celery, RQ or any task queue. Strava will retry delivery if your endpoint returns a non-200 response, so make activity processing idempotent. ## Strava's developer program and access restrictions Strava's developer program has moved toward tighter access controls over time. Understanding what requires approval before you start building saves time later. ### What is available by default Under the default developer tier, you can read activity summaries, athlete profiles, and segment data. Basic activity metadata (type, distance, duration, start time) is available without any special approval. ### What requires approval Applications that need higher rate limits or access to detailed activity streams must apply through Strava's developer program. Streams include per-second GPS coordinates, heart rate, power, cadence, and altitude. If your use case involves training analysis, route mapping, or any feature that needs granular sensor data, plan for the approval process before committing to that data dependency. The approval criteria are not fully documented and approval is not guaranteed. Strava evaluates applications based on use case, expected user base, and how you intend to handle the data. ### Building without single-provider dependency Strava has changed its developer program terms multiple times. Rate limits have been adjusted. Webhook access has narrowed. Data that was available without approval has moved behind approval gates. This pattern is not unique to Strava: it is the standard risk of building a product feature on top of a single third-party API. The structural answer is abstraction. If your product queries a normalized data layer rather than Strava directly, policy changes affect the integration layer, not your application logic. A user who connects Garmin instead of Strava still produces workout data in the same format. Your product keeps working regardless of what any single provider changes. ## Strava API changes in 2026: what broke and what still works Strava made its most significant changes to the developer program in mid-2026. Here is what actually changed and what it means if you are building on the API today. ### What changed In June 2026, Strava restructured access into two tiers. Standard Tier gives up to 10 users and higher rate limits than before, with no approval queue, but requires an active Strava subscription from the developer. Extended Access Tier covers larger user bases and priority support, and requires a separate application process. Three endpoints are being retired on 1 September 2026: Club Activities, Club Administrators, and Club Members. Segments Explore is also moving behind the Extended Access gate. If your app used any of these, you need to migrate before that date. The change that hit the open-source ecosystem hardest is the ban on third-party intermediary platforms routing Strava data. Strava explicitly blocked apps that accessed the API through middleware or aggregator layers. The official reasoning was a 448% increase in registered apps, with AI companies and scrapers cited as the main abuse vectors. From June 2027, two further breaking changes take effect: tokens must be passed in headers (not query parameters), and the base URL changes from api.strava.com to www.api-v3.strava.com. ### What still works Standard activity data, including distance, duration, heart rate, GPS streams, power, and cadence, is still accessible for authenticated users with no approval required under Standard Tier. Webhooks still work and remain the right approach for production apps. The OAuth flow is unchanged. ### What this means in practice If you are building a personal tool or a small app for under 10 users, Standard Tier actually gives you more headroom than before. If you are building something at scale, you need Extended Access approval, and Strava has not published clear criteria for what gets approved. The deeper problem is predictability. Strava has changed its program terms three times in the past two years. Each change required developers to audit integrations, update endpoints, and in some cases rebuild features entirely. Building a product that depends on a single fitness platform's API goodwill is an architecture risk, not just a compliance task. Open Wearables abstracts this: your app connects once to the Open Wearables API, and the Strava integration layer handles token management, endpoint changes, and rate limit logic on your behalf. When Strava updates its base URL in June 2027, you do not need to touch your code. ## Data normalization across providers If Strava is one of several providers your app supports, data normalization becomes a significant design concern. Strava's activity schema is specific to Strava: field names, units, and data structures differ from Garmin, Polar or other providers. Your product layer should not depend on provider-specific schemas. The practical approach is a canonical activity model in your database. Define what an activity looks like in your system: sport type, start time, duration, distance, heart rate, elevation, GPS coordinates. Map each provider's output to that canonical model at ingestion time. Your product code only ever reads from the canonical model, never from provider-specific data. This pays dividends when you add a new provider. Strava users who also have a Garmin device should see their training history in one unified view, not siloed by device. ## Open Wearables and Strava Open Wearables is an open-source platform that handles Strava's OAuth flow, token refresh, rate limit tracking and webhook management alongside eight other providers in a single self-hosted deployment. When a user connects Strava through Open Wearables, the platform manages the OAuth exchange, stores tokens securely, registers the webhook subscription, and handles incoming activity events. Your application queries a single normalized API endpoint and receives activity data in a consistent schema regardless of whether it came from Strava, Garmin or Polar. The platform is MIT licensed, self-hosted via Docker Compose or Railway. Your infrastructure costs are the only costs: typically $200 to $500 per month for a startup-scale deployment regardless of user count. ## Faq ### Does the Strava API provide sleep or HRV data? No. Strava is an activity platform. It does not expose sleep, resting heart rate, HRV, recovery scores or any continuous biometric data. For those signals, you need providers like Whoop, Oura, Garmin or Apple Health. ### How do strava's rate limits work across a large user base? Rate limits are per athlete, not global. 1000 requests per day per athlete means a user base of 10,000 users gives you 10 million daily requests across all users combined. The constraint is usually initial sync for new users with large activity histories, not ongoing operations. ### Can i access data without the user re-authenticating? Yes, as long as you store and refresh the refresh token correctly. The refresh token remains valid until the user explicitly deauthorizes your app in Strava's connected applications settings. ### What scopes do i need? For most use cases: activity:read_all to access all activities including private ones, and read for basic athlete profile information. Request only what you need. ### Does Strava support bulk activity export? There is no bulk export endpoint. Fetch the activity list via GET /athlete/activities with pagination, then fetch individual activities as needed. For initial sync, this means multiple API calls. Budget your rate limit accordingly and spread backfill across multiple days if the user has a large history. ## Open Wearables Open Wearables is an open-source platform that connects your application to wearable and health data providers through a single API. One normalized data model, multi-provider support in a single self-hosted deployment, no per-user fees, MIT licensed, and health intelligence built in: normalized recovery, sleep, activity and biometric data ready for your product layer. We offer custom deployment and integration support through Momentum. If your team needs help getting to production faster, we can set up and configure Open Wearables as part of a managed engagement. [Let's talk](https://www.themomentum.ai/lets-talk). [Book a demo](https://openwearables.io/book) to see how Open Wearables fits your use case. ## Strava integration View the full [Strava integration documentation](https://openwearables.io/integrations/strava) on Open Wearables. ## See related articles - [What wearable app development actually looks like in 2026](https://openwearables.io/blog/what-wearable-app-development-actually-looks-like-in-2026) - [The wearable app development checklist: what you actually need to build (and what you don't)](https://openwearables.io/blog/wearable-app-development-checklist) [How to Integrate Strava Without Building OAuth From Scratch](https://openwearables.io/blog/how-to-integrate-strava-without-building-oauth-from-scratch) [Whoop API: Recovery, Strain and Sleep Data for Developers](https://openwearables.io/blog/whoop-api-recovery-strain-sleep-data-for-developers) [Garmin Connect API: Developer Guide for Activities and Health Metrics](https://openwearables.io/blog/garmin-connect-api-developer-guide-activities-health-metrics) ## Keep reading Strava · May 4, 2026 · 5 min read ### How to integrate Strava without building OAuth from scratch Building a production Strava integration means writing OAuth, token refresh, webhooks and rate limit logic before shipping any product. Here's what that actually takes, and a simpler path. Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. Guides · Oct 26, 2026 · 9 min read ### Moving from a hosted wearable API to Open Wearables: a migration playbook Moving from a hosted wearable API to Open Wearables is usually a re-integration rather than a data migration. This playbook walks through the decisions, the steps in order, how your users reconnect and what to tell your security team. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/strava-api-integration-guide-health-fitness-apps # Strava API integration guide for health and fitness apps [All posts](https://openwearables.io/blog) [Guides](https://openwearables.io/blog/category/guides) Open Wearables Team · Jun 1, 2026 · 4 min read ## Key Takeaways - Integrating the Strava API directly requires building OAuth 2.0 authorization, token refresh logic, rate limit handling, and data normalization before you write a single line of product code. - Open Wearables abstracts the entire Strava API integration into three API calls: authorize, sync, and read. - Strava is activity-focused only. It does not provide sleep data, HRV, or continuous 24/7 metrics. - Open Wearables supports Strava alongside Garmin, Polar, Suunto, Whoop, Fitbit, and Ultrahuman through the same unified interface. - Strava setup requires only a free Strava account. There is no developer program approval process. - The stack is MIT-licensed, self-hosted, and has no per-user fees. - Workout data from Strava maps to 50+ activity types in canonical units (bpm, meters, Celsius, UTC). ## What You Actually Have to Build When Integrating the Strava API Directly If you decide to integrate the Strava API without an abstraction layer, the scope of work tends to surprise developers new to fitness API integrations. The Strava API uses OAuth 2.0. That part is standard. But OAuth means you need a working redirect URI, a server-side token exchange flow, and persistent storage for access and refresh tokens. Strava access tokens expire after six hours, so you need a proactive or on-demand refresh mechanism. If a refresh fails at 3am, you need error handling and retry logic that does not silently drop a user's data. Once you have tokens, you are hitting Strava's activity endpoints. The response shape is Strava's own schema: fields like `moving_time`, `elapsed_time`, `total_elevation_gain`, `average_heartrate`. If your app also connects to Garmin or Polar, every provider has a different schema. You end up writing a normalization layer that maps each provider's field names, units, and timestamp formats into your internal model. Then there is rate limiting. Strava enforces per-15-minute and per-day request limits. You need queuing, backoff logic, and instrumentation to avoid hitting those limits in production. For a complete breakdown of what changed in the Strava developer program in 2026, including the new access tiers, retired endpoints, and breaking changes coming in 2027, read the [Strava API 2026 developer guide](https://openwearables.io/blog/strava-api-developer-guide-activities-heart-rate-gps-data). ## What Open Wearables Does for You Open Wearables is a self-hosted, open source layer that handles the full Strava API integration, plus other providers, through a single interface. The authentication flow is standardized. You redirect your user to: ``` GET /api/v1/oauth/strava/authorize?user_id={id}&redirect_uri={url} ``` Open Wearables handles the OAuth exchange with Strava, stores the tokens, and manages refresh automatically. Token refresh, rate limit handling, and retry logic live inside Open Wearables. You do not implement them. All data is returned in canonical units regardless of source. Heart rate in bpm, distance in meters, timestamps in UTC. When you add a second provider later, your data model does not change. ## The Strava Limitation You Need to Know Before You Build Strava is an activity tracking platform. It is not a health platform. Strava does not provide: sleep data, HRV, or continuous 24/7 metrics. If your app needs any of those, Strava alone is not sufficient. You would need to pair it with Whoop, Garmin, or Polar. Open Wearables supports all of them through the same API, so you can add providers incrementally. What Strava does cover is workouts. If your use case is fitness activity tracking, training load analysis, or exercise history, Strava is a strong source. ## Setting Up Strava in Open Wearables Strava setup is straightforward compared to some other providers. You need a Strava account (free tier is sufficient) and a Strava API application created at strava.com/settings/api. There is no developer program approval process. ``` git clone https://github.com/the-momentum/open-wearables.git cd open-wearables docker compose up -d ``` The API is available at `http://localhost:8000`. All requests use the `X-Open-Wearables-API-Key` header. ## Authorizing a User ``` GET /api/v1/oauth/strava/authorize?user_id={your_user_id}&redirect_uri={your_callback_url} ``` Open Wearables redirects the user to Strava's authorization page. After the user grants access, Strava redirects back through Open Wearables to your `redirect_uri`. The tokens are stored internally. ## Syncing and Reading Data ``` POST /api/v1/providers/strava/users/{user_id}/sync ``` To read workout data: ``` GET /api/v1/users/{user_id}/events/workouts GET /api/v1/users/{user_id}/timeseries ``` The response is the same schema whether the data came from Strava, Garmin, or any other connected provider. ## See Related Articles - [How to integrate Strava without building OAuth from scratch](https://openwearables.io/blog/how-to-integrate-strava-without-building-oauth-from-scratch) - [How to sync wearable data from multiple devices](https://openwearables.io/blog/how-to-sync-wearable-data-from-multiple-devices) - [How to normalize wearable data across providers](https://openwearables.io/blog/how-to-normalize-wearable-data-across-providers) - [Wearable API integration: comparing SaaS, custom build, and open source](https://openwearables.io/blog/wearable-api-integration-saas-custom-build-open-source) - [Garmin Connect API: developer guide](https://openwearables.io/blog/garmin-connect-api-developer-guide-activities-health-metrics) ## FAQ **Does Strava provide sleep data through the Strava API?** No. Strava is an activity tracking platform. It does not collect or expose sleep data, HRV, or continuous 24/7 health metrics. **Do I need a paid Strava account or developer program approval?** No. A free Strava account is sufficient. You create an API application at strava.com/settings/api to get your credentials. **How does Open Wearables handle Strava token refresh?** Strava access tokens expire after six hours. Open Wearables handles token refresh automatically using the stored refresh token. Your application does not need to implement refresh logic. **What activity types does Strava return through Open Wearables?** Open Wearables maps Strava activity data to a unified workout schema covering 50+ activity types including runs, rides, swims, hikes, and strength workouts in canonical units. **What happens if a user revokes Strava access?** Subsequent sync calls will fail with an authentication error. Your app should handle this by prompting the user to re-authorize via the OAuth endpoint. ## Keep reading Guides · Oct 26, 2026 · 9 min read ### Moving from a hosted wearable API to Open Wearables: a migration playbook Moving from a hosted wearable API to Open Wearables is usually a re-integration rather than a data migration. This playbook walks through the decisions, the steps in order, how your users reconnect and what to tell your security team. Guides · Oct 26, 2026 · 7 min read ### Why teams move from a hosted wearable API to Open Wearables A hosted wearable API is a sensible way to start. As a product grows, the questions change: whose provider apps, whose cloud, whose schema. Here is why teams move to Open Wearables, what they get after the move, and what it asks of them. Guides · Jul 28, 2026 · 5 min read ### How Wearable Data Flows From Device to Your API: A Complete Architecture Guide Wearable data does not go directly from device to your API. It flows through the provider cloud, then Open Wearables, then PostgreSQL, then your application. Here is what each step looks like. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/suunto-api-accessing-watch-data-for-developers # Suunto API: accessing watch data for developers [All posts](https://openwearables.io/blog) [Suunto](https://openwearables.io/blog/category/suunto) Open Wearables Team · May 2, 2026 · 7 min read ## Key takeaways - Suunto API provides workout data for over 80 sport types with GPS, altitude metrics, heart rate time series, Training Effect and VO2 max. - Altitude data is Suunto's most distinctive contribution: cumulative ascent and descent, altitude profiles for trail runs and hikes, and barometric altitude from the device sensor. - Suunto API uses a subscription and polling model rather than webhooks. You register for activity notifications and poll for new data on a schedule. - Developer access to the Suunto API requires registering an application through the Suunto developer portal. The process is straightforward but gated. - Suunto focuses on training and outdoor sport data and does not provide the sleep or recovery metrics available from Polar, Whoop or Oura. Pair Suunto with a recovery-focused provider in multi-provider architectures. - Open Wearables normalizes Suunto workout data alongside other supported providers. ## Introduction Suunto has been making sports watches for outdoor and endurance athletes since the late 1990s. Their devices are built for trail running, mountaineering, swimming, cycling and other activities where durability, GPS accuracy and altitude tracking matter. The Suunto app ecosystem reflects this focus: it is built around training sessions and outdoor sport rather than continuous health monitoring. The Suunto API, officially called the Suunto App API, provides developer access to workout data synced by Suunto users. If you are building an application for endurance athletes, mountain sports enthusiasts or anyone who trains outdoors, Suunto data is likely a required integration. The outdoor sport demographic that uses Suunto devices is distinct from the Garmin Forerunner user base (more focused on road running and triathlon) and from the Polar user base (more focused on heart rate and training load analysis). What Suunto offers that other providers do not is depth in altitude data. Barometric altitude measurements, cumulative ascent and descent per session, altitude profiles for GPS-tracked workouts, and detailed elevation-corrected pace and effort metrics are all available. For products serving trail runners, hikers, alpinists or cyclists in hilly terrain, this is the most relevant data stream available from any consumer wearable API. ## What the Suunto API provides Workout sessions include sport type, start time, duration, distance, GPS track, heart rate time series (where the user wore an optical HR sensor or a Bluetooth chest strap), ascent and descent in meters, average and maximum altitude, calories, average pace and speed, Training Effect for aerobic and anaerobic adaptation, and VO2 max estimate for run and cycle sport types. GPS data is available as a coordinate track with timestamps and altitude values at each point. For trail activities, this produces a full 3D route trace. The sampling interval depends on the user's GPS accuracy setting on the device: best mode records more frequently, good battery mode records less frequently. Heart rate data is included in the session record when the user has a heart rate source paired to the watch. For pool swimming, heart rate monitoring during the swim may not be available due to water interference with optical sensors. Suunto's FusedHeart technology attempts to mitigate this for open water and some pool scenarios. Training Effect is Suunto's implementation of Firstbeat's training adaptation scoring. Aerobic Training Effect (1-5 scale) indicates the session's impact on aerobic fitness. Anaerobic Training Effect (1-5 scale) indicates the session's impact on anaerobic capacity and lactate threshold. These scores are available for running and cycling sport types on devices that support the feature. Daily activity and sleep data are not available through the Suunto API. Suunto devices with sleep tracking (introduced in the Suunto Race and newer models) store sleep data in the app but this data is not exposed via the developer API as of the time of writing. Plan your application architecture accordingly: Suunto data covers training sessions only. ## Developer registration and OAuth Register your application at developer.suunto.com. The registration form requires an application name, description and redirect URI. You receive a client_id and client_secret after registration. The process does not require a lengthy review period, but Suunto may contact you if your application description raises questions about data usage. Suunto uses OAuth 2.0 with the authorization code flow. The authorization endpoint is at Suunto's account server. After the user authorizes your application, they are redirected to your redirect URI with an authorization code. Exchange the code for an access token and a refresh token at the Suunto token endpoint. Refresh tokens are long-lived. Access tokens expire after a shorter period and should be refreshed using the refresh grant. Store both tokens securely per user and handle 401 responses by attempting a token refresh before prompting the user to re-authorize. ## The subscription and polling model Suunto's API uses a subscription model for data delivery. You register your application's callback URL (or use the polling endpoint) to receive notifications when new workout data is available. When a Suunto user syncs their watch to the Suunto app, a notification is sent to your registered endpoint containing the workout ID. After receiving a workout notification, fetch the full workout details using the workout ID. The notification payload itself is minimal; the actual workout data including GPS, heart rate and altitude is retrieved in a separate request to the workouts endpoint. If you prefer not to manage a webhook endpoint, poll the workouts list endpoint on a schedule (once per hour is sufficient) using a last-synced timestamp as a cursor. This polling approach is more robust for development and small-scale deployments where webhook delivery reliability is harder to guarantee. ## Altitude data in product context Suunto's altitude data is the primary reason to prioritize this integration for outdoor sport products. Cumulative ascent (total meters climbed during a session) and descent (total meters descended) are the key metrics for trail running load quantification. A 10-kilometer run with 500 meters of ascent is significantly harder than a 10-kilometer flat run, and most training load models that only use heart rate and duration do not account for this adequately. Building altitude-aware training load models requires normalizing the elevation factor. A common approach is grade-adjusted pace: the GPS track and altitude profile are combined to compute what flat-road pace an equivalent effort would represent, removing the terrain variable from pace-based training analysis. For visual product features, the altitude profile (altitude versus distance or time from the GPS track) is a compelling and informative chart for trail runners and hikers reviewing their sessions. It contextualizes heart rate data: elevated heart rate at the top of a major climb is expected, not alarming. ## Open Wearables and Suunto Open Wearables handles Suunto OAuth token management, the subscription notification model and data normalization. Suunto workout data including altitude metrics, GPS tracks and Training Effect scores is normalized to the common schema alongside data from Garmin, Polar, Whoop and other supported providers. Altitude-specific fields are preserved as provider-specific extensions in the normalized output. For multi-provider apps serving outdoor athletes, this means Suunto users and Garmin users produce comparable workout summaries through the same pipeline. Self-hosted, MIT licensed, no per-user fees. ## Faq ### Does Suunto API provide sleep data? Sleep tracking is available on some newer Suunto devices, but sleep data is not currently exposed via the Suunto developer API. If your application needs sleep and recovery data alongside workout data for Suunto users, integrate a complementary provider such as Oura, Whoop or Polar for recovery metrics. ### How does suunto's training effect compare to polar's? Both Suunto and Polar license Firstbeat Analytics technology for Training Effect scoring. The methodology is the same: a 1-5 scale for aerobic and anaerobic effect derived from heart rate response data. The scores are comparable across the two platforms for the same user and sport type. ### What sport types does Suunto track? Suunto supports over 80 sport modes including trail running, road running, cycling, mountain biking, swimming (pool and open water), hiking, mountaineering, skiing and snowboarding (downhill and cross-country), paddling, gym and many others. Sport type is encoded as a string identifier in the workout response. ### Is altitude data from barometric sensors or GPS altitude? Suunto devices with a barometric altimeter (most Suunto 9, Suunto Race and Vertical series devices) use the barometric sensor for altitude measurement, which is more accurate than GPS altitude for cumulative ascent and descent calculations. GPS altitude data is used as a fallback on devices without a barometric sensor and for position accuracy. The API does not explicitly distinguish which source was used, but devices with barometric sensors produce more accurate altitude profiles. ## Open Wearables Open Wearables is an open-source platform that connects your application to wearable and health data providers through a single API. One normalized data model, multi-provider support in a single self-hosted deployment, no per-user fees, MIT licensed, and health intelligence built in: normalized recovery, sleep, activity and biometric data ready for your product layer. We offer custom deployment and integration support through Momentum. If your team needs help getting to production faster, we can set up and configure Open Wearables as part of a managed engagement. [Let's talk](https://www.themomentum.ai/lets-talk). [Book a demo](https://openwearables.io/book) to see how Open Wearables fits your use case. ## Suunto integration View the full [Suunto integration documentation](https://openwearables.io/integrations/suunto) on Open Wearables. ## See related articles [How to Integrate Suunto Data Into Your Training App](https://openwearables.io/blog/how-to-integrate-suunto-data-into-your-training-app) [Garmin Connect API: Developer Guide for Activities and Health Metrics](https://openwearables.io/blog/garmin-connect-api-developer-guide-activities-health-metrics) [Polar API: Training, HRV and Nightly Recharge Data](https://openwearables.io/blog/polar-api-training-hrv-nightly-recharge-data) ## Keep reading Suunto · Jun 2, 2026 · 6 min read ### How to integrate Suunto data into your health app The Suunto API provides workouts and 24/7 continuous monitoring. Open Wearables handles OAuth, polling, and normalization so you query one endpoint instead of building provider logic. Suunto · May 4, 2026 · 6 min read ### How to integrate Suunto data into your training app Suunto's altitude metrics and Training Effect scores enable outdoor sport features no other major wearable API covers with comparable depth. Here's how to use them in a product. Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/ultrahuman-api-ring-data-cgm-recovery-metrics # Ultrahuman API: ring data, CGM and recovery metrics [All posts](https://openwearables.io/blog) [Ultrahuman](https://openwearables.io/blog/category/ultrahuman) Open Wearables Team · May 5, 2026 · 6 min read ## Key takeaways - Ultrahuman Ring AIR provides Recovery Score, Sleep Score, Movement Index, HRV, resting heart rate, skin temperature deviation and nightly blood oxygen. - Ultrahuman's optional CGM (M1 patch) adds continuous blood glucose data, making it the only consumer wearable ecosystem that combines ring biometrics with glucose monitoring in a single API. - The Ultrahuman API is a REST API with OAuth 2.0 authentication. Access requires applying to the developer program, as credentials are not self-serve. - Skin temperature deviation from personal baseline is a nightly metric that provides recovery and illness onset signals comparable to Oura's temperature feature. - Open Wearables normalizes Ultrahuman data alongside other supported providers and preserves CGM glucose data in the normalized output. ## Introduction Ultrahuman is a metabolic health platform built around the Ring AIR wearable and an optional continuous glucose monitor (CGM) called the M1. The combination is unusual in the consumer wearable market: most wearables focus either on fitness performance or sleep quality, while Ultrahuman's design positions metabolic health (how the body processes food and regulates blood sugar) alongside recovery metrics. The ring form factor captures data during sleep with high accuracy because rings stay on during the night more reliably than wrist devices. Ultrahuman Ring AIR measures HRV, heart rate, skin temperature, SpO2 and movement. The CGM patch, worn on the arm for up to 14 days, measures interstitial glucose continuously throughout the day and night. For developers, Ultrahuman's combination of ring biometrics and optional glucose data represents a dataset with no equivalent in other consumer wearable APIs. Building features that correlate meal timing, glucose response and overnight recovery is only possible if you have access to both data streams, and Ultrahuman is the only platform that provides both through a single integration. ## What the Ultrahuman API provides Daily recovery data includes the Recovery Score (0-100 composite based on HRV, resting heart rate and sleep quality), resting heart rate, HRV (rMSSD), cardiovascular load from the previous day's activity and sleep metrics including total sleep duration, sleep efficiency and time in each sleep stage. Sleep data covers total sleep duration, sleep onset time, wake time, time in light, deep and REM sleep, sleep efficiency percentage, number of wake events, Sleep Score, heart rate during sleep, HRV during sleep and breathing rate during sleep. Sleep temperature deviation is reported as a delta from the user's personal baseline, derived from multiple weeks of nightly measurements. Movement data tracks steps, active calories, inactive periods (described as Workout Index and Movement Index in Ultrahuman's terminology), and periods of inactivity that the app flags as sedentary time to address. Glucose data from the M1 CGM patch is available for users who have used or are using the CGM. The data includes timestamped glucose readings at approximately five-minute intervals (in mg/dL or mmol/L depending on the user's regional setting), glucose variability metrics and Ultrahuman's proprietary metabolic score derived from meal response patterns. ## Developer program and API access Ultrahuman API access is not self-serve. You must apply to the developer program through Ultrahuman's developer documentation or partnership channel. The application requires information about your use case, user base and how you intend to use the data. Approval timelines are not publicly specified. Applications for legitimate health and wellness use cases have been processed within one to two weeks in practice. Contact Ultrahuman directly if your application is time-sensitive. Ultrahuman uses OAuth 2.0 with the authorization code flow. Once a user authorizes your application, you receive an access token and a refresh token. Access tokens expire and must be refreshed using the refresh token. Ultrahuman refresh tokens rotate on use: each time you exchange a refresh token for a new access token, you receive a new refresh token. Store the latest refresh token and discard the previous one after each exchange. ## Skin temperature data Ultrahuman's nightly skin temperature is reported as a deviation from the user's personal baseline rather than an absolute temperature in degrees. The baseline is established over the first two to three weeks of ring usage by averaging nightly temperatures. Deviations are expressed as positive or negative deltas. A consistently positive deviation of half a degree or more above baseline can indicate elevated physiological stress from illness, overtraining or hormonal cycle phase (for female users, temperature rises during the luteal phase are normal and expected). A consistently negative deviation may indicate caloric restriction or cold environment effects. For product purposes, surface temperature deviation as a trend signal in combination with Recovery Score. A user with a declining Recovery Score and elevated temperature deviation has a stronger case for a rest day than a user with a low Recovery Score and neutral temperature. ## Glucose data in a biometric context CGM data from Ultrahuman's M1 patch is available as a time series of glucose readings. The patch is worn for up to 14 days. After the patch expires, glucose data stops until the user applies a new patch. Not all Ultrahuman users use the CGM; it is a separate purchase from the ring. When glucose data is available, it enables correlations that ring data alone cannot support. High post-meal glucose spikes are associated with disrupted sleep in research literature. Users who experience nocturnal glucose dips may have worse sleep quality and worse Recovery Scores. These correlations are observable in the data when you have both glucose time series and overnight biometric data for the same user. Handle CGM data as an optional enhancement in your data pipeline. Design your schema to accept glucose time series when available without breaking features that depend only on ring data. Gate glucose-specific product features on a check for available CGM data in the user's history. ## Open Wearables and Ultrahuman Open Wearables handles Ultrahuman OAuth token management including rotating refresh token handling, developer program credentials, and data normalization. Ring biometric data is mapped to the common schema shared across all providers. CGM glucose data is preserved as a provider-specific extension in the normalized output. For health apps targeting metabolic health, Ultrahuman support through Open Wearables provides the only consumer wearable integration that delivers both recovery biometrics and continuous glucose data through a single normalized pipeline. Self-hosted, MIT licensed, no per-user fees. ## Faq ### Is CGM data available for all Ultrahuman users? No. The M1 CGM patch is a separate product from the Ring AIR. Users must purchase and use the CGM patch to generate glucose data. When building features that depend on glucose data, always check for data availability before attempting to display glucose-based features. ### How accurate is ultrahuman's sleep staging compared to polysomnography? Consumer wearable sleep staging uses heart rate, HRV, movement and skin temperature to infer sleep stages. It is meaningfully less accurate than clinical polysomnography. Ring-based devices generally outperform wrist-based devices for sleep metrics because the ring remains stationary during sleep more reliably. For product purposes, treat sleep stage data as directionally accurate trend data rather than clinical-grade measurements. ### What happens when a user's CGM patch expires? When a CGM patch expires, glucose readings stop. The API will not return glucose data for dates after the patch expiry until a new patch is activated. Handle this gracefully by detecting gaps in glucose data and updating your UI to reflect that metabolic monitoring is temporarily unavailable rather than displaying an error. ### Does Ultrahuman API provide workout data? Ultrahuman Ring AIR is not primarily a workout tracker. The ring does not have GPS. Workout data in the Ultrahuman app is primarily heart-rate-based session tracking rather than the detailed training metrics available from Garmin or Polar. If your application needs detailed workout data, plan to pair Ultrahuman with a separate workout provider in your multi-provider architecture. ## Open Wearables Open Wearables is an open-source platform that connects your application to wearable and health data providers through a single API. One normalized data model, multi-provider support in a single self-hosted deployment, no per-user fees, MIT licensed, and health intelligence built in: normalized recovery, sleep, activity and biometric data ready for your product layer. We offer custom deployment and integration support through Momentum. If your team needs help getting to production faster, we can set up and configure Open Wearables as part of a managed engagement. [Let's talk](https://www.themomentum.ai/lets-talk). [Book a demo](https://openwearables.io/book) to see how Open Wearables fits your use case. ## Ultrahuman integration View the full [Ultrahuman integration documentation](https://openwearables.io/integrations/ultrahuman) on Open Wearables. ## See related articles [Building With Ultrahuman Data: Recovery, Sleep and Glucose](https://openwearables.io/blog/building-with-ultrahuman-data-recovery-sleep-glucose) [Oura API: Accessing Ring Data, Sleep, HRV and Readiness](https://openwearables.io/blog/oura-api-accessing-ring-data-sleep-hrv-readiness) [Whoop API: Recovery, Strain and Sleep Data for Developers](https://openwearables.io/blog/whoop-api-recovery-strain-sleep-data-for-developers) ## Keep reading Ultrahuman · May 5, 2026 · 6 min read ### Building with Ultrahuman data: recovery, sleep and glucose Ultrahuman's combination of ring biometrics and optional CGM glucose data enables product features no other single platform supports. Here's how to build with it effectively. Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. Guides · Oct 26, 2026 · 9 min read ### Moving from a hosted wearable API to Open Wearables: a migration playbook Moving from a hosted wearable API to Open Wearables is usually a re-integration rather than a data migration. This playbook walks through the decisions, the steps in order, how your users reconnect and what to tell your security team. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/wearable-api-integration-saas-custom-build-open-source # Wearable API integration: comparing SaaS, custom build, and open source [All posts](https://openwearables.io/blog) [Guides](https://openwearables.io/blog/category/guides) Bartosz Michalak · May 14, 2026 · 7 min read You're building a health or fitness product. You need wearable data: sleep from Garmin, recovery from Whoop, training load from Polar. At some point, you have to decide how to get that data into your product. There are three ways to do it. Each has a different cost structure, a different engineering footprint, and a different ceiling. This article maps out all three so you can make the right call for your stage and your team. ## The three approaches **SaaS vendors** (Terra, Spike, Sahha, Rook, Junction) give you a hosted API layer. You connect your product to their service, and they handle OAuth flows, data normalization, and delivery. Fast to start, but the bill follows your usage and your data lives on their infrastructure. **Custom builds** mean going directly to each device provider's API and implementing OAuth, webhooks, token refresh logic, and data normalization yourself. Full control, but expensive in engineering time. **Open source** (Open Wearables) is a self-hosted platform you deploy on your own infrastructure. You own the data and the code, and what you pay for is the infrastructure it runs on. ## Option 1: SaaS wearable API vendors The managed API vendor market has a handful of well-established players. Each follows the same general model: hosted infrastructure, normalized data, per-user or usage-based pricing. Here is what each one offers. [Terra API](https://openwearables.io/compare/terra) is one of the most widely adopted wearable data APIs. It covers a broad range of providers and delivers normalized data via webhooks. Pricing is a monthly subscription with an allowance of credits, which active connections and events consume. [Spike API](https://openwearables.io/compare/spike) focuses on health and fitness data aggregation with support for wearables and health platforms. It provides mobile and web SDKs and targets teams building consumer health apps. If you are looking for a Spike API alternative, the comparison is primarily around provider coverage and pricing model. [Sahha](https://openwearables.io/compare/sahha) returns five scores plus biomarkers, behavioural archetypes, tags and insights, from proprietary models, and every score returns its factor breakdown. The scores also work from phone data without a wearable, and its device coverage runs through Apple Health and Health Connect, plus direct cloud APIs for Garmin, Oura and WHOOP. [Rook API](https://openwearables.io/compare/rook) provides a unified API with a focus on mobile SDKs for Android and iOS. It includes health scores with a published method and targets teams building fitness and wellness apps. [Junction API](https://openwearables.io/compare/junction) is a developer-first wearable data connectivity layer. It supports a range of providers and is aimed at teams that want a lightweight integration without heavy vendor lock-in. A full feature comparison of each against Open Wearables is available on the [compare page](https://openwearables.io/compare). ### Where the SaaS model breaks down Usage-based pricing works at low user counts and gets expensive at scale. Vendors price by connected users, active users, credits or plan tiers, so the bill grows with your user base. Each publishes its current plans on its own pricing page, and the figures change often, so check them against your own growth before you commit. Beyond cost, there are structural constraints: - **Data residency.** Your users' health data passes through the vendor's servers. For products in regulated markets (HIPAA, GDPR), your compliance posture depends on their infrastructure and their BAA terms. - **Data model lock-in.** You work within their schema. Custom fields, retention policies, and derived metrics depend on what the vendor exposes. - **Vendor dependency.** Pricing changes. Provider contracts change. Services shut down. Your switching cost is high. - **Health scoring on their terms.** Where a vendor offers scores, they come from its own models and are computed in its infrastructure. How much of the method you can see varies by vendor. ### When it makes sense SaaS vendors are the right starting point when you are pre-product-market-fit, have fewer than 1,000 users, and need to validate whether wearable data is even valuable in your product before investing engineering time. ## Option 2: Building direct integrations Some teams skip the vendor layer and build integrations directly against each provider's API. You own the code, the data model, the storage, and the logic. No per-user fees, no vendor dependency. ### What it actually costs A production-grade integration with a single provider takes a senior backend engineer two to four weeks to build properly: OAuth implementation with token refresh and error recovery, webhook infrastructure, rate limit management, and data normalization. Each provider has its own quirks. The [Garmin API](https://openwearables.io/integrations/garmin) uses OAuth 1.0a and a push-based delivery model. The [Whoop API](https://openwearables.io/integrations/whoop) uses rotating refresh tokens. The [Strava API](https://openwearables.io/integrations/strava) requires webhook deduplication. The [Apple Health API](https://openwearables.io/integrations/apple-health) has no REST endpoint at all and requires a native iOS SDK. [Google Health Connect](https://openwearables.io/integrations/google-health-connect) and [Samsung Health](https://openwearables.io/integrations/samsung-health) both require Android-side implementation with background sync. After four weeks, you have one integration. A product that needs Garmin, Whoop, Polar, and Strava has committed four to eight months of backend engineering to infrastructure that has nothing to do with what makes your product different. Provider API updates add ongoing maintenance on top of that. ### When it makes sense Building direct integrations makes sense when you need a single, deep integration with one specific provider and have the engineering bandwidth to own it long-term. A multi-provider health platform is not a good fit for this approach. ## Option 3: Open source with Open Wearables [Open Wearables](https://openwearables.io/) is a self-hosted open-source platform for wearable health data integration. You deploy it on your own infrastructure, and it handles provider integrations and data normalization across all major wearable platforms, with health scores available as a licensed Pro module. Open Wearables supports live integrations with all major wearable platforms. The full list of supported providers is available at [openwearables.io/integrations](https://openwearables.io/integrations). One normalized API schema regardless of source. Token lifecycle management, webhook handling, and provider-specific complexity are handled by the platform. ### Health scoring and AI On top of the raw data, Pro adds health scores designed and validated by our science team and computed inside your own deployment, so the data they read stays in your account. Each score comes with what it measures and how it was validated, and custom scores can be built for clinical or fitness contexts. For teams building AI-powered features, an MCP server connects your LLM directly to the health data layer, enabling trend detection, anomaly flagging, and cross-metric reasoning. ### Cost and compliance Core is free and open source, so running it costs what your infrastructure costs. Pro and Enterprise add licensed modules and support. Deployment is Docker Compose or one-click Railway. The quickstart gets you to a first API call in under five minutes. Data stays on your servers. You control where it lives, how long it is retained, and who has access. HIPAA-eligible infrastructure and BAA support are available through the enterprise tier. ### If you want help Open Wearables is built and maintained by [Momentum](https://themomentum.ai), a healthtech software studio with 10 years of experience building health products. If you want a team to handle deployment, custom provider integrations, or bespoke health scoring for your use case, that is what we do. See the [pricing and support options](https://openwearables.io/pricing) for details. ## Side-by-side comparison ### SaaS Vendor - Time to first data: Minutes to days - Pricing: Usage-based, on each vendor's pricing page - Data ownership: Vendor's servers - Multi-provider support: Yes - Health scores: Proprietary, where offered - Score customization: Varies by vendor - AI reasoning: Limited / varies - Source code: Proprietary - Compliance (HIPAA/GDPR): The vendor's certifications and terms - Vendor lock-in: Yes ### Custom Build - Time to first data: Months - Pricing: Engineering time and infrastructure - Data ownership: Yours - Multi-provider support: Build each one - Health scores: Build yourself - Score customization: Yes - AI reasoning: Build yourself - Source code: Internal - Compliance (HIPAA/GDPR): Full control - Vendor lock-in: No ### Open Wearables - Time to first data: 5 minutes - Pricing: Free Core, with paid Pro and Enterprise plans - Data ownership: Yours - Multi-provider support: Yes - Health scores: Pro module, computed in your deployment - Score customization: Custom scores with our science team - AI reasoning: MCP server for any LLM - Source code: MIT licensed - Compliance (HIPAA/GDPR): Full control - Vendor lock-in: No ## How to choose - **Start with a SaaS vendor if:** you are pre-product-market-fit, have fewer than 1,000 users, and need to validate the product before investing in infrastructure. - **Build direct integrations if:** you need a single deep integration with one specific provider and have the engineering bandwidth to own it long-term. - **Use Open Wearables if:** you are past initial validation, need multi-provider support, care about where your users' health data lives, or need health scores computed inside your own deployment. ## Getting started Open Wearables is available on [GitHub](https://github.com/the-momentum/open-wearables) under the MIT license. The [quickstart](https://docs.openwearables.io/quickstart) covers deployment and your first API call. If you want to talk through your specific architecture before making a decision, [book a demo](https://openwearables.io/book). ## Keep reading Guides · Oct 26, 2026 · 9 min read ### Moving from a hosted wearable API to Open Wearables: a migration playbook Moving from a hosted wearable API to Open Wearables is usually a re-integration rather than a data migration. This playbook walks through the decisions, the steps in order, how your users reconnect and what to tell your security team. Guides · Oct 26, 2026 · 7 min read ### Why teams move from a hosted wearable API to Open Wearables A hosted wearable API is a sensible way to start. As a product grows, the questions change: whose provider apps, whose cloud, whose schema. Here is why teams move to Open Wearables, what they get after the move, and what it asks of them. Guides · Jul 28, 2026 · 5 min read ### How Wearable Data Flows From Device to Your API: A Complete Architecture Guide Wearable data does not go directly from device to your API. It flows through the provider cloud, then Open Wearables, then PostgreSQL, then your application. Here is what each step looks like. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/wearable-app-development-checklist # The wearable app development checklist: what you actually need to build (and what you don't) [All posts](https://openwearables.io/blog) [Guides](https://openwearables.io/blog/category/guides) Open Wearables Team · Jul 15, 2026 · 7 min read ## Key Takeaways - **OAuth flow** differs per provider and must be implemented individually unless you use a unified abstraction layer - **Token refresh** is required for providers like Strava (6-hour expiry) and Whoop, and must be handled automatically - **Webhook registration** is mandatory for Garmin, which does not support polling-based sync - **Unit normalization** (heart rate in bpm, distance in meters, timestamps in UTC) must happen at ingestion, not at query time - **Deduplication** within a single provider is handled by Open Wearables via `external_id`; cross-provider merge logic is your responsibility - **Apple Health, Google Health Connect, and Samsung Health** require a mobile SDK and cannot be synced from the cloud - **Open Wearables** handles the integration plumbing; your business logic, UI, and user authentication are outside its scope - The most common scoping mistake is underestimating provider-specific edge cases, not the core data model Scoping a wearable feature is harder than it looks. You know you need heart rate data from Garmin. Maybe sleep from Oura. Maybe workouts from Strava. The first architectural diagram fits on a napkin. Then you start reading the provider docs and the napkin fills up fast: OAuth flows that differ per provider, tokens that expire after six hours, webhook registration requirements, timestamp formats that vary by device firmware, and a deduplication problem that only shows up when a user connects both their Garmin watch and their iPhone. This checklist is for founders and PMs who are scoping that project right now. It maps what you actually need to build, what Open Wearables handles for you, and what you will still own no matter what. ## The checklist ### 1. OAuth flow per provider Each provider runs its own OAuth 2.0 implementation with different scopes, redirect requirements, and consent screens. Building this yourself means maintaining multiple OAuth clients, handling provider-specific quirks, and keeping up with API changes. OW handles this. A single endpoint covers all supported providers: ``` GET /api/v1/oauth/{provider}/authorize?user_id={id}&redirect_uri={url} ``` ### 2. Token storage and refresh Access tokens expire. Strava tokens expire after six hours. Whoop tokens auto-refresh but require an active paid membership on the user's side. Storing tokens securely and refreshing them before they expire is table stakes, but it is also boilerplate you do not want to maintain. OW handles this. Token lifecycle management, including automatic refresh, is built into the provider integration layer. ### 3. Webhook endpoint registration and retry logic Some providers push data to you rather than waiting for you to pull it. Garmin is webhook-only, meaning you must register an endpoint, handle incoming payloads, and implement retry logic for failed deliveries. Missed webhooks mean missing data. OW handles this. Register a webhook endpoint once: ``` POST /api/v1/webhooks/endpoints ``` OW handles the provider-side registration and retry behavior. ### 4. Polling for providers without webhooks Not every provider supports webhooks. For those that use polling, you need to manage sync scheduling, backfill windows, and avoiding duplicate ingestion on repeated polls. Garmin's 30-day historical backfill is a specific case: use the dedicated endpoint, not generic `/sync`. OW handles this. Provider-specific sync endpoints abstract the polling strategy: ``` POST /api/v1/providers/garmin/users/{user_id}/sync/historical POST /api/v1/providers/whoop/users/{user_id}/sync POST /api/v1/providers/suunto/users/{user_id}/sync?data_type=all ``` ### 5. Data normalization (units, timestamps, field names) Garmin reports distance in meters. Some providers use local time. Field names for the same concept differ across APIs. If you normalize at query time, you will do it in every downstream consumer. If you never normalize, you will ship a bug to production. OW handles this. Normalization is applied at ingestion: heart rate in bpm, distance in meters, temperature in Celsius, all timestamps in UTC. Your app reads clean data. ### 6. Deduplication within a provider A user might sync the same workout twice: once from a manual trigger and once from a webhook. Without deduplication, you store duplicate records and your aggregations break. OW handles this. Records are deduplicated by `external_id` within a provider. The same workout will not appear twice. ### 7. Cross-provider deduplication A user who wears a Garmin watch and uses Strava will generate overlapping workout records. OW stores them as separate records with different `provider` values. Deciding which source wins, or how to merge them, requires product judgment: do you prefer GPS data from Garmin or the activity metadata from Strava? You build this. OW does not auto-merge across providers. Cross-provider merge logic belongs in your application layer because it depends on what your product needs. ### 8. Pagination through large datasets A user with years of historical data will not fit in a single API response. User listings use offset-based pagination. Data endpoints use cursor-based pagination via `next_cursor`. Getting this wrong means silently missing records. OW handles this. Pagination is built into the data retrieval endpoints. Your client code needs to follow the cursor, but the server-side implementation is handled. ### 9. Mobile SDK integration (Apple Health, Google Health Connect, Samsung Health) Apple Health has no cloud API. Neither does Google Health Connect or Samsung Health. These providers require a native mobile SDK. There is no server-side workaround. OW handles partially. OW includes mobile SDK support for these providers. You still need to embed the SDK in your mobile app and handle the platform-specific setup on the client side. ### 10. Data storage schema OW provides a storage layer with its own schema, but your application will likely need to join wearable data against your own user records, product events, or business data. You build this (partially). OW handles storage for the wearable data it ingests. Your schema for connecting that data to the rest of your product is yours to design. ## What OW handles out of the box Stand up the stack: ``` git clone https://github.com/the-momentum/open-wearables.git cd open-wearables docker compose up -d ``` API at `http://localhost:8000`. Admin panel at `localhost:3000`. Full Swagger docs at `localhost:8000/docs`. Authenticate with a header on every request: ``` X-Open-Wearables-API-Key: YOUR_API_KEY ``` Once a user has connected a provider through the OAuth flow, you retrieve unified data with standard GET requests regardless of which provider it came from: ``` GET /api/v1/users/{user_id}/events/workouts GET /api/v1/users/{user_id}/events/sleep GET /api/v1/users/{user_id}/timeseries GET /api/v1/users/{user_id}/summaries/ ``` The response format is the same whether the data came from Polar, Oura, or Strava. Units are already normalized. Timestamps are already UTC. For more granular provider-specific sync: ``` POST /api/v1/providers/polar/users/{user_id}/sync?samples=true&zones=true&route=true ``` ## What you still need to build OW handles the integration plumbing. It does not handle your product. **Cross-provider merge logic.** If a user connects Garmin and Apple Health, you will have two sets of workout records covering the same time window. OW stores both with their respective `provider` values. Deciding which one to surface, how to avoid double-counting in your dashboard, or how to present conflicts to the user: that is your code. **Your own user authentication.** OW uses its own API key auth. Your application has its own user accounts, sessions, and permissions. Mapping your user IDs to OW's `user_id` parameter and managing that relationship is your responsibility. **Business logic.** OW gives you normalized health data. What that data means for your product, what thresholds trigger a notification, what a "good week" looks like for your users: all of that lives in your application layer. **UI.** OW has no frontend components beyond the admin panel. Charts, dashboards, summaries, and anything a user sees is yours to build. ## Getting started ``` git clone https://github.com/the-momentum/open-wearables.git cd open-wearables docker compose up -d ``` API at `http://localhost:8000`. Admin panel at `localhost:3000`. Swagger at `localhost:8000/docs`. MIT-licensed and self-hosted. Source and full documentation: [https://github.com/the-momentum/open-wearables](https://github.com/the-momentum/open-wearables) ## Related articles - [How to normalize wearable data across providers](https://openwearables.io/blog/how-to-normalize-wearable-data-across-providers) - [How to sync wearable data from multiple devices](https://openwearables.io/blog/how-to-sync-wearable-data-from-multiple-devices) - [Strava API integration guide for health and fitness apps](https://openwearables.io/blog/strava-api-integration-guide-health-fitness-apps) - [How to integrate Apple Health data into your app](https://openwearables.io/blog/how-to-integrate-apple-health-data-into-your-app) - [Garmin Connect API: What You Can Fetch and How to Do It Faster](https://openwearables.io/blog/garmin-connect-api-what-you-can-fetch) - [How to Handle OAuth, Webhooks, and Token Refresh Across Multiple Wearable Providers](https://openwearables.io/blog/how-to-handle-oauth-webhooks-token-refresh-wearable-providers) - [How to Build a HIPAA-Compliant Health App That Uses Wearable Data](https://openwearables.io/blog/how-to-build-hipaa-compliant-health-app-wearable-data) - [What Is an Open Source Wearable API and When Does It Make Sense](https://openwearables.io/blog/what-is-open-source-wearable-api-when-does-it-make-sense) - [How to Add Wearable Support to an Existing Health App in Days, Not Months](https://openwearables.io/blog/how-to-add-wearable-support-existing-health-app) ## FAQ ### Does Open Wearables work with Apple Health? Yes, via mobile SDK. Apple Health does not expose a cloud API, so there is no server-side sync path. You need to embed the OW mobile SDK in your iOS or Android app to collect Apple Health data. ### How does OW handle token expiry for providers like Strava? Strava access tokens expire after six hours. OW auto-refreshes tokens before expiry so your syncs do not fail silently. You do not need to implement refresh logic yourself. ### What happens when a user connects both Garmin and Strava? OW stores records from each provider separately, identified by their `provider` field. There is no automatic cross-provider merge. If the same workout exists in both, you will see two records. Deciding which to use or how to merge them is your application's job. ### Can I use OW in a production app or is it only for prototyping? OW is MIT-licensed and self-hosted, which means you control the infrastructure and can run it in production. It is designed to handle the full integration layer, not just prototype use cases. ### What if a provider I need is not supported yet? The project is open source. You can check the current provider list in the GitHub repo, open an issue to request a new integration, or contribute one. The architecture is designed to make adding providers consistent. Never miss an update. Join our community. No spam ever. ## Keep reading Guides · Oct 26, 2026 · 9 min read ### Moving from a hosted wearable API to Open Wearables: a migration playbook Moving from a hosted wearable API to Open Wearables is usually a re-integration rather than a data migration. This playbook walks through the decisions, the steps in order, how your users reconnect and what to tell your security team. Guides · Oct 26, 2026 · 7 min read ### Why teams move from a hosted wearable API to Open Wearables A hosted wearable API is a sensible way to start. As a product grows, the questions change: whose provider apps, whose cloud, whose schema. Here is why teams move to Open Wearables, what they get after the move, and what it asks of them. Guides · Jul 28, 2026 · 5 min read ### How Wearable Data Flows From Device to Your API: A Complete Architecture Guide Wearable data does not go directly from device to your API. It flows through the provider cloud, then Open Wearables, then PostgreSQL, then your application. Here is what each step looks like. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/wearable-data-deduplication-multiple-devices # Wearable Data Deduplication: How to Handle Users With Multiple Devices [All posts](https://openwearables.io/blog) [Guides](https://openwearables.io/blog/category/guides) Open Wearables Team · Jul 22, 2026 · 5 min read ## Key Takeaways - Users with multiple wearable devices or apps produce overlapping data. The same workout can arrive from Garmin, Strava, and Apple Health as three separate records. - Open Wearables stores records from each provider separately, identified by provider and source metadata. Deduplication within a provider happens via unique constraints at the database level. - Cross-provider deduplication is handled through a configurable priority system: provider priorities and device type priorities determine which source is used when multiple providers cover the same data. - A user who shares one provider account across multiple Open Wearables profiles is handled by a sync coordination layer that prevents duplicate API calls. - Your application queries normalized data through the API. The priority system determines what you receive. You configure the priorities; Open Wearables applies them. Multi-device users are common. An athlete with a Garmin watch connected to Strava will produce workout records from both. A user with an iPhone running Apple Health and a Polar watch will produce overlapping sleep and step data. A corporate wellness user might have their employer's wellness app pulling from Google Health Connect while also using a Whoop. Each of these configurations creates the same problem: the same real-world event appears multiple times in your data from different sources. How you handle this determines whether your health AI produces accurate insights or noisy ones. ## How Duplicates Happen There are two distinct deduplication problems. Within-provider deduplication happens when the same record arrives multiple times from the same provider. This can happen due to webhook retries, sync overlap, or race conditions in background processing. Open Wearables handles this automatically at the database layer using unique constraints. The handle_duplicates decorator in the codebase catches UniqueViolation database errors, queries for the existing record using the violated unique constraint, and returns it instead of failing. The insert is idempotent. Cross-provider deduplication happens when different providers report the same real-world event. A run recorded on a Garmin watch that syncs to Strava produces two records with slightly different timestamps, different field values, and different source metadata. These are not database duplicates: they are two valid records from two valid sources. Deciding which one to use is an application-level decision handled by the priority system. ## The Priority System Open Wearables includes a configurable priority system that determines which source takes precedence when multiple providers cover the same data. There are two levels of priority: - **Provider priority:** a ranked order of providers. If a user has both Garmin and Strava connected, and both report the same workout, the provider priority determines which one appears in your query results. - **Device type priority:** a ranked order of device categories (watch, phone, ring, etc.). If a user's Garmin watch and their iPhone both contribute step data through Apple Health, the device type priority determines which one is used for daily activity aggregates. The priority system exposes API endpoints for reading and updating these priorities: ``` GET /api/v1/priorities/providers PUT /api/v1/priorities/providers/{provider} PUT /api/v1/priorities/providers GET /api/v1/priorities/device-types PUT /api/v1/priorities/device-types/{device_type} PUT /api/v1/priorities/device-types ``` Each record in the Open Wearables data model includes a source field with provider and device metadata. Your application always knows where each data point came from, regardless of priority configuration. ## Shared Provider Accounts A less common but real scenario: multiple Open Wearables user profiles linked to the same external provider account. This happens in team or testing setups where multiple developers share one Garmin or Polar account. If each profile triggered its own sync independently, the same provider API call would happen multiple times in parallel, producing duplicate data and unnecessary API load. Open Wearables handles this through a sync coordination layer backed by Redis. When a sync starts, the first profile to initiate claims the primary role using a Redis lock (SET NX). Other profiles with the same external provider account become secondaries. The primary makes the API call and the data is fanned out to secondary profiles. Each secondary receives a sync status event indicating it received data from the primary rather than making its own call. This coordination is scoped per provider, per provider user ID, and per sync type, so concurrent syncs of different types do not interfere. ## What Your Application Sees When you query the Open Wearables API, you receive data that has already passed through the priority system. For most endpoints, you get one record per event per day, from the highest-priority source that has data for that event. The source field on every record tells you which provider and device contributed it. If you need to inspect or override the priority logic, the raw records from all providers are accessible through lower-level API endpoints. Data from different providers is never merged into a single record. Open Wearables does not combine a Garmin heart rate with a Strava GPS trace into one unified workout. Each provider's data is stored as a separate record. The priority system selects which record to surface in response to a given query. ## Related articles - [How to Handle OAuth, Webhooks, and Token Refresh Across Multiple Wearable Providers](https://openwearables.io/blog/how-to-handle-oauth-webhooks-token-refresh-wearable-providers) - [How to normalize wearable data across providers](https://openwearables.io/blog/how-to-normalize-wearable-data-across-providers) - [How to Structure Health Data for AI: What Your LLM Actually Needs](https://openwearables.io/blog/how-to-structure-health-data-for-ai-llm) - [How to sync wearable data from multiple devices](https://openwearables.io/blog/how-to-sync-wearable-data-from-multiple-devices) ## FAQ ### Does Open Wearables merge records from different providers into one? No. Records from different providers are always stored separately. Each record carries a source field identifying its provider and device. The priority system determines which record is returned for a given query, but the underlying records remain distinct. ### What happens when Garmin and Strava both report the same run? Both records are stored. The provider priority configuration determines which one appears in your workout query results. If Garmin has higher priority than Strava, the Garmin record is returned. The Strava record remains in the database and is accessible if you query for it directly. ### Can I configure which provider takes precedence for each user individually? The priority configuration is per-deployment, not per-user. All users in your Open Wearables instance use the same provider and device type priority order. If you need per-user priority logic, you implement that in your application layer using the source metadata on each record. ### What if a user connects the same provider account twice? The OAuth connection flow associates an external provider user ID with an Open Wearables user. If the same external account is connected again, the existing connection is updated rather than creating a duplicate. Multiple Open Wearables users sharing the same external provider account are handled by the sync coordination layer, which prevents duplicate API calls. ### How does deduplication work within a single provider? Within a single provider, records are deduplicated using unique database constraints. If the same event arrives twice (due to webhook retries, sync overlap, or a race condition), the second insert detects the constraint violation, queries for the existing record, and returns it. The operation is idempotent from the caller's perspective. ## Keep reading Guides · Oct 26, 2026 · 9 min read ### Moving from a hosted wearable API to Open Wearables: a migration playbook Moving from a hosted wearable API to Open Wearables is usually a re-integration rather than a data migration. This playbook walks through the decisions, the steps in order, how your users reconnect and what to tell your security team. Guides · Oct 26, 2026 · 7 min read ### Why teams move from a hosted wearable API to Open Wearables A hosted wearable API is a sensible way to start. As a product grows, the questions change: whose provider apps, whose cloud, whose schema. Here is why teams move to Open Wearables, what they get after the move, and what it asks of them. Guides · Jul 28, 2026 · 5 min read ### How Wearable Data Flows From Device to Your API: A Complete Architecture Guide Wearable data does not go directly from device to your API. It flows through the provider cloud, then Open Wearables, then PostgreSQL, then your application. Here is what each step looks like. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/what-is-open-source-wearable-api-when-does-it-make-sense # What Is an Open Source Wearable API and When Does It Make Sense [All posts](https://openwearables.io/blog) [Guides](https://openwearables.io/blog/category/guides) Open Wearables Team · Jul 22, 2026 · 5 min read ## Key Takeaways - An open source wearable API gives you access to the integration code itself, not just the API endpoint. You can read it, fork it, audit it, and run it on your own infrastructure. - Open Wearables is MIT-licensed and self-hosted. Your users' data stays on your infrastructure with no third-party data custody. - The platform goes beyond raw data aggregation: it includes open algorithms for health scoring and an AI reasoning layer built on top of the unified data model. - Open source makes sense when: data ownership matters, you need to customize the integration, compliance requires auditability, or you want to build intelligence on top of the data layer. - Open Wearables is already running in production in applications built on top of it. When developers look for wearable integrations, most discover SaaS APIs first. They are easy to find, well-documented, and let you make your first API call quickly. Open source alternatives exist but are less visible. The question is not which one is better, but which one fits your situation. This article explains what an open source wearable API actually is, how Open Wearables specifically works, and the practical cases where this approach makes sense. ## What "Open Source Wearable API" Actually Means A SaaS wearable API gives you an endpoint to call. The integration code that connects to Garmin, Polar, or Oura lives on someone else's servers. You send a request, they return data. You never see how it works. An open source wearable API gives you the integration code itself. You deploy it on your own infrastructure. You can read every line that handles the Garmin OAuth flow, the Polar webhook registration, the Oura data normalization. You can change it, extend it, fork it, and run it wherever you want. Open Wearables is MIT-licensed. The full source is at github.com/the-momentum/open-wearables. Every provider integration, every data normalization step, every algorithm is in the repository. ## What Open Wearables Is Open Wearables is a self-hosted health intelligence platform. It connects wearable devices, normalizes the data into a unified model, and exposes it through a single REST API. On top of that data layer, it provides open algorithms for health scores and an MCP server that gives AI assistants structured access to health data. When you deploy Open Wearables, wearable data from connected providers flows into your PostgreSQL instance. Your application queries one API regardless of which device a user has. A workout from Garmin and a workout from Polar come back in the same EventRecord format, with the same field names, the same units, the same timestamp format. The current list of supported providers is at docs.openwearables.io/provider-setup. ## What You Can Do With the Source Code MIT license means you can: - **Read it:** every OAuth flow, every webhook handler, every normalization step is visible. If you want to understand exactly how Garmin data is processed before it reaches your API, you can read the code. - **Fork it:** take the repository, modify it for your use case, and run your version. - **Extend it:** add custom provider integrations, custom data types, or proprietary processing logic on top of the existing foundation. For teams that need a provider not yet in the community version, Momentum can build custom integrations as a commercial service. - **Audit it:** compliance and security teams can review exactly what happens to user data. There is no black box. ## When Open Source Makes Sense - **Data ownership is a requirement.** Some use cases, particularly in healthcare, require that user health data never passes through a third party's infrastructure. Self-hosting is the only way to guarantee this. SaaS APIs store data on their servers by design. - **You need to build intelligence on top of the data.** Open Wearables goes beyond data aggregation. The open health score algorithms and AI reasoning layer are designed to be extended and customized for specific domains. If you are building a coaching product, a clinical monitoring tool, or a corporate wellness platform, the intelligence layer matters as much as the data layer. - **Compliance requires auditability.** If a compliance team, clinical reviewer, or data governance committee needs to verify what happens to user data, open source gives them the code. A closed-source SaaS API cannot provide this. - **You need to customize the integration.** If a provider is not yet supported, or if you need to handle data types that Open Wearables does not expose by default, you can add this yourself or work with Momentum to build it. - **You are already managing infrastructure.** If your product already runs on self-managed infrastructure, adding Open Wearables to your Docker Compose stack is a smaller lift than it sounds. ## Related articles - [How to Handle OAuth, Webhooks, and Token Refresh Across Multiple Wearable Providers](https://openwearables.io/blog/how-to-handle-oauth-webhooks-token-refresh-wearable-providers) - [How to Give Your LLM Access to Wearable Data](https://openwearables.io/blog/how-to-give-your-llm-access-to-wearable-data) - [How to Build a HIPAA-Compliant Health App That Uses Wearable Data](https://openwearables.io/blog/how-to-build-hipaa-compliant-health-app-wearable-data) - [What wearable app development actually looks like in 2026](https://openwearables.io/blog/what-wearable-app-development-actually-looks-like-in-2026) - [How to Add Wearable Support to an Existing Health App in Days, Not Months](https://openwearables.io/blog/how-to-add-wearable-support-existing-health-app) - [How to Build an AI Agent That Reasons Over Health Data](https://openwearables.io/blog/how-to-build-ai-agent-reasons-over-health-data) ## FAQ ### Is Open Wearables production-ready? Yes. The platform is already running in production in applications built on top of it. The wearable data integration layer is stable and actively maintained. Check the GitHub releases page for the current version and changelog. ### How long does it take to set up? The Docker Compose stack can be running in minutes. Provider credential setup takes longer: most providers issue credentials immediately through a self-service developer portal, but Garmin's developer program is currently not accepting new applications. Plan your integration timeline around the providers you need to support. ### Can I add a provider that Open Wearables does not support yet? Yes. The repository includes documentation for adding new providers. The architecture uses a strategy pattern, so each provider is a self-contained implementation. You can contribute the provider back to the open source project, keep it in your fork, or work with Momentum to build a custom integration. ### What happens if I need help? Community support is available through Discord and GitHub Issues. For enterprise support with SLA guarantees and dedicated implementation help, Momentum offers commercial services. Details at openwearables.io/pricing. ### Does Open Wearables work alongside existing integrations? Yes. You can deploy Open Wearables for new provider integrations while keeping existing direct integrations in place. The unified API means you can gradually migrate without a full cut-over. ## Keep reading Guides · Oct 26, 2026 · 9 min read ### Moving from a hosted wearable API to Open Wearables: a migration playbook Moving from a hosted wearable API to Open Wearables is usually a re-integration rather than a data migration. This playbook walks through the decisions, the steps in order, how your users reconnect and what to tell your security team. Guides · Oct 26, 2026 · 7 min read ### Why teams move from a hosted wearable API to Open Wearables A hosted wearable API is a sensible way to start. As a product grows, the questions change: whose provider apps, whose cloud, whose schema. Here is why teams move to Open Wearables, what they get after the move, and what it asks of them. Guides · Jul 28, 2026 · 5 min read ### How Wearable Data Flows From Device to Your API: A Complete Architecture Guide Wearable data does not go directly from device to your API. It flows through the provider cloud, then Open Wearables, then PostgreSQL, then your application. Here is what each step looks like. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/what-wearable-app-development-actually-looks-like-in-2026 # What wearable app development actually looks like in 2026 [All posts](https://openwearables.io/blog) [Guides](https://openwearables.io/blog/category/guides) Open Wearables Team · Jul 15, 2026 · 8 min read ## Key Takeaways - **OAuth flows differ by provider**: token lifetimes, refresh behavior, and authorization endpoints are not standardized across wearable APIs. - **Polling vs. webhooks is not a choice you make once**: Garmin delivers data exclusively via webhook; other providers require polling. Your architecture has to handle both. - **Field names and units vary** across providers. Heart rate might be `heart_rate`, `heartRate`, or `hr_bpm`. Without normalization, every query becomes a provider-specific special case. - **Cross-provider deduplication is your problem**: a user wearing Garmin and Apple Watch produces separate records per provider. OW stores them separately; merging is application-level logic. - **Apple Health has no cloud API**: it requires a mobile SDK. Any architecture that assumes all providers work the same way will break here. - **Open Wearables is a self-hosted, MIT-licensed data layer** that normalizes these differences at ingestion time, exposing a single set of endpoints regardless of source device. - **Setup takes under five minutes**: Docker Compose, one API key header, and you have a running local instance with Swagger docs at `localhost:8000/docs`. Most tutorials about wearable app development start with OAuth and end with a JSON payload containing heart rate data. What they skip is everything in between: the provider-specific token refresh schedules, the fact that "sleep" means different things depending on which device recorded it, the webhook-only providers that never respond to polling, and the quiet chaos of a user who owns two devices from different ecosystems. By the time you have handled all of that cleanly, you have built an integration platform. This article describes what that actually looks like, and where you can take pieces off the shelf instead of building them yourself. ## What building the data layer yourself actually involves The first thing you hit is OAuth. Each provider has its own authorization flow, its own token format, and its own rules about expiry. Strava tokens expire after six hours. Whoop requires an active paid membership before the OAuth flow will succeed. Garmin's authorization model is structured differently from a standard OAuth 2.0 flow. You write one integration, it works, then you write the next one and none of the assumptions transfer cleanly. Token refresh is its own layer. Some providers return a new refresh token with every access token exchange. Others reuse the same refresh token indefinitely. If you build a refresh handler that assumes one model, it will silently fail on providers that use the other. Then there is the polling vs. webhook split. Most providers let you pull data on demand. Garmin does not. Garmin pushes data to a registered webhook endpoint; there is no `/sync` call that works. If your architecture assumes you can pull when you need data, Garmin will not fit into it without a structural change. Field names and units are the part that takes the most calendar time even if it is not the hardest conceptually. One provider returns `heart_rate_bpm`, another returns `heartRate`, another returns a nested object. Distance might be in meters, kilometers, or miles depending on the provider and sometimes on the user's account settings. Timestamps might be Unix epoch, ISO 8601 with a timezone, or ISO 8601 in UTC. None of this is wrong on the provider's part. It is just not standardized. Deduplication adds another layer. A user who connects both Garmin and Apple Watch will produce two sets of workout records for the same activity. They are not duplicates in the strict sense: they come from different sources and may have different field values. But they represent the same event. Deciding how to handle that is a non-trivial application design question, and it is not one a generic library can answer for you. ## Where the complexity hides The OAuth and field-name issues are visible early. The harder problems surface later. "Sleep" is not a universal concept across wearable providers. One provider might return a single sleep block with a start and end time. Another returns a breakdown by sleep stage with separate records for light, deep, and REM. A third returns a sleep score and a summary but no raw stage data at all. If your application needs to compare sleep quality across providers, you are writing normalization logic that requires understanding each provider's data model, not just mapping field names. Garmin's webhook-only architecture means your infrastructure needs an always-available endpoint to receive pushes. During development, that means running something like ngrok or a deployed staging environment. It also means that if your webhook endpoint is down, you miss data. There is no catch-up mechanism built into Garmin's API. You need to implement your own gap detection. Cross-provider users are where deduplication gets genuinely complex. Imagine a user who records a run on their Garmin watch and then syncs the same run to Strava via Garmin Connect. OW stores a record from Garmin and a separate record from Strava. They are different records from different providers. They may have different GPS traces, different heart rate averages, or different timestamps depending on sync lag. Whether those are "the same workout" is an application-level decision. OW does not auto-merge them, and that is the correct behavior: any auto-merge logic would require assumptions about what "same" means that differ by application. Apple Health is a special case that affects mobile architecture decisions. There is no cloud sync for Apple Health data. If you need Apple Health data in your backend, you need a mobile SDK that reads from HealthKit on-device and pushes to your API. Any backend-only integration architecture will not reach Apple Health data at all. ## What Open Wearables handles Open Wearables is a self-hosted data layer that sits between your application and the wearable provider APIs. It handles OAuth flows, token refresh, webhook ingestion, and normalization. Your application talks to one API regardless of which providers the user has connected. The setup is a Docker Compose stack: ``` git clone https://github.com/the-momentum/open-wearables.git cd open-wearables docker compose up -d ``` The API runs at `http://localhost:8000`. The admin panel is at `localhost:3000`. Swagger documentation is at `localhost:8000/docs`. Authentication uses a header, not a Bearer token: ``` X-Open-Wearables-API-Key: YOUR_API_KEY ``` OAuth connections are initiated through a provider-specific authorize endpoint: ``` GET /api/v1/oauth/{provider}/authorize?user_id={id}&redirect_uri={url} ``` OW handles the token exchange, stores credentials, and manages refresh automatically. Strava's six-hour token expiry and Whoop's refresh behavior are handled internally. Strava has also changed its developer program terms several times, most recently in mid-2026. For a practical summary of what broke and what still works, see the [Strava API 2026 developer guide](https://openwearables.io/blog/strava-api-developer-guide-activities-heart-rate-gps-data). Normalized data is available through a consistent set of endpoints regardless of source provider: ``` GET /api/v1/users/{user_id}/events/workouts GET /api/v1/users/{user_id}/events/sleep GET /api/v1/users/{user_id}/timeseries GET /api/v1/users/{user_id}/summaries/ ``` Canonical units are applied at ingestion: heart rate in bpm, distance in meters, temperature in Celsius, timestamps in UTC. You do not write unit conversion logic in your application. Webhook delivery to your own services is available through a registered endpoint: ``` POST /api/v1/webhooks/endpoints ``` Here is a minimal Python example pulling workout data for a user: ``` import requests BASE_URL = "http://localhost:8000" API_KEY = "YOUR_API_KEY" USER_ID = "user_123" headers = {"X-Open-Wearables-API-Key": API_KEY} response = requests.get( f"{BASE_URL}/api/v1/users/{USER_ID}/events/workouts", headers=headers ) workouts = response.json() ``` The response structure is the same regardless of whether the workout came from Garmin, Polar, Strava, or Suunto. The `provider` field tells you where each record originated. Cross-provider deduplication remains your responsibility at the application layer, but the data you are comparing is already normalized. For mobile integrations: Apple Health, Google Health Connect, and Samsung Health are supported through a mobile SDK. The cloud providers use the API directly. ## Getting started ``` git clone https://github.com/the-momentum/open-wearables.git cd open-wearables docker compose up -d ``` API at `http://localhost:8000`. Admin at `localhost:3000`. Swagger at `localhost:8000/docs`. Open Wearables is MIT-licensed and self-hosted. The quickstart with provider configuration steps is at docs.openwearables.io/quickstart. ## Related articles - [How to sync wearable data from multiple devices](https://openwearables.io/blog/how-to-sync-wearable-data-from-multiple-devices) - [How to normalize wearable data across providers](https://openwearables.io/blog/how-to-normalize-wearable-data-across-providers) - [How to build an AI health coaching app with wearable data](https://openwearables.io/blog/how-to-build-ai-health-coaching-app-with-wearable-data) - [Wearable API integration: comparing SaaS, custom build, and open source](https://openwearables.io/blog/wearable-api-integration-saas-custom-build-open-source) - [Garmin Connect API: What You Can Fetch and How to Do It Faster](https://openwearables.io/blog/garmin-connect-api-what-you-can-fetch) - [How to Give Your LLM Access to Wearable Data](https://openwearables.io/blog/how-to-give-your-llm-access-to-wearable-data) - [How to Handle OAuth, Webhooks, and Token Refresh Across Multiple Wearable Providers](https://openwearables.io/blog/how-to-handle-oauth-webhooks-token-refresh-wearable-providers) - [How to Build a HIPAA-Compliant Health App That Uses Wearable Data](https://openwearables.io/blog/how-to-build-hipaa-compliant-health-app-wearable-data) - [What Is an Open Source Wearable API and When Does It Make Sense](https://openwearables.io/blog/what-is-open-source-wearable-api-when-does-it-make-sense) - [Wearable Data Deduplication: How to Handle Users With Multiple Devices](https://openwearables.io/blog/wearable-data-deduplication-multiple-devices) - [How to Add Wearable Data to a Corporate Wellness Platform](https://openwearables.io/blog/how-to-add-wearable-data-corporate-wellness-platform) - [How to Add Wearable Support to an Existing Health App in Days, Not Months](https://openwearables.io/blog/how-to-add-wearable-support-existing-health-app) - [How Wearable Data Flows From Device to Your API: A Complete Architecture Guide](https://openwearables.io/blog/how-wearable-data-flows-device-to-api-architecture) ## FAQ ### Does Open Wearables handle Garmin's webhook-only delivery? Yes. OW registers and manages Garmin webhook endpoints. You do not need to set up separate webhook infrastructure for Garmin; data arrives through the same normalized API as other providers. ### Can I use Open Wearables with Apple Health? Apple Health requires the mobile SDK. There is no cloud API for HealthKit data, so backend-only integrations cannot reach it. The OW mobile SDK reads from HealthKit on-device and sends data to your OW instance. ### How does OW handle token expiry for providers like Strava? Token refresh is managed internally. Strava tokens expire after six hours; OW refreshes them automatically before expiry. Your application code does not need to handle provider-specific token lifecycle logic. ### What happens when a user connects multiple devices that record the same activity? OW stores records from each provider separately, deduplicated by `external_id` within a provider. A run recorded on Garmin and synced to Strava will produce two records. Merging them is application-level logic, because the definition of "same activity" depends on your use case. ### Is there a managed cloud version? Open Wearables is designed for self-hosting. The Docker Compose setup runs on any server with Docker installed. For teams that want a managed deployment, contact the Momentum team at the link in the documentation. Never miss an update. Join our community. No spam ever. ## Keep reading Guides · Oct 26, 2026 · 9 min read ### Moving from a hosted wearable API to Open Wearables: a migration playbook Moving from a hosted wearable API to Open Wearables is usually a re-integration rather than a data migration. This playbook walks through the decisions, the steps in order, how your users reconnect and what to tell your security team. Guides · Oct 26, 2026 · 7 min read ### Why teams move from a hosted wearable API to Open Wearables A hosted wearable API is a sensible way to start. As a product grows, the questions change: whose provider apps, whose cloud, whose schema. Here is why teams move to Open Wearables, what they get after the move, and what it asks of them. Guides · Jul 28, 2026 · 5 min read ### How Wearable Data Flows From Device to Your API: A Complete Architecture Guide Wearable data does not go directly from device to your API. It flows through the provider cloud, then Open Wearables, then PostgreSQL, then your application. Here is what each step looks like. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/whoop-api-recovery-strain-sleep-data-for-developers # Whoop API: recovery, strain and sleep data for developers [All posts](https://openwearables.io/blog) [Whoop](https://openwearables.io/blog/category/whoop) Open Wearables Team · May 6, 2026 · 9 min read ## Key takeaways - **Whoop requires a paid active membership**: the OAuth flow will not complete for users without a current Whoop subscription. - **Recovery data is not real-time**: it is only available after a sleep cycle completes. Build your pipeline around scheduled syncs, not live fetches. - **Rotating refresh tokens**: every token exchange returns a new refresh token. If you store the old one, the user loses access. Requires atomic token handling in your backend. - **Whoop's cycle-based data model** organizes data around sleep, recovery, and strain cycles rather than calendar days. Understanding this is essential before you write any sync logic. - **Available data**: Recovery Score, Strain Score, Sleep Performance, HRV, resting heart rate, respiratory rate, skin temperature (4.0+), SpO2 (4.0+). - **No GPS data**: Whoop has no GPS. Workout tracking is accelerometer and heart rate based. - **Open Wearables** handles OAuth, rotating token management, and cycle-based data normalization. You query unified endpoints instead of managing Whoop-specific sync logic. ## Introduction Whoop built its product around a single idea: give athletes a daily answer to the question of whether their body is ready to perform. The Recovery Score, Strain Score and Sleep Performance metrics are the output of continuous biometric monitoring throughout the day and night. For developers building recovery coaching apps, wellness platforms or sports performance tools, Whoop's API provides access to some of the most actionable recovery-oriented data available from a consumer wearable. But Whoop's data model is different from most wearable APIs in ways that matter for how you architect your integration. Data is organized around cycles, not timestamps. Recovery is a consequence of sleep, not a standalone metric. Strain accumulates across a day rather than being a fixed measurement. Understanding how Whoop thinks about these concepts is a prerequisite to building something useful with the data. This guide covers what the Whoop API exposes, how the cycle-based model works in practice, what authentication requires, and how the data maps to real product use cases. ## What the Whoop API exposes Whoop's data model has three primary object types: sleep cycles, recovery cycles and strain cycles. Each maps to a dedicated set of endpoints. Sleep cycles contain everything recorded during a sleep period: total time in bed, total sleep duration, sleep efficiency (time asleep divided by time in bed), sleep latency (how long it took to fall asleep), sleep staging broken into light, deep and REM percentages, disturbances, respiratory rate during sleep, and the Sleep Performance Score which aggregates these signals into a single 0-100 number. Sleep Performance reflects how well the user slept relative to their individual baseline, not an absolute standard. Recovery cycles are generated after each sleep cycle ends and the user wakes up. The Recovery Score (0-100) is Whoop's flagship metric: a daily readiness indicator that aggregates heart rate variability, resting heart rate and sleep quality. Whoop color-codes recovery into three zones: green (67-100, ready to perform), yellow (34-66, moderate readiness) and red (0-33, prioritize rest). The underlying biometrics are also available individually: HRV in milliseconds (RMSSD methodology), resting heart rate in beats per minute, respiratory rate, skin temperature deviation on Whoop 4.0+, and SpO2 on compatible hardware. Strain cycles track daily cardiovascular load. Day Strain is a dimensionless value from 0 to 21 that represents cumulative cardiovascular load. Whoop also tracks individual workouts within the strain cycle, each with its own sport type, duration, heart rate during the session and workout strain score. What Whoop does not provide: GPS data (Whoop has no GPS), step counts, blood glucose, ECG or any metric requiring optical blood flow measurement beyond heart rate and SpO2. ## The cycle-based model in practice The most important thing to understand about Whoop data is its temporal structure. A recovery cycle does not exist until the preceding sleep cycle ends. If you query the recovery endpoint at 7 AM before a user has woken up and their sleep cycle has closed, you will get no data for that day. Recovery is a morning metric, available after wake, not a continuous stream. This has direct implications for your data pipeline. You cannot build a real-time recovery dashboard. The right architecture is a daily morning sync, triggered either on a schedule or by a webhook event when new recovery data becomes available. Many teams schedule this sync to run between 6 and 10 AM in the user's local time zone, after the typical wake window. Day Strain is the inverse: it accumulates throughout the day and is a running total. If you fetch strain at noon, you get the strain accumulated to that point, not the final daily value. Final strain is available after midnight when the strain cycle closes. If your product shows a day's training load, decide whether to show live intraday strain or closed daily totals, and make that distinction clear to users. ## Authentication and token management Whoop uses OAuth 2.0 with the authorization code flow. The key operational detail that differentiates Whoop from most providers is rotating refresh tokens. Every time you exchange a refresh token for a new access token, Whoop returns a new refresh token as well. The previous refresh token is immediately invalidated. This means your token storage layer needs to handle concurrent refresh attempts carefully. If two background jobs for the same user both detect an expired access token and both attempt to refresh simultaneously, one will succeed and one will receive a 401 because the refresh token it used has already been rotated by the first job. The second job now has an invalid refresh token in its hand and no way to recover without user re-authentication. The solution is atomic token refresh with distributed locking: acquire a per-user lock before attempting a refresh, check whether the token was already refreshed by another process while waiting for the lock, and only refresh if the stored token still matches what you started with. This is a pattern you need with any rotating-token provider. The offline scope is required to receive a refresh token at all. Without it, users need to re-authenticate every time the access token expires. ## Building with Whoop data The practical value of Whoop data in a product context comes from treating the signals as a system rather than individually. Recovery Score alone is useful as a daily headline, but its explanatory power comes from the contributing signals. A user with a Recovery Score of 42 (yellow zone) wants to know why. If their HRV is 14% below their 30-day baseline but their sleep score was 85, the culprit is cardiovascular stress, not poor sleep. If their sleep score was 58 but HRV was normal, the story is different: the body is physically ready but sleep quality dragged the composite score down. Surfacing these contributing factor breakdowns in your product gives users actionable context rather than just a number to react to. For coaching applications, the 30-day rolling HRV baseline is more useful than any single HRV reading. Single-day HRV values fluctuate due to alcohol, travel, illness, stress and countless other factors. The trend line and deviation from baseline reveal the underlying fitness trajectory. A user whose HRV baseline has increased 15% over six weeks is adapting positively to training load. A user whose baseline has declined three weeks running while strain remains high is accumulating fatigue. ## Open Wearables and Whoop Open Wearables integrates with Whoop's API and handles OAuth, rotating refresh token management and cycle-based data normalization. Recovery, sleep and workout data is available through a consistent schema shared with Garmin, Oura and other supported providers. For apps serving users who might have Whoop or Oura or both, Open Wearables normalizes the conceptually similar but technically different recovery scoring models into a unified daily health summary. Your product code works with one schema regardless of which device a user has connected. Self-hosted and MIT-licensed. Deploy via Docker Compose. ## Fetching Whoop data with Open Wearables Once a user connects Whoop through the OAuth flow, you trigger a sync and then query the unified endpoints: ``` POST /api/v1/providers/whoop/users/{user_id}/sync ``` Recovery, sleep, and strain data are then available through the same endpoints as any other provider: ``` GET /api/v1/users/{user_id}/events/sleep GET /api/v1/users/{user_id}/summaries/ GET /api/v1/users/{user_id}/timeseries ``` Here is a minimal Python example pulling sleep data for a user: ``` import requests BASE_URL = "http://localhost:8000" API_KEY = "YOUR_API_KEY" USER_ID = "user_123" headers = {"X-Open-Wearables-API-Key": API_KEY} response = requests.get( f"{BASE_URL}/api/v1/users/{USER_ID}/events/sleep", headers=headers ) sleep_data = response.json() ``` The response format is the same whether the data came from Whoop, Oura, or Garmin. The provider field on each record tells you the source. ## Common issues when building with the Whoop API ### Paid membership required The most common early blocker: the Whoop OAuth flow completes successfully but returns no data. The most likely cause is that the user does not have an active paid Whoop membership. Whoop requires a current subscription to access the API. Build a clear error state for this case rather than showing an empty dashboard. ### Concurrent token refresh If multiple background jobs attempt to refresh the same user token simultaneously, only one will succeed. The other will receive an invalid grant error and invalidate the refresh token. Implement per-user distributed locking around your token refresh logic. Once a token is invalidated this way, the user must re-authenticate. ### Recovery data timing Recovery data is generated after a sleep cycle closes. If you sync before the user wakes up and their sleep cycle is still open, you will get no recovery record for that day. Schedule your sync after a reasonable wake time for your user base, or implement retry logic that checks for the recovery record after it should have been generated. ### Missing offline scope If you do not request the offline scope during OAuth, Whoop will not return a refresh token. Your integration will appear to work until the access token expires, at which point the user will need to re-authenticate. Always request offline scope upfront. ## Faq ### Does the Whoop API provide real-time data? No. Recovery data is generated after a sleep cycle completes. Strain accumulates throughout the day but the daily total is only final after midnight. Whoop is a daily-cadence data source, not a real-time stream. ### What Whoop hardware does the API support? Whoop 4.0 and later. Skin temperature deviation and SpO2 are only available on 4.0+. Older Whoop devices have limited or no API access. ### Is the Whoop recovery score algorithm public? No. The Recovery Score methodology is proprietary. You receive the score and the underlying biometrics (HRV, RHR, sleep quality) but not the weighting formula. Open Wearables computes an open, auditable recovery score from the same biometric inputs. ### How do i handle the rotating refresh token correctly? Always store the new refresh token returned from every token exchange, even successful ones that were only refreshing a still-valid access token. Use distributed locking or database-level concurrency controls to prevent simultaneous refresh attempts for the same user. ### How long does it take to set up Open Wearables with Whoop? Deploy takes under an hour with Docker. Whoop OAuth configuration requires registering your app at the Whoop developer portal and adding credentials to the Open Wearables config. First data sync completes within minutes of a user connecting. ## Open Wearables Open Wearables is an open-source platform that connects your application to wearable and health data providers through a single API. One normalized data model, multi-provider support in a single self-hosted deployment, no per-user fees, MIT licensed, and health intelligence built in: normalized recovery, sleep, activity and biometric data ready for your product layer. We offer custom deployment and integration support through Momentum. If your team needs help getting to production faster, we can set up and configure Open Wearables as part of a managed engagement. [Let's talk](https://www.themomentum.ai/lets-talk). [Book a demo](https://openwearables.io/book) to see how Open Wearables fits your use case. ## Whoop integration View the full [Whoop integration documentation](https://openwearables.io/integrations/whoop) on Open Wearables. ## See related articles - [What wearable app development actually looks like in 2026](https://openwearables.io/blog/what-wearable-app-development-actually-looks-like-in-2026) - [The wearable app development checklist: what you actually need to build (and what you don't)](https://openwearables.io/blog/wearable-app-development-checklist) [Building a Health App With Whoop API Data](https://openwearables.io/blog/building-a-health-app-with-whoop-api-data) [Oura API: Accessing Ring Data, Sleep, HRV and Readiness](https://openwearables.io/blog/oura-api-accessing-ring-data-sleep-hrv-readiness) [Strava API Developer Guide: Activities, Heart Rate and GPS Data](https://openwearables.io/blog/strava-api-developer-guide-activities-heart-rate-gps-data) ## Keep reading Whoop · Jun 2, 2026 · 4 min read ### How to integrate Whoop API data into your health app The Whoop API requires a paid membership and OAuth setup. Learn how Open Wearables handles authentication, polling, and normalization so you query one endpoint. Whoop · May 6, 2026 · 6 min read ### Building a health app with Whoop API data Getting data out of the Whoop API is one problem. Building something users find valuable is another. Here's how to use Recovery Score, HRV trends and Sleep Performance effectively in a product. Releases · Oct 26, 2026 · 11 min read ### Open Wearables 0.10.0: new dashboard, nutrition data and sync-aware webhooks Open Wearables 0.10.0 rebuilds the dashboard in SvelteKit, adds 42 nutrition series types with a meal event, tags every data webhook with the sync it came from and splits calories into total, active and basal energy. Contains breaking changes. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/blog/why-teams-move-from-hosted-wearable-api-to-open-wearables # Why teams move from a hosted wearable API to Open Wearables [All posts](https://openwearables.io/blog) [Guides](https://openwearables.io/blog/category/guides) Open Wearables Team · Oct 26, 2026 · 7 min read ## Key takeaways - A hosted wearable API is a sensible way to start: someone else runs it, and the provider approvals are already in place. - As wearable data becomes the foundation of a product, teams want the provider apps in their name, the data in their own cloud and the schema in their own database. Open Wearables is built for that. - Four things push teams to move now: provider terms that expect your own app, enterprise security reviews, residency requirements, and the need to control change. - After the move, your product reads one standard schema from your own deployment, and the provider relationships are yours. In exchange, you run the deployment or have it run for you in your account, and users reconnect once. - If speed matters more than control and nobody is asking where the data sits, a hosted API is still a reasonable choice. If that is changing, Momentum can help you move. ## A hosted API is a good way to start Most teams that read wearable data started with a hosted API, and for good reasons. One integration covers many devices, the provider approvals are already in place, and someone else keeps the connections running. For a product finding its feet, that speed is worth a lot. The trade-offs show up later, as the product grows. Wearable data stops being a feature and becomes the layer that coaching, care programmes, insurer and employer products are built on. Then the questions change: whose provider apps are these, whose cloud does the data sit in, and what happens when either of those has to change? ## Two architectures, side by side With a hosted wearable API, data flows from each provider through the vendor's infrastructure before it reaches your product. The provider apps are registered to the vendor, the data sits on the vendor's schema, and their team operates the service. With Open Wearables, the same providers connect inside a cloud account you own. Open Wearables is an open-source platform for wearable and health data, MIT licensed and built by Momentum. It connects to the devices your users already own, standardises what comes back into one schema, and runs inside your own account rather than ours. - **Where the data sits:** Hosted wearable API: the vendor's cloud. Open Wearables: your account, your region. - **Who operates it:** Hosted wearable API: the vendor. Open Wearables: you, or we run it in your account. - **Whose provider apps:** Hosted wearable API: the vendor's. Open Wearables: yours, registered in your name. - **The data model:** Hosted wearable API: the vendor's schema. Open Wearables: one standard schema in your own database. - **Time to first data:** Hosted wearable API: minutes, on their infrastructure. Open Wearables: minutes locally, then a deployment. - **Leaving later:** Hosted wearable API: you rebuild on somebody else's model. Open Wearables: already yours. Neither column wins every row. A hosted API reaches working data faster. Open Wearables gives you the layer itself. ## What your product gets after the move **One schema, in your own database.** Activity, sleep, heart rate and body measurements come back in the same shape whichever device produced them. Your product queries the user, not the provider. **The raw payloads, if you want them.** The original provider payload can be kept underneath the standard schema, so anything can be re-derived later without going back to the provider. **Every way in, from one deployment.** Cloud providers connect server to server under your credentials. Apple Health, Health Connect and Samsung Health sync from the phone through the mobile SDK. Your product reads it all over the REST API, reacts to webhooks, or lets an AI assistant ask questions through the MCP server. **Health scores where you need them.** With Pro, health scores designed and validated by our science team are computed inside your deployment, next to the data they come from. **Code you can read.** The source, the roadmap and the issues are public. We are working toward Open Wearables 1.0, and the roadmap shows what is live and what is still being built. ## Why teams make the move now ### Provider terms expect your own app Device makers increasingly want a direct relationship with the company that builds the product. Garmin's reopened developer program expects each company to register its own app and hold its own credentials, and its agreement does not allow passing keys or data to a third party without written permission. Strava's API agreement carries a similar rule on API tokens. With Open Wearables, the provider apps are registered in your name, so the relationship is yours. ### Security reviews ask where the data sits Enterprise customers, insurers and care providers send security questionnaires before they sign, and the questions are consistent: where is member data stored, who can reach it, and what happens on a bad day. When Open Wearables runs in your own cloud account, behind the network rules and monitoring you already have, the answers are about your environment. When Momentum works on your system, it does so under a DPA you sign. ### Some markets set residency rules Some contracts and regulators require health data to stay inside a country or region. Your Open Wearables deployment runs in the region you choose, and you can evidence it by pointing at your own cloud account rather than at a vendor's policy page. ### Teams want to control change Providers change their APIs, their algorithms and their terms. With your own deployment, you decide when to upgrade, test changes in staging first, and see fixes for provider changes land in the public repository. Your history sits in your own database rather than behind someone else's retention window, which matters when a feature you build next year has to run on data you collected this year. ## What the move asks of you It is worth being plain about the trade-offs. You need provider credentials in your own name, and approval takes longer with some providers than others. You run the deployment yourself, or pay someone to run it in your account, so infrastructure, monitoring and upgrades become someone's job. And your users reconnect once, because their existing connections belong to the hosted service's apps. If speed matters more than control and nobody is asking where your data sits, a hosted API is still a reasonable choice. If either of those is changing, moving early usually means fewer hard conversations later. ## How the move works Moving from a hosted API to Open Wearables is usually a re-integration rather than a data migration. Your history stays where it is, new data lands in your own deployment from the switch onwards, and most teams run both side by side before cutting over. The full sequence, from the architecture audit to switching off the hosted API, is in our [migration playbook](https://openwearables.io/blog/hosted-wearable-api-to-open-wearables-migration-playbook), and the [migration page](https://openwearables.io/migrate) shows how a move runs. ## How Momentum supports the move You can move to Open Wearables entirely on your own, with the documentation and the community on Discord. When a launch date, an enterprise customer or the size of your user base makes that harder, Momentum, the team that builds Open Wearables, offers: - **Deployment:** production and staging in your cloud and region, providers onboarded under your credentials, infrastructure as code in your repository. - **Integration:** the connection and consent flow built into your app, tested end to end. - **Enterprise support:** an SLA, a named on-call, provider changes handled and upgrades tested in staging first. - **Custom development:** a migration off a hosted API planned and run with your team, new sources, and AI or coaching features on top. Whichever you choose, the deployment and the data stay in your account. ## FAQ ### Is there a hosted version of Open Wearables? No. You host it in your own cloud account, or we run it there for you. That is the design rather than a gap: the reason teams move is that the data stops passing through a vendor's cloud. ### Will our users notice the move? Once. Each user reconnects their device to your app, because their existing connection belongs to the hosted service. Planned well, it is a single tap in your product. ### What do we need to run Open Wearables? If you can run a PostgreSQL database and deploy Docker containers, you can run it. It deploys with Docker Compose to start and infrastructure as code for production. ### What happens if Open Wearables stops being maintained? You keep everything. The code is MIT licensed and the deployment is in your account, which is a different position from a hosted service shutting down. ### Can we move one provider at a time? Yes. Many teams start with the providers their users connect most, and move the rest once the first ones are proven. ## Open Wearables Open Wearables is an open-source platform that connects your application to wearable and health data providers through a single API. One normalized data model, multi-provider support in a single self-hosted deployment, MIT licensed, and health intelligence built in: normalized recovery, sleep, activity and biometric data ready for your product layer. We offer custom deployment and integration support through Momentum. If your team needs help getting to production faster, we can set up and configure Open Wearables as part of a managed engagement. [Let's talk](https://www.themomentum.ai/lets-talk). [Book a demo](https://openwearables.io/book) to see how Open Wearables fits your use case. ## See related articles - [Moving from a hosted wearable API to Open Wearables: a migration playbook](https://openwearables.io/blog/hosted-wearable-api-to-open-wearables-migration-playbook) - [Wearable API integration: comparing SaaS, custom build, and open source](https://openwearables.io/blog/wearable-api-integration-saas-custom-build-open-source) - [What Is an Open Source Wearable API and When Does It Make Sense](https://openwearables.io/blog/what-is-open-source-wearable-api-when-does-it-make-sense) ## Keep reading Guides · Oct 26, 2026 · 9 min read ### Moving from a hosted wearable API to Open Wearables: a migration playbook Moving from a hosted wearable API to Open Wearables is usually a re-integration rather than a data migration. This playbook walks through the decisions, the steps in order, how your users reconnect and what to tell your security team. Guides · Jul 28, 2026 · 5 min read ### How Wearable Data Flows From Device to Your API: A Complete Architecture Guide Wearable data does not go directly from device to your API. It flows through the provider cloud, then Open Wearables, then PostgreSQL, then your application. Here is what each step looks like. Guides · Jul 22, 2026 · 5 min read ### How to Build an AI Agent That Reasons Over Health Data An AI agent that reasons over health data is different from one that reads it. Here is how the Open Wearables MCP server works and how to build the reasoning layer on top of it. ## Run it in your own cloud Open Wearables is open source and self-hosted. Start from the repository, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) --- Source: https://openwearables.io/case-studies # Built with Open Wearables Case studies Teams running Open Wearables in production, each in their own cloud account. Every case study below has their numbers, how long it took and who did the work. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) Trusted by - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo Case studies ## How teams shipped it. Heart Monitor Consumer heart health app ### How Heart Monitor shipped wearable integrations in a week Active users ~90,000 From SDK to production 1 week Engineer on the integration 1 Read the case study Lifelong Family health app ### How Lifelong is building an AI health companion for the whole family Users with a wearable connected 87% To the first Apple Watch data 5 days Commit in their repository 2nd Read the case study MoveTogether Social fitness app ### How MoveTogether runs on one wearable data layer Brands connected 6 Integration to maintain 1 Per-vendor OAuth flows built 0 Read the case study JustGains Social workout platform ### How JustGains puts every run, ride and rep in one feed To Strava in the feed 1 day Engineer on the integration 1 Countries with members 58 Read the case study In their words > “Open Wearables was our second commit. Five days later, we had real Apple Watch data in Lifelong. It let us start building the family experience instead of rebuilding wearable ingestion.” Razi Syed · Founder, Lifelong [trylifelong.com](https://trylifelong.com/) ## Your product could be next. Every team above runs the same open-source project, in an account they own. Clone it and run it yourself, or see what it costs to have us stand it up inside your account. [Get started](https://openwearables.io/docs/quickstart) [See pricing](https://openwearables.io/pricing) FAQ ## Common questions. ### How many companies run Open Wearables? We do not know, and that is normal for an MIT licensed project: running it takes nobody's permission and generates no signup. What is public is the [repository](https://github.com/the-momentum/open-wearables), where the forks and the contributor list are visible to anyone. A fork is somebody running the code, which makes it a better signal than stars. ### Why are there only a few names here? Because we name a company when they have agreed to it in writing. Plenty of teams are under agreements that say nothing about marketing, and putting somebody's logo on our site is a claim about their business. A name you can check beats a row of logos with no case study behind any of them. ### Is it running at real scale, or just in pilots? Heart Monitor runs it in production at around 90,000 monthly active users. [The case study](https://openwearables.io/case-study/heart-monitor) has the detail, including how long the integration took and who did it. ### Did these teams stand it up themselves, or did you do it? Both happen, and each case study says which. Some teams adopt the open-source project and ship it with their own engineers. Others buy a deployment and we stand it up inside their account, usually when there is a launch date. The architecture is the same either way, and so is who owns the account. ### We run Open Wearables. Can we be listed? Yes, and we would like that. There are two levels: a logo here, or a full case study with your own numbers. Both need your written go-ahead, and the case study needs an hour or two of somebody's time. Tell us in [Discord](https://discord.gg/qrcfFnNE6H) or open a discussion. ### We would rather not be named. Does that matter? Not at all, and it is common. If you are running it and would rather stay quiet about your stack, nothing changes for you. It is still useful to us to know what people run in production, because it tells us which providers to prioritise and what belongs in the next release. ### Can we talk to one of your adopters before we commit? Ask us. Whether an introduction is possible depends on them rather than on us, but we will tell you what we can arrange instead of promising a reference call we cannot deliver. --- Source: https://openwearables.io/case-study/heart-monitor # How Heart Monitor shipped wearable integrations in a week. Case study Heart Monitor logo A consumer heart health app with around 90,000 active users on iOS and Android. Native integrations would have taken months. It took a week, and every reading stays in their own infrastructure. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) Active users ~90,000 From SDK to production 1 week Engineer on the integration 1 Providers in production 6 The problem ## Six ecosystems, one user, no single view. The data Heart Monitor needed was already on its users' wrists, spread across six providers that each describe the same reading differently. ### Wearable data at the core Heart Monitor's own readings mean more next to what a watch or ring records all day: heart rate, sleep and activity. Without them, the app saw a user only when they opened it. ### Six schemas for one reading The same heart rate arrives in a different shape from every provider, behind its own authorisation flow and quirks. Integrated one by one, a feature becomes a roadmap. The solution ## One API, normalised from day one. Heart Monitor runs Open Wearables, the MIT-licensed self-hosted platform, in their own infrastructure. Their engineer built against one REST API instead of six. ### One schema across providers Activity, sleep and heart rate arrive in the same shape whatever device produced them, deduplicated where sources overlap. ### Native SDKs in the app The connection and consent screens live inside Heart Monitor's own interface on iOS and Android, not in a vendor widget. ### Their infrastructure, their data Self-hosted from the start, in infrastructure Heart Monitor controls, so no copy of a user's health history sits in a third party's tenant. ### History that compounds Raw provider payloads are kept under the normalised schema, so a score they decide to compute next year runs on data they already hold. The stack ## Built into the stack they already had. ### Providers Apple Health, Google Health Connect, Samsung Health, Garmin, Polar and Strava, each under credentials in Heart Monitor's name. ### Infrastructure Docker Compose, self-hosted, with Open Wearables running beside their own services. ### Backend Hasura and GraphQL, reading the normalised data next to everything else the app knows. ### Mobile Flutter, with the Open Wearables SDK for iOS and Android inside the app. How it came together ## A week, start to production. 01 Deploy ### The platform came up first Docker Compose in their own environment, before any provider was connected, with each provider's credentials issued in Heart Monitor's own name. 02 Connect ### The SDK went into the Flutter app Connection and consent inside their existing login, so users never left the app to link a device and never saw a second account. 03 Land ### Data landed in their own schema Normalised, deduplicated and queryable next to everything the app already knew about that user. Data ownership ## Data stays where it belongs. ### Their account, their credentials The deployment runs in infrastructure Heart Monitor controls, with every provider app registered in their name. ### No vendor tenant Nobody holds a copy, so retention is their decision and a security review has one fewer name to examine. ### Run by their own team One deployment serves around 90,000 users, operated by Heart Monitor rather than by a vendor. Heart Monitor's Wearable Providers screen: Apple Health connected and syncing, Garmin and Polar ready to connect The result ## What shipped. Around 90,000 users can connect their own devices from inside the app, and six providers run reliably in production feeding one normalised schema. The integration work that would have been a quarter became a week of one engineer's time. ### What it unlocked next. Because the data arrives in one shape and the history stays in their own database, health scoring and personalised recommendations became a query against data they already have rather than a second integration project. ## Ship wearable integrations the same way. Heart Monitor started from the public repository and shipped it with their own team. Clone it and run it in your own infrastructure, or see what it costs to have us stand it up inside your account. [Get started](https://openwearables.io/docs/quickstart) [See pricing](https://openwearables.io/pricing) FAQ ## Questions this raises. ### Is a week typical, or was this a good run? A week is fast and it is not a promise. What made it possible here: one platform to integrate against instead of six, SDKs that handled the in-app consent flow, and an engineer who already knew the codebase. Bringing the platform up takes minutes with Docker Compose. What varies is provider credentials, because each source issues them to your organisation on its own timeline, and that work can start before anything else. ### One engineer for six providers. What did that person have to know? Their own stack, and how to read an API. No wearable-specific expertise, because the provider quirks sit inside Open Wearables rather than in the application code. Nobody had to learn six authorisation models or six data shapes. ### Does 90,000 users prove it is stable at scale? It proves this deployment serves that many users in production, which is the most honest thing we can say. It is not a load test report and we will not dress it up as one. If your question is about a specific volume or pattern, ask and we will tell you what we have measured and what we have not. ### Did you build this for them? No. Heart Monitor adopted the open-source project and their own engineer did the integration. We name them with their permission, not to describe work we sold. Where a team wants us to stand it up inside their account, that is a deployment, priced on the [pricing page](https://openwearables.io/pricing). ### Do we need the same stack as theirs? No. Flutter, Hasura and GraphQL are their choices, and Open Wearables went in underneath without dictating any of them. It needs somewhere to run and a database; the rest of your architecture stays yours. ### What if we need a different set of providers? The work is the same shape whichever sources you pick, because you integrate once against one schema rather than once per provider. What changes is credential approval, which is slower with some sources than others. [Integrations](https://openwearables.io/integrations) has a page per source with what each one returns. --- Source: https://openwearables.io/case-study/justgains # How JustGains puts every run, ride and rep in one feed. Case study [JustGains, their site](https://justgains.com/) JustGains is an open social workout platform where lifting and cardio share one feed and one history. Open Wearables brings in what members' watches already recorded, and being open source let the team build on top of it. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) To Strava in the feed 1 day Engineer on the integration 1 Countries with members 58 Platforms: iOS, Android and web 3 The problem ## Their training was already being recorded. Just not by JustGains. A run lives in Strava, a ride on a Garmin, a gym session in JustGains. Asking people to record everything twice is how you lose them. ### One complete history Every run, ride, swim and hike lands in JustGains automatically, next to the lifting. ### Routes as a real feature Not “you ran 8 km”, but the GPS line itself, to draw, share, replay and rank. ### No duplicates When a watch and the app record the same session, members see one activity with the best data from each. The integration ## One integration, every provider. One engineer did it, from the first sync to a fork they now extend themselves. 01 ### Connect through Open Wearables OAuth, tokens, provider quirks and webhook delivery were already solved, so the first provider was in the feed within a day. 02 ### Self-host it next to their stack Their fork runs alongside the rest of their infrastructure, with Postgres, Redis and signed webhooks. 03 ### Wire it into their API One service class holds all of it: activities arrive by webhook, with an hourly sync as a safety net, into one normalised record. 04 ### Reconcile and extend Watch activities link to the gym workout they overlap, duplicates fold into one, and what the product needed next went into their fork. What surprised them ## The hard parts were already solved. ### How quickly it became real OAuth, tokens, provider quirks and webhook delivery were already solved. ### How readable the codebase is When they needed something new, they found the place and added it. ### How little glue they needed One service class and one webhook controller hold all of it. In their words > “With Open Wearables we had Strava activities flowing into the JustGains feed in a day. When we needed route data it didn't return yet, we didn't wait on a vendor: we read the code, added it to our fork, and shipped. That is the difference open source makes.” James Greene Founder & Engineer, JustGains JustGains logo [justgains.com](https://justgains.com/) The deciding factor ## Open source was the deciding factor. Routes are the heart of their cardio product, and Open Wearables did not keep a Strava workout's route or name yet. With a closed aggregator that ends the conversation. They read the code and added it to their fork. Commits of their own 7 Files changed 44 Lines added 2,496 Additions, all additive 4 ### Routes and names Every synced workout keeps its GPS line and its title, not just its distance. ### Instant webhooks A five-line fix so workout.created fires straight away for a single new run. ### Elevation profiles Up to 300 points per activity, low and high preserved, with tests and docs. ### Their deployment Configs, a deploy script and a guide for the whole stack on their host. The stack ## One service class away from every device. ### Providers OAuth and provider webhooks. Strava is live; Garmin, Polar, Suunto, Oura, WHOOP and Fitbit run through the same pipeline. ### Their Open Wearables fork Self-hosted on Fly.io: API, Postgres and Redis, Svix webhooks, and their own additions for routes and elevation. ### The JustGains API .NET on Postgres. One service class is the only Open Wearables code; sync and reconciliation sit beside it. ### The apps iOS, Android and web: the activity feed, training history, routes, leaderboards and replays. In the app ## A synced run becomes a route. Cardio recorded anywhere sits next to the lifting, and the GPS line becomes something members can open, run and compete on. ### Synced from Strava Route, distance, climb, pace and energy, with where it came from on every activity. A hike synced from Strava in JustGains, with its map and stats ### Becomes a route Follow it, export GPX, race the leaderboard. The same hike saved as a route in JustGains: Follow & record, Save route, Export GPX and a leaderboard ### Replay A flyover of an activity JustGains never recorded itself. A flyover replay of the hike in JustGains, 2.44 km into the route JustGains' Connected Apps with every supported provider connected: Garmin, Polar, Suunto, WHOOP, Strava, Oura and Fitbit The result ## Connect once. Then forget about it. Connected Apps lists whatever their Open Wearables instance has enabled. A member taps a provider, approves it, and activities start arriving on their own: by webhook, with an hourly sync as a safety net. ### Strava is live for all members today. Activities, routes, heart rate, calories and elevation flow into the feed, history, routes and leaderboards. The other providers already run through the same pipeline and are turned on as each is verified. What's next ## Where they want to take it. ### More providers Garmin, Polar, Oura, WHOOP, Suunto and Fitbit already run through the same pipeline, turned on as each is verified. ### Recovery into training Sleep, HRV and readiness shaping what the workout engine suggests for the day. ### Coaching Coaches see a client's full picture, including what their watch recorded between sessions. ### Contributing back Upstreaming routes, names, elevation profiles and the webhook fix. ## Build on top of it, not around it. JustGains started from the public repository, forked it and shipped their own additions. Clone it and run it yourself, or see what it costs to have us stand it up inside your account. [Get started](https://openwearables.io/docs/quickstart) [See pricing](https://openwearables.io/pricing) FAQ ## Questions this raises. ### Did JustGains have to fork Open Wearables? They chose to. Routes were missing for their product, so they added them to a fork with every change additive, and they merge upstream releases into it, most recently 0.6.3. They plan to contribute their additions back. ### How do they stop the same workout appearing twice? Their activity record is idempotent on the provider and its external id, and a reconciliation step links a watch activity to the gym workout it overlaps, folding cross-source duplicates into one. ### Which providers are live? Strava is live for all members. Garmin, Polar, Oura, WHOOP, Suunto and Fitbit already run through the same pipeline and are being turned on as each is verified. --- Source: https://openwearables.io/case-study/lifelong # How Lifelong is building an AI health companion for the whole family. Case study [Lifelong, their site](https://trylifelong.com/) Lifelong brings wearable data and health records into one shared picture for a family, with an AI health companion, Alo, to help make sense of it. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) Users with a wearable connected 87% Commit in their repository 2nd To the first Apple Watch data 5 days Co-founders building it 3 The problem ## A family needs to know how someone else is doing. A parent can say they're fine while their sleep has been poor all week. The person worrying about them has very little to go on. ### Context between appointments Records say what happened at the clinic. Sleep and activity say something about the days around it. Neither is the whole story on its own. ### Nobody logs their HRV You can't ask grandpa to log his HRV. Background sync had to be part of the product from the start, on data Lifelong controls. The integration ## Real data in five days. 01 ### Open Wearables was the second commit The first commit was the app starter. The second brought Open Wearables into the project. 02 ### Self-hosted in about three days The foundation went up on their own infrastructure, with credentials kept server-side so families never have to think about any of it. 03 ### Day five: 1,650 steps The first Apple Watch reading made it all the way into Lifelong, and the team could start building the family experience on real data. 04 ### Reliable background sync Two weeks in, background sync was working reliably, and Param, a co-founder, took over the health engineering. In their words > “Open Wearables was our second commit. Five days later, we had real Apple Watch data in Lifelong. It let us start building the family experience instead of rebuilding wearable ingestion.” Razi Syed Founder, Lifelong Lifelong logo [trylifelong.com](https://trylifelong.com/) The deciding factor ## Connecting a wearable should be like signing in. It should work, then get out of the way. The founders had built wearable infrastructure before and knew how much sits behind a simple connection. ### More thorough than their own The intricacies were handled more thoroughly than what they had tried to build themselves. That rigour made it an easy decision. ### Theirs to change Open source, MIT-licensed and self-hostable, so they move quickly, keep the raw stream on their own infrastructure and fix what real users expose. ### Time for what's different Engineering goes into understanding a family's health over time, not into ingestion. Their own scoring sits beside the data. The stack ## Open Wearables does the thinking, their app does the showing. ### The app Expo and React Native on iOS. The Open Wearables React Native SDK syncs Apple Health data in the background. ### A small gateway Checks who the user is and hands the app its Open Wearables token, so credentials never ship inside the app. ### Their own Open Wearables Self-hosted on Railway: API, workers and scheduler on Postgres and Redis, with their own daily scores and baselines worked out next to the raw data. ### The app backend Convex adds the AI layer and keeps every family member's app up to date, live. In the app ## Health insight, ambiently. Wearables show how someone slept, moved and recovered, without anyone opening the app to type something in. ### Daily scores Sleep, activity and recovery for each family member, ready when they wake up, set against their own baseline. Lifelong's home screen: the family in a row and today's sleep, activity and rest scores ### A shared family view Everyone's steps and sleep side by side, with access chosen by the person sharing their data. Lifelong's Family Steps: each family member's weekly steps, the family average 8,104 ### A night, explained The detail behind a score, so Alo can answer a question like 'how has Mum been sleeping?' from her actual data. A night of sleep in Lifelong: time asleep through the night, duration 6h 16m, efficiency 88% What's next ## Where they're taking it. Separate from what is live today. ### Android A family shouldn't be split by which phone each person owns. Health Connect through Open Wearables is the route they're evaluating. ### Direct provider connections Most data reaches them through Apple Health today. Direct connections could bring richer provider-specific data. ### Trends alongside records Helping a family notice a change in sleep around a medication change, with the context in front of them. ### Closer to upstream Bringing their own scoring back onto mainline Open Wearables without losing what families use today. Lifelong's family updates: Dad finished a morning run, Mum's recovery is up three days in a row, Son slept through the night The result ## What shipped. Today wearable data supports daily scores, personal baselines, AI-explained alerts, the shared family view and Alo's answers. In the 30 September snapshot, 87% of users had connected a wearable. ### What success looks like. A family understanding a change in wearable scores without spending an evening collecting screenshots to explain it. Not another dashboard for the organised sibling to manage, but some of that person's time back. ## Build your product on the data layer, not in it. Lifelong started from the public repository and runs it on their own infrastructure. Clone it and run it yourself, or see what it costs to have us stand it up inside your account. [Get started](https://openwearables.io/docs/quickstart) [See pricing](https://openwearables.io/pricing) FAQ ## Questions this raises. ### Did Lifelong change Open Wearables itself? Yes. They keep its code in their monorepo and added their own scoring on top, so each person's daily scores and baseline are worked out next to the raw data. They are assessing how to bring that work back onto mainline. ### How do the credentials stay out of the app? A small gateway of their own checks who the user is and hands the app its Open Wearables token, as the Open Wearables docs recommend. The credentials never ship inside the app. ### Is Lifelong on Android? Not yet. The app is iOS today, and Health Connect through Open Wearables is the route they're evaluating for Android. --- Source: https://openwearables.io/case-study/movetogether # How MoveTogether runs on one wearable data layer. Case study [MoveTogether, their site](https://movetogetherfitness.com/) A social fitness app where members compete in leagues and group challenges, with an AI coach that reads real activity. Every device a member owns had to work, and the team behind it is small. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) Brands connected 6 Integration to maintain 1 Per-vendor OAuth flows built 0 Sync modes: on demand + scheduled 2 The problem ## Every brand is its own integration. A competition only works if everyone's steps count the same way, whatever device each member already wears. ### A separate integration per brand Done natively, every brand is its own OAuth flow, data model and set of quirks, each one changing on its own schedule. ### A standing commitment for a small team Every provider added is another thing that can break in a release you did not ship, and the maintenance does not scale down with the team. The solution ## One layer, all of it. Open Wearables is MoveTogether's entire third-party wearable layer. Rather than integrating each brand, they integrated once and the platform handles what sits underneath. ### Server to server Open Wearables manages the OAuth handshakes and token storage for every connected brand, so none of that lives in MoveTogether's codebase. ### One normalised shape Daily activity and sleep summaries arrive identically whatever produced them, which is what makes a leaderboard fair across devices. ### Refresh on their terms On demand when a member opens the app, scheduled the rest of the time. ### Their data, their deployment Self-hosted, so the activity history behind every competition stays in infrastructure they control. In their words > “Open Wearables is our entire third-party wearable layer. We connect Fitbit, Garmin, WHOOP, Oura, Strava, and Polar through a single integration, no per-vendor OAuth to maintain, one normalized data shape feeding our whole competition and coaching engine. It let a small team ship a broad device lineup and keep it current.” Sam Pullen Founder, MoveTogether MoveTogether logo [movetogetherfitness.com](https://movetogetherfitness.com/) The data ## What arrives in one shape. Everything the competition engine and the AI coach read comes through the same schema, whatever device produced it. - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Strava integration](https://openwearables.io/integrations/strava) - [Polar integration](https://openwearables.io/integrations/polar) - [Apple Health integration](https://openwearables.io/integrations/apple-health) Open Wearables · one schema - steps - active_calories - exercise_minutes - workouts - sleep Six brands server to server, plus Apple Health on the device through HealthKit. - Steps Competitions and leaderboards. - Active calories Challenge scoring. - Exercise minutes Streaks and goals. - Workouts Activity history and coaching context. - Sleep Recovery context for the AI coach. In the app ## What members see. Every screen runs on the same normalised data, whichever device a member wears. ### Today's activity Move, exercise and steps rings, closed from whatever a member's watch or ring recorded. MoveTogether's home screen: today's Move, Exercise and Steps rings and a workout streak ### Competitions Weekly challenges between friends, scored the same way for every brand in the group. MoveTogether's Compete screen: an athlete league and the weekly competitions a member is in ### AI coach Mo reads a member's real activity and sleep, then plans the fastest way to close today's gap. MoveTogether's AI coach, Mo: how far a member is behind today and a plan built on their usual activity MoveTogether's Athlete League: members ranked by points across devices, with a promotion zone The result ## A broad device lineup, kept current by a small team. MoveTogether shipped support for six brands without building a single per-vendor OAuth flow. Every connected device feeds the same normalised schema, so competition scoring, leaderboards, streaks and the AI coach treat them equally, with no device-specific branches in the product logic. ### The part that matters for a small team is what happens after launch. Provider changes land in the open-source core rather than in their sprint, which is why a broad lineup stayed maintainable rather than becoming the thing the team works on. ## Support every device your users own. MoveTogether started from the public repository and shipped it with their own team. Clone it and run it in your own infrastructure, or see what it costs to have us stand it up inside your account. [Get started](https://openwearables.io/docs/quickstart) [See pricing](https://openwearables.io/pricing) FAQ ## Questions this raises. ### What happens when one of those providers changes their API? The fix lands in the open-source core rather than in their sprint. That is the part that makes a broad device lineup survivable for a small team: the maintenance is shared across everyone running the project, instead of being six separate things each team tracks alone. ### Can a brand be added later, or is the lineup fixed at launch? Added later, and it does not change the application code. Because every source arrives in the same schema, the competition scoring and the coaching engine do not know which device produced a reading. A new brand is a connection, not a feature. ### Does a small team need you to keep this running? Not for this shape of deployment. MoveTogether runs it themselves, and ongoing maintenance from us is a decision a team can take later rather than a dependency they start with. What we sell is the work of standing it up or keeping it current, never access to the software. --- Source: https://openwearables.io/compare # Open Wearables compared with the hosted wearable APIs. Compare Compare hosted wearable APIs with a platform you run in your own cloud. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) ## Which platform are you comparing? ### Terra [View comparison](https://openwearables.io/compare/terra) ### Junction [View comparison](https://openwearables.io/compare/junction) ### Spike [View comparison](https://openwearables.io/compare/spike) ### ROOK [View comparison](https://openwearables.io/compare/rook) ### Sahha [View comparison](https://openwearables.io/compare/sahha) The short version ## What is actually different. Coverage and pricing vary. The shared difference is where your data sits, who operates the infrastructure and who owns the schema. | | Hosted wearable APIs | Open Wearables | | --- | --- | --- | | Where the data sits | Their cloud, their regions | Your account, your region | | Who operates it | They do, entirely | You do, or you buy a deployment | | Who can reach the data | The vendor and its sub-processors | Your team, and us under a DPA you sign when we work on it | | The data model | Theirs. You build against their schema | Yours, in your own database | | Scoring logic | Varies by vendor | Designed and validated by our science team, computed in your deployment | | Raw provider payloads | Varies by vendor | Kept in your own bucket when you turn it on | | Time to first data | Minutes to days, on their infrastructure | Minutes locally, then a deployment | | Certifications | Several hold certifications we do not | None held. The deployment sits inside your certified environment | | Cost shape | Grows with your usage | Free to self-host, with paid Pro and Enterprise plans | | Leaving later | You rebuild on somebody else's model | Already yours | The honest version ## When you should not pick us. Three situations where a managed service is the right call. ### Speed matters more than control. A hosted API returns working data in hours. A deployment takes longer, and no amount of arguing changes that. ### Nobody is asking where the data sits. No regulator, no enterprise security review, no contractual residency clause. The architecture argument on these pages only works when something makes a hosted vendor expensive to defend. ### You need the vendor itself certified. Several of them hold certifications we do not. Running inside your own certified environment answers this for most teams, but not for all of them. ## Deploy Open Wearables in your own cloud. The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account with the providers connected and validated on real accounts. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) FAQ ## Common questions. ### Where should we start? With whichever one you are already evaluating. Each page covers the same ground for that specific comparison, so there is no need to read more than one. ### How does Open Wearables compare with Terra? The architecture is the difference: Terra operates the service and holds the data, Open Wearables runs in your own cloud account on a schema you own. The [Terra comparison](https://openwearables.io/compare/terra) has the full table, including the rows where a managed service wins. ### How does Open Wearables compare with Junction? Same architectural split, and Junction covers some sources we do not. The [Junction comparison](https://openwearables.io/compare/junction) sets both out side by side. ### How does Open Wearables compare with Spike? Spike reaches well past wearable data, and we do not. On the wearable layer itself the difference is where it runs and who owns the schema. The [Spike comparison](https://openwearables.io/compare/spike) has the detail. ### How does Open Wearables compare with ROOK? ROOK covers sources beyond wearables. On the wearable layer the difference is where it runs and where the scores are computed. The [ROOK comparison](https://openwearables.io/compare/rook) goes through both. ### How does Open Wearables compare with Sahha? Health scores are where the two differ most. Ours are part of Pro, designed and validated by our science team and computed inside your deployment. The [Sahha comparison](https://openwearables.io/compare/sahha) covers it, including what Sahha returns on every plan. ### Do you support the same devices as the hosted APIs? Open Wearables connects through direct cloud APIs for Garmin, Whoop, Oura, Polar, Suunto, Withings, Strava, Ultrahuman, SensorBio, Google Health API and Fitbit, and reads on-device data from Apple Health, Google Health Connect and Samsung Health through the mobile SDKs. A source we do not cover yet is built on request, usually in two to three weeks. Every source has its page under [integrations](https://openwearables.io/integrations), and the [coverage matrix](https://openwearables.io/docs/providers/coverage) in the docs lists what each one returns. ### What does Open Wearables cost compared with them? Their pricing is published on their own pages and it changes, so read it there. Each comparison links it. Core is free and MIT licensed, and running it costs your own cloud bill, paid directly to your provider and never marked up by us. Pro adds the licensed modules, health scores and the health agent among them, priced per deployment rather than per user. Enterprise is an annual agreement with SLA support. Deployment and Integration are optional one-off services. [Pricing](https://openwearables.io/pricing) has the figures. ### Do you hold SOC 2 or ISO 27001? No. Some hosted vendors do. The deployment runs inside your certified environment, which is how most teams answer this in their own audit, but if you need the vendor itself certified then that is a genuine difference. ### How hard is migrating off one of them? Usually a re-integration rather than a data migration. Your historical data stays where it is, and what changes is where new data lands from the switch onwards. Most teams run both in parallel while they validate, then cut over. It starts with an architecture audit. ### Is it running in production anywhere? Yes. Heart Monitor runs Open Wearables in production at around 90,000 monthly active users. They adopted the open-source project and shipped it with their own team. ### Who maintains Open Wearables? Momentum, a healthcare software development company. The project is MIT licensed and developed in the open, with a public roadmap and public issues, so the source does not depend on us continuing to fund it. --- Source: https://openwearables.io/compare/junction # The Junction API alternative that runs in your own cloud. Open source. Self-hosted. MIT license. The open-source alternative to Junction API. Wearable data in one standard schema, inside your own cloud account, in a region you choose. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) The two architectures ## Their cloud or yours? The key difference is where your data flows and who runs the infrastructure. ### Junction: managed service. Wearable data flows through Junction's infrastructure before reaching your product. Their team runs the service; your product connects to their API. ### Open Wearables: your own deployment. Wearable data lands in your own database, in a cloud account and region you choose. You operate the deployment, with support available from our team. What you get ## What Open Wearables gives you. ### One standard schema Query a user, not a provider. Activity, sleep, heart rate and body measurements come back in one shape, in your own database. - Raw payloads kept - Time series - Webhooks ### Connection flows, maintained Each source has its own authorisation model and its own quirks. All of them are implemented and kept working behind a single endpoint. - Integrations - OAuth - Delivery history ### Custom health scores Health scores designed and validated by our science team, computed inside your deployment. Part of Pro, with custom scores built on request. - Health scores - Science team ### Data off the device On-device sources have no server-to-server API. Native SDKs for iOS, Android, Flutter and React Native handle background sync. - HealthKit - Health Connect ### Shared accounts, no wasted quota One provider account can sit behind several of your user profiles. The payload arrives once and fans out, and a lock stops duplicate calls. - Fan-out - Dedup lock - Quota-safe ### MCP server Point Claude Desktop or Cursor at your own deployment and ask about your data in plain language. - Claude Desktop - Cursor Side by side ## Open Wearables vs Junction, side by side. | | Junction API | Open Wearables | | --- | --- | --- | | Where the data sits | Their cloud, in the US or the EU | Your account, your region | | Who operates it | They do, entirely | You do, or you buy a deployment | | Who can reach the data | The vendor and its sub-processors | Your team, and us under a DPA you sign when we work on it | | The data model | Theirs. You build against their schema | Yours, in your own database, queryable directly | | Scoring logic | Documented readiness scores | Designed and validated by our science team, computed in your deployment | | Adding a source they do not cover | Prioritised requests on Enterprise | Write it yourself, or we build it on request | | Cost shape | Tiers by connected users | Free to self-host, with paid Pro and Enterprise plans | | Time to first data | Days, on their infrastructure | Minutes locally, then a deployment | | Leaving later | You rebuild on somebody else's model | Already yours | Solutions ## Wearable data for your use case. [All solutions](https://openwearables.io/for) ### Digital health products Commercial health products where the data model and what you build on it are part of what you sell. [Learn more](https://openwearables.io/for/digital-health) ### Care providers Run a monitored programme without building the software. [Learn more](https://openwearables.io/for/care-providers) ### Hospitals and telemedicine Wearable data in the EHR your clinicians already open. [Learn more](https://openwearables.io/for/hospitals-telemedicine) ### Health data platforms EHR, telemedicine and aggregator platforms that are already somebody's processor. [Learn more](https://openwearables.io/for/health-data-platforms) ### Remote patient monitoring Readings from the patient's own device, in the record their clinician reads. [Learn more](https://openwearables.io/for/remote-patient-monitoring) ### Clinical and research builders Teams heading for review, who need auditable inputs and documented validation. [Learn more](https://openwearables.io/for/clinical-research) ### Corporate and employer wellness One set of metrics across a member population, with the processor obligations that follow. [Learn more](https://openwearables.io/for/employer-wellness) ### Sports and nutrition brands Training load, fuelling and recovery behind a coaching product. [Learn more](https://openwearables.io/for/sports-nutrition) How it works ## Where the data goes, step by step. Every step runs inside your deployment, in the region you chose. Nothing passes through a Momentum tenant on the way. [See the platform](https://openwearables.io/platform) 01 ### Collect Cloud providers connect server to server, and the mobile SDKs read the stores that live on the phone. Every source ends up in the same deployment, in your account. 02 ### Store Everything lands in one schema in your own database, in your chosen region, with the original payload kept underneath if you switch that on. 03 ### Compute With Pro, health scores from our science team, computed inside your deployment. 04 ### Use Your product reads it over the REST API, reacts to webhooks, or asks questions through the MCP server, all against the same deployment. More comparisons ## Compare Open Wearables with other vendors. ### [Terra API](https://openwearables.io/compare/terra) ### [Sahha](https://openwearables.io/compare/sahha) ### [ROOK](https://openwearables.io/compare/rook) ### [Spike API](https://openwearables.io/compare/spike) ## Connect the devices your users already own. The coverage matrix lists what each source returns, so you can check it against the providers you need rather than against a total. New sources land in the open-source repository first, so it is always ahead of this page. [Browse integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## Deploy Open Wearables in your own cloud. The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account with the providers connected and validated on real accounts. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) FAQ ## Common questions. ### How does Junction API pricing work? Two plans: a monthly plan up to a set number of connected users, and an annual Enterprise plan with unlimited users, volume discounts and lab testing. Their current plans and figures are on [Junction's pricing page](https://www.junction.com/pricing). ### What does Open Wearables cost? Core is free and MIT licensed, and running it costs your own cloud bill, paid directly to your provider and never marked up by us. Pro adds the licensed modules, health scores and the health agent among them, priced per deployment rather than per user. Enterprise is an annual agreement with SLA support. Deployment and Integration are optional one-off services. [Pricing](https://openwearables.io/pricing) has the figures. ### Is Open Wearables really free? Yes. Core is MIT licensed, with the full source. We charge for Pro, Enterprise, the Deployment and Integration services and custom development. ### Does it support the same devices as Junction? Open Wearables connects through direct cloud APIs for Garmin, Whoop, Oura, Polar, Suunto, Withings, Strava, Ultrahuman, SensorBio, Google Health API and Fitbit, and reads on-device data from Apple Health, Google Health Connect and Samsung Health through the mobile SDKs. A source we do not cover yet is built on request, usually in two to three weeks. Every source has its page under [integrations](https://openwearables.io/integrations), and the [coverage matrix](https://openwearables.io/docs/providers/coverage) in the docs lists what each one returns. ### Junction also does lab testing. Do you? No. Junction covers lab ordering and results alongside wearable data. Open Wearables is the wearable layer only, so if labs are part of what you are buying, that is a real difference and it is worth weighing. ### Is it running in production anywhere? Yes. Heart Monitor runs Open Wearables in production at around 90,000 monthly active users. They adopted the open-source project and shipped it with their own team. ### What about health scores? Health scores designed and validated by our science team, computed inside your own deployment. They are part of Pro, and custom scores are built with our science team. [The scoring layer has its own page](https://openwearables.io/platform/health-scores). ### Do you hold SOC 2 or ISO 27001? No, and Junction lists both. The deployment runs inside your certified environment, which is how most teams answer this in their own audit, but if you need the vendor itself to be certified then that is a genuine difference. ### How hard is the migration? Usually a re-integration rather than a data migration. Your historical data stays where it is, and what changes is where new data lands from the switch onwards. Most teams run both in parallel while they validate, then cut over. It starts with an architecture audit. ### Who maintains Open Wearables? Momentum, a healthcare software development company. The project is MIT licensed and developed in the open, with a public roadmap and public issues, so the source does not depend on us continuing to fund it. --- Source: https://openwearables.io/compare/rook # The ROOK API alternative that runs in your own cloud. Open source. Self-hosted. MIT license. The open-source alternative to the ROOK API. Wearable data in one standard schema, inside your own cloud account, in a region you choose. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) The two architectures ## Their cloud or yours? The key difference is where your data flows and who runs the infrastructure. ### ROOK API: managed service. Wearable data flows through ROOK's infrastructure before reaching your product. Their team runs the service; your product connects to their API. ### Open Wearables: your own deployment. Wearable data lands in your own database, in a cloud account and region you choose. You operate the deployment, with support available from our team. What you get ## What Open Wearables gives you. ### One standard schema Query a user, not a provider. Activity, sleep, heart rate and body measurements come back in one shape, in your own database. - Raw payloads kept - Time series - Webhooks ### Connection flows, maintained Each source has its own authorisation model and its own quirks. All of them are implemented and kept working behind a single endpoint. - Integrations - OAuth - Delivery history ### Custom health scores Health scores designed and validated by our science team, computed inside your deployment. Part of Pro, with custom scores built on request. - Health scores - Science team ### Data off the device On-device sources have no server-to-server API. Native SDKs for iOS, Android, Flutter and React Native handle background sync. - HealthKit - Health Connect ### Shared accounts, no wasted quota One provider account can sit behind several of your user profiles. The payload arrives once and fans out, and a lock stops duplicate calls. - Fan-out - Dedup lock - Quota-safe ### MCP server Point Claude Desktop or Cursor at your own deployment and ask about your data in plain language. - Claude Desktop - Cursor Side by side ## Open Wearables vs the ROOK API, side by side. | | ROOK API | Open Wearables | | --- | --- | --- | | Where the data sits | Their cloud, hosted in the US | Your account, your region | | Who operates it | They do, entirely | You do, or you buy a deployment | | Who can reach the data | The vendor and its sub-processors | Your team, and us under a DPA you sign when we work on it | | The data model | Theirs. You build against their schema | Yours, in your own database, queryable directly | | Scoring logic | A published scoring method | Designed and validated by our science team, computed in your deployment | | Raw provider payloads | Normalised, raw metrics as an add-on | Kept in your own bucket when you turn it on | | Time to first data | Minutes, on their infrastructure | Minutes locally, then a deployment | | Cost shape | Tiers by active users, plus add-ons | Free to self-host, with paid Pro and Enterprise plans | Solutions ## Wearable data for your use case. [All solutions](https://openwearables.io/for) ### Digital health products Commercial health products where the data model and what you build on it are part of what you sell. [Learn more](https://openwearables.io/for/digital-health) ### Care providers Run a monitored programme without building the software. [Learn more](https://openwearables.io/for/care-providers) ### Hospitals and telemedicine Wearable data in the EHR your clinicians already open. [Learn more](https://openwearables.io/for/hospitals-telemedicine) ### Health data platforms EHR, telemedicine and aggregator platforms that are already somebody's processor. [Learn more](https://openwearables.io/for/health-data-platforms) ### Remote patient monitoring Readings from the patient's own device, in the record their clinician reads. [Learn more](https://openwearables.io/for/remote-patient-monitoring) ### Clinical and research builders Teams heading for review, who need auditable inputs and documented validation. [Learn more](https://openwearables.io/for/clinical-research) ### Corporate and employer wellness One set of metrics across a member population, with the processor obligations that follow. [Learn more](https://openwearables.io/for/employer-wellness) ### Sports and nutrition brands Training load, fuelling and recovery behind a coaching product. [Learn more](https://openwearables.io/for/sports-nutrition) How it works ## Where the data goes, step by step. Every step runs inside your deployment, in the region you chose. Nothing passes through a Momentum tenant on the way. [See the platform](https://openwearables.io/platform) 01 ### Collect Cloud providers connect server to server, and the mobile SDKs read the stores that live on the phone. Every source ends up in the same deployment, in your account. 02 ### Store Everything lands in one schema in your own database, in your chosen region, with the original payload kept underneath if you switch that on. 03 ### Compute With Pro, health scores from our science team, computed inside your deployment. 04 ### Use Your product reads it over the REST API, reacts to webhooks, or asks questions through the MCP server, all against the same deployment. More comparisons ## Compare Open Wearables with other vendors. ### [Terra API](https://openwearables.io/compare/terra) ### [Junction](https://openwearables.io/compare/junction) ### [Sahha](https://openwearables.io/compare/sahha) ### [Spike API](https://openwearables.io/compare/spike) ## Connect the devices your users already own. The coverage matrix lists what each source returns, so you can check it against the providers you need rather than against a total. New sources land in the open-source repository first, so it is always ahead of this page. [Browse integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## Deploy Open Wearables in your own cloud. The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account with the providers connected and validated on real accounts. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) FAQ ## Common questions. ### How does ROOK API pricing work? Plans tiered by active users, with add-ons priced separately and lab files billed per file processed. Their current plans and figures are on [ROOK's pricing page](https://tryrook.io/pricing). ### What does Open Wearables cost? Core is free and MIT licensed, and running it costs your own cloud bill, paid directly to your provider and never marked up by us. Pro adds the licensed modules, health scores and the health agent among them, priced per deployment rather than per user. Enterprise is an annual agreement with SLA support. Deployment and Integration are optional one-off services. [Pricing](https://openwearables.io/pricing) has the figures. ### Is Open Wearables really free? Yes. Core is MIT licensed, with the full source. We charge for Pro, Enterprise, the Deployment and Integration services and custom development. ### Does it support the same devices as ROOK API? Open Wearables connects through direct cloud APIs for Garmin, Whoop, Oura, Polar, Suunto, Withings, Strava, Ultrahuman, SensorBio, Google Health API and Fitbit, and reads on-device data from Apple Health, Google Health Connect and Samsung Health through the mobile SDKs. A source we do not cover yet is built on request, usually in two to three weeks. Every source has its page under [integrations](https://openwearables.io/integrations), and the [coverage matrix](https://openwearables.io/docs/providers/coverage) in the docs lists what each one returns. ### ROOK API also covers labs and medical records. Do you? No. ROOK offers lab, medical device and medical records APIs alongside wearable data. Open Wearables is the wearable layer only, so if those sources are part of what you are buying, that is a real difference and it is worth weighing before you decide. ### Is it running in production anywhere? Yes. Heart Monitor runs Open Wearables in production at around 90,000 monthly active users. They adopted the open-source project and shipped it with their own team. ### ROOK has a ready-made app for on-device data. Is there an equivalent? Yes. The [Connect App](https://openwearables.io/platform/connect-app) reads Apple Health and Health Connect for users who join with an invitation code, into your own deployment. A version under your own brand is available on request. Native SDKs for iOS, Android, Flutter and React Native do the same from your own app. ### What about health scores? Health scores designed and validated by our science team, computed inside your own deployment so the data they read stays in your account. They are part of Pro, and each score comes with what it measures and how it was validated. ### Do you hold SOC 2 or ISO 27001? No. The deployment runs inside your certified environment, which is how most teams answer this in their own audit. ### How hard is the migration? Usually a re-integration rather than a data migration. Your historical data stays where it is, and what changes is where new data lands from the switch onwards. Most teams run both in parallel while they validate, then cut over. It starts with an architecture audit. ### Who maintains Open Wearables? Momentum, a healthcare software development company. The project is MIT licensed and developed in the open, with a public roadmap and public issues, so the source does not depend on us continuing to fund it. --- Source: https://openwearables.io/compare/sahha # The Sahha alternative that runs in your own cloud. Open source. Self-hosted. MIT license. Wearable data and health scores in your own cloud account, under your credentials. The scores are designed and validated by our science team and computed inside your deployment. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) The two architectures ## Their cloud or yours? The difference is who controls the infrastructure and where the data and the scores are computed. ### Sahha: managed service. Sahha processes wearable data in its infrastructure and returns scores from its models. Their team runs the service. ### Open Wearables: your own deployment. Wearable data and health scores run in your own cloud account, in a region you choose. The scores come from our science team as a licensed Pro module. What you get ## What Open Wearables gives you. ### One standard schema Query a user, not a provider. Activity, sleep, heart rate and body measurements come back in one shape, in your own database. - Raw payloads kept - Time series - Webhooks ### Connection flows, maintained Each source has its own authorisation model and its own quirks. All of them are implemented and kept working behind a single endpoint. - Integrations - OAuth - Delivery history ### Custom health scores Health scores designed and validated by our science team, computed inside your deployment. Part of Pro, with custom scores built on request. - Health scores - Science team ### Data off the device On-device sources have no server-to-server API. Native SDKs for iOS, Android, Flutter and React Native handle background sync. - HealthKit - Health Connect ### Shared accounts, no wasted quota One provider account can sit behind several of your user profiles. The payload arrives once and fans out, and a lock stops duplicate calls. - Fan-out - Dedup lock - Quota-safe ### MCP server Point Claude Desktop or Cursor at your own deployment and ask about your data in plain language. - Claude Desktop - Cursor Side by side ## Open Wearables vs Sahha, side by side. | | Sahha | Open Wearables | | --- | --- | --- | | Where the data sits | Their cloud, their regions | Your account, your region | | Who can reach the data | The vendor and its sub-processors | Your team, and us under a DPA you sign when we work on it | | Where scores are computed | In their infrastructure | Inside your deployment | | What you get back | Scores, biomarkers and insights from proprietary models | Normalised data, with health scores in Pro | | Explaining a score to a reviewer | Every score comes with its contributing factors | What it measures and how it was validated | | Scores beyond the standard set | Their published set | Custom scores built with our science team | | Device coverage | Broad, mostly through Apple Health and Health Connect | Direct cloud APIs plus on-device sources | | Compliance | SOC 2 Type II certified | Runs inside your own certified environment | | Cost shape | Priced per user above an included allowance | Free to self-host, with paid Pro and Enterprise plans | Solutions ## Wearable data for your use case. [All solutions](https://openwearables.io/for) ### Digital health products Commercial health products where the data model and what you build on it are part of what you sell. [Learn more](https://openwearables.io/for/digital-health) ### Care providers Run a monitored programme without building the software. [Learn more](https://openwearables.io/for/care-providers) ### Hospitals and telemedicine Wearable data in the EHR your clinicians already open. [Learn more](https://openwearables.io/for/hospitals-telemedicine) ### Health data platforms EHR, telemedicine and aggregator platforms that are already somebody's processor. [Learn more](https://openwearables.io/for/health-data-platforms) ### Remote patient monitoring Readings from the patient's own device, in the record their clinician reads. [Learn more](https://openwearables.io/for/remote-patient-monitoring) ### Clinical and research builders Teams heading for review, who need auditable inputs and documented validation. [Learn more](https://openwearables.io/for/clinical-research) ### Corporate and employer wellness One set of metrics across a member population, with the processor obligations that follow. [Learn more](https://openwearables.io/for/employer-wellness) ### Sports and nutrition brands Training load, fuelling and recovery behind a coaching product. [Learn more](https://openwearables.io/for/sports-nutrition) How it works ## Where the data goes, step by step. Every step runs inside your deployment, in the region you chose. Nothing passes through a Momentum tenant on the way. [See the platform](https://openwearables.io/platform) 01 ### Collect Cloud providers connect server to server, and the mobile SDKs read the stores that live on the phone. Every source ends up in the same deployment, in your account. 02 ### Store Everything lands in one schema in your own database, in your chosen region, with the original payload kept underneath if you switch that on. 03 ### Compute With Pro, health scores from our science team, computed inside your deployment. 04 ### Use Your product reads it over the REST API, reacts to webhooks, or asks questions through the MCP server, all against the same deployment. More comparisons ## Compare Open Wearables with other vendors. ### [Terra API](https://openwearables.io/compare/terra) ### [Junction](https://openwearables.io/compare/junction) ### [ROOK](https://openwearables.io/compare/rook) ### [Spike API](https://openwearables.io/compare/spike) ## Connect the devices your users already own. The coverage matrix lists what each source returns, so you can check it against the providers you need rather than against a total. New sources land in the open-source repository first, so it is always ahead of this page. [Browse integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## Deploy Open Wearables in your own cloud. The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account with the providers connected and validated on real accounts. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) FAQ ## Common questions. ### How do your health scores compare with Sahha's? Every Sahha plan returns five scores plus biomarkers, behavioural archetypes, tags and insights, from proprietary models, and every score returns its factor breakdown. Ours are designed and validated by our science team and computed inside your deployment, so the data they read stays in your account. Health scores are a licensed Pro module, and the docs list what is live and what is in development. ### Can we explain a score to a reviewer? Yes. Each score comes with what it measures and how it was validated, which is what a reviewer or a clinician asks for. The scoring method itself stays with our science team. ### Can we cite the scores in a paper or a technical file? You can cite what each score measures and how it was validated. Health scores are a licensed Pro module rather than part of the MIT-licensed Core, so the method is not published with the source. ### How does Sahha's pricing work? Plans billed annually that include a set number of users, with a rate per user above that, and the scores, biomarkers and archetypes included on every plan. Their current plans and figures are on [Sahha's pricing page](https://sahha.ai/pricing). ### What does Open Wearables cost? Core is free and MIT licensed, and running it costs your own cloud bill, paid directly to your provider and never marked up by us. Pro adds the licensed modules, health scores and the health agent among them, priced per deployment rather than per user. Enterprise is an annual agreement with SLA support. Deployment and Integration are optional one-off services. [Pricing](https://openwearables.io/pricing) has the figures. ### Is Open Wearables really free? Yes. Core is MIT licensed, with the full source. We charge for Pro, Enterprise, the Deployment and Integration services and custom development. ### Does it support the same devices as Sahha? Sahha reaches 800+ devices via Apple Health and Health Connect, plus direct cloud APIs for Garmin, Oura and WHOOP. Open Wearables connects through direct cloud APIs for Garmin, Whoop, Oura, Polar, Suunto, Withings, Strava, Ultrahuman, SensorBio, Google Health API and Fitbit, and reads on-device data from Apple Health, Google Health Connect and Samsung Health through the mobile SDKs. A source we do not cover yet is built on request, usually in two to three weeks. Every source has its page under [integrations](https://openwearables.io/integrations), and the [coverage matrix](https://openwearables.io/docs/providers/coverage) in the docs lists what each one returns. ### Is it running in production anywhere? Yes. Heart Monitor runs Open Wearables in production at around 90,000 monthly active users. They adopted the open-source project and shipped it with their own team. ### Do you hold SOC 2 or ISO 27001? No, and Sahha does: SOC 2 Type II, a DPA on every plan and a BAA from Pro. The deployment runs inside your certified environment, which is how most teams answer this in their own audit, but if you need the vendor itself to be certified then that is a genuine difference. ### How hard is the migration? Usually a re-integration rather than a data migration. Your historical data stays where it is, and what changes is where new data lands from the switch onwards. Scores are recomputed from your own data once the deployment is running. Most teams run both in parallel while they validate, then cut over. ### Who maintains Open Wearables? Momentum, a healthcare software development company. The project is MIT licensed and developed in the open, with a public roadmap and public issues, so the source does not depend on us continuing to fund it. --- Source: https://openwearables.io/compare/spike # The Spike API alternative that runs in your own cloud. Open source. Self-hosted. MIT license. The open-source alternative to the Spike API for wearable data. One standard schema, inside your own cloud account, in a region you choose. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) The two architectures ## Their cloud or yours? The key difference is where your data flows and who runs the infrastructure. ### Spike API: managed service. Wearable data flows through Spike's infrastructure before reaching your product. Their team runs the service; your product connects to their API. ### Open Wearables: your own deployment. Wearable data lands in your own database, in a cloud account and region you choose. You operate the deployment, with support available from our team. What you get ## What Open Wearables gives you. ### One standard schema Query a user, not a provider. Activity, sleep, heart rate and body measurements come back in one shape, in your own database. - Raw payloads kept - Time series - Webhooks ### Connection flows, maintained Each source has its own authorisation model and its own quirks. All of them are implemented and kept working behind a single endpoint. - Integrations - OAuth - Delivery history ### Custom health scores Health scores designed and validated by our science team, computed inside your deployment. Part of Pro, with custom scores built on request. - Health scores - Science team ### Data off the device On-device sources have no server-to-server API. Native SDKs for iOS, Android, Flutter and React Native handle background sync. - HealthKit - Health Connect ### Shared accounts, no wasted quota One provider account can sit behind several of your user profiles. The payload arrives once and fans out, and a lock stops duplicate calls. - Fan-out - Dedup lock - Quota-safe ### MCP server Point Claude Desktop or Cursor at your own deployment and ask about your data in plain language. - Claude Desktop - Cursor Side by side ## Open Wearables vs the Spike API, side by side. | | Spike API | Open Wearables | | --- | --- | --- | | Where the data sits | Their cloud, stored in Germany | Your account, your region | | Who operates it | They do, entirely | You do, or you buy a deployment | | Who can reach the data | The vendor and its sub-processors | Your team, and us under a DPA you sign when we work on it | | The data model | Theirs. You build against their schema | Yours, in your own database, queryable directly | | Scoring logic | Proprietary scores, on Enterprise | Designed and validated by our science team, computed in your deployment | | Raw provider payloads | Raw and normalised | Kept in your own bucket when you turn it on | | Cost shape | Usage-based plans | Free to self-host, with paid Pro and Enterprise plans | Solutions ## Wearable data for your use case. [All solutions](https://openwearables.io/for) ### Digital health products Commercial health products where the data model and what you build on it are part of what you sell. [Learn more](https://openwearables.io/for/digital-health) ### Care providers Run a monitored programme without building the software. [Learn more](https://openwearables.io/for/care-providers) ### Hospitals and telemedicine Wearable data in the EHR your clinicians already open. [Learn more](https://openwearables.io/for/hospitals-telemedicine) ### Health data platforms EHR, telemedicine and aggregator platforms that are already somebody's processor. [Learn more](https://openwearables.io/for/health-data-platforms) ### Remote patient monitoring Readings from the patient's own device, in the record their clinician reads. [Learn more](https://openwearables.io/for/remote-patient-monitoring) ### Clinical and research builders Teams heading for review, who need auditable inputs and documented validation. [Learn more](https://openwearables.io/for/clinical-research) ### Corporate and employer wellness One set of metrics across a member population, with the processor obligations that follow. [Learn more](https://openwearables.io/for/employer-wellness) ### Sports and nutrition brands Training load, fuelling and recovery behind a coaching product. [Learn more](https://openwearables.io/for/sports-nutrition) How it works ## Where the data goes, step by step. Every step runs inside your deployment, in the region you chose. Nothing passes through a Momentum tenant on the way. [See the platform](https://openwearables.io/platform) 01 ### Collect Cloud providers connect server to server, and the mobile SDKs read the stores that live on the phone. Every source ends up in the same deployment, in your account. 02 ### Store Everything lands in one schema in your own database, in your chosen region, with the original payload kept underneath if you switch that on. 03 ### Compute With Pro, health scores from our science team, computed inside your deployment. 04 ### Use Your product reads it over the REST API, reacts to webhooks, or asks questions through the MCP server, all against the same deployment. More comparisons ## Compare Open Wearables with other vendors. ### [Terra API](https://openwearables.io/compare/terra) ### [Junction](https://openwearables.io/compare/junction) ### [Sahha](https://openwearables.io/compare/sahha) ### [ROOK](https://openwearables.io/compare/rook) ## Connect the devices your users already own. The coverage matrix lists what each source returns, so you can check it against the providers you need rather than against a total. New sources land in the open-source repository first, so it is always ahead of this page. [Browse integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## Deploy Open Wearables in your own cloud. The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account with the providers connected and validated on real accounts. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) FAQ ## Common questions. ### How does Spike API pricing work? Usage-driven plans from a sandbox tier, with Enterprise quoted and Nutrition AI priced separately. Their current plans and figures are on [Spike's pricing page](https://www.spikeapi.com/pricing). ### What does Open Wearables cost? Core is free and MIT licensed, and running it costs your own cloud bill, paid directly to your provider and never marked up by us. Pro adds the licensed modules, health scores and the health agent among them, priced per deployment rather than per user. Enterprise is an annual agreement with SLA support. Deployment and Integration are optional one-off services. [Pricing](https://openwearables.io/pricing) has the figures. ### Is Open Wearables really free? Yes. Core is MIT licensed, with the full source. We charge for Pro, Enterprise, the Deployment and Integration services and custom development. ### We are building an AI health product. Does that change the choice? It sharpens it. An AI feature is only as defensible as the data underneath it, and a model reasoning over a vendor's API depends on that vendor's schema, retention and roadmap. Here the history sits in your own database, the raw payloads in your own bucket when you turn them on, and the MCP server points at your deployment rather than at somebody else's service. ### Does it support the same devices as Spike API? Open Wearables connects through direct cloud APIs for Garmin, Whoop, Oura, Polar, Suunto, Withings, Strava, Ultrahuman, SensorBio, Google Health API and Fitbit, and reads on-device data from Apple Health, Google Health Connect and Samsung Health through the mobile SDKs. A source we do not cover yet is built on request, usually in two to three weeks. Every source has its page under [integrations](https://openwearables.io/integrations), and the [coverage matrix](https://openwearables.io/docs/providers/coverage) in the docs lists what each one returns. ### Spike covers labs, EMR and nutrition. Do you? No. Spike is a broad health data platform that reaches well past wearables, into lab reports, medical IoT, clinical records and nutrition. Open Wearables is the wearable layer only. If those other sources are part of what you are buying, that is a real difference and the honest answer is that we do not cover them. ### Is it running in production anywhere? Yes. Heart Monitor runs Open Wearables in production at around 90,000 monthly active users. They adopted the open-source project and shipped it with their own team. ### What about health scores? Health scores designed and validated by our science team, computed inside your own deployment so the data they read stays in your account. They are part of Pro, and each score comes with what it measures and how it was validated. ### Do you hold SOC 2 or ISO 27001? No, and Spike does hold certifications we do not. The deployment runs inside your certified environment, which is how most teams answer this in their own audit, but if you need the vendor itself to be certified then that is a genuine difference. ### How hard is the migration? Usually a re-integration rather than a data migration. Your historical data stays where it is, and what changes is where new data lands from the switch onwards. Most teams run both in parallel while they validate, then cut over. It starts with an architecture audit. ### Who maintains Open Wearables? Momentum, a healthcare software development company. The project is MIT licensed and developed in the open, with a public roadmap and public issues, so the source does not depend on us continuing to fund it. --- Source: https://openwearables.io/compare/terra # The Terra API alternative that runs in your own cloud. Open source. Self-hosted. MIT license. The open-source alternative to Terra API. Wearable data in one standard schema, inside your own cloud account, in a region you choose. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) The two architectures ## Their cloud or yours? The key difference is where your data flows and who runs the infrastructure. ### Terra: managed service. Wearable data flows through Terra's infrastructure before reaching your product. Their team runs the service; your product connects to their API. ### Open Wearables: your own deployment. Wearable data lands in your own database, in a cloud account and region you choose. You operate the deployment, with support available from our team. What you get ## What Open Wearables gives you. ### One standard schema Query a user, not a provider. Activity, sleep, heart rate and body measurements come back in one shape, in your own database. - Raw payloads kept - Time series - Webhooks ### Connection flows, maintained Each source has its own authorisation model and its own quirks. All of them are implemented and kept working behind a single endpoint. - Wearable integrations - OAuth flows - Delivery history ### Custom health scores Health scores designed and validated by our science team, computed inside your deployment. Part of Pro, with custom scores built on request. - Health scores - Science team ### Data off the device On-device sources have no server-to-server API. Native SDKs for iOS, Android, Flutter and React Native handle background sync. - HealthKit - Health Connect ### Shared accounts, no wasted quota One provider account can sit behind several of your user profiles. The payload arrives once and fans out, and a lock stops duplicate calls. - Fan-out - Dedup lock - Quota-safe ### MCP server Point Claude Desktop or Cursor at your own deployment and ask about your data in plain language. - Claude Desktop - Cursor Side by side ## Open Wearables vs Terra, side by side. | | Terra API | Open Wearables | | --- | --- | --- | | Where the data sits | Their cloud, in the EU by default | Your account, your region | | Who operates it | They do, entirely | You do, or you buy a deployment | | Who can reach the data | The vendor and its sub-processors | Your team, and us under a DPA you sign when we work on it | | The data model | Theirs. You build against their schema | Yours, in your own database, queryable directly | | Scoring logic | Proprietary scores | Designed and validated by our science team, computed in your deployment | | Adding a source they do not cover | A custom build on Enterprise | Write it yourself, or we build it on request | | Cost shape | Subscription with usage credits | Free to self-host, with paid Pro and Enterprise plans | | Time to first data | Minutes, on their infrastructure | Minutes locally, then a deployment | | Leaving later | You rebuild on somebody else's model | Already yours | Solutions ## Wearable data for your use case. [All solutions](https://openwearables.io/for) ### Digital health products Commercial health products where the data model and what you build on it are part of what you sell. [Learn more](https://openwearables.io/for/digital-health) ### Care providers Run a monitored programme without building the software. [Learn more](https://openwearables.io/for/care-providers) ### Hospitals and telemedicine Wearable data in the EHR your clinicians already open. [Learn more](https://openwearables.io/for/hospitals-telemedicine) ### Health data platforms EHR, telemedicine and aggregator platforms that are already somebody's processor. [Learn more](https://openwearables.io/for/health-data-platforms) ### Remote patient monitoring Readings from the patient's own device, in the record their clinician reads. [Learn more](https://openwearables.io/for/remote-patient-monitoring) ### Clinical and research builders Teams heading for review, who need auditable inputs and documented validation. [Learn more](https://openwearables.io/for/clinical-research) ### Corporate and employer wellness One set of metrics across a member population, with the processor obligations that follow. [Learn more](https://openwearables.io/for/employer-wellness) ### Sports and nutrition brands Training load, fuelling and recovery behind a coaching product. [Learn more](https://openwearables.io/for/sports-nutrition) How it works ## Where the data goes, step by step. Every step runs inside your deployment, in the region you chose. Nothing passes through a Momentum tenant on the way. [See the platform](https://openwearables.io/platform) 01 ### Collect Cloud providers connect server to server, and the mobile SDKs read the stores that live on the phone. Every source ends up in the same deployment, in your account. 02 ### Store Everything lands in one schema in your own database, in your chosen region, with the original payload kept underneath if you switch that on. 03 ### Compute With Pro, health scores from our science team, computed inside your deployment. 04 ### Use Your product reads it over the REST API, reacts to webhooks, or asks questions through the MCP server, all against the same deployment. More comparisons ## Compare Open Wearables with other vendors. ### [Junction](https://openwearables.io/compare/junction) ### [Sahha](https://openwearables.io/compare/sahha) ### [ROOK](https://openwearables.io/compare/rook) ### [Spike API](https://openwearables.io/compare/spike) ## Connect the devices your users already own. The coverage matrix lists what each source returns, so you can check it against the providers you need rather than against a total. New sources land in the open-source repository first, so it is always ahead of this page. [Browse integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## Deploy Open Wearables in your own cloud. The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account with the providers connected and validated on real accounts. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) FAQ ## Common questions. ### How does Terra's pricing work? A monthly subscription with an allowance of credits included, which active connections and events consume. Some capabilities are add-ons, and Enterprise is quoted. Their current plans and figures are on [Terra's pricing page](https://tryterra.co/pricing). ### How much does Terra cost? Terra publishes its plans and current figures on [its own pricing page](https://tryterra.co/pricing). The structure is a monthly subscription with an included credit allowance, and larger usage is quoted. Because the numbers change, read them there rather than from a comparison page. ### What does Open Wearables cost? Core is free and MIT licensed, and running it costs your own cloud bill, paid directly to your provider and never marked up by us. Pro adds the licensed modules, health scores and the health agent among them, priced per deployment rather than per user. Enterprise is an annual agreement with SLA support. Deployment and Integration are optional one-off services. [Pricing](https://openwearables.io/pricing) has the figures. ### Is Open Wearables really free? Yes. Core is MIT licensed, with the full source. We charge for Pro, Enterprise, the Deployment and Integration services and custom development. ### Does it support the same devices as Terra? Open Wearables connects through direct cloud APIs for Garmin, Whoop, Oura, Polar, Suunto, Withings, Strava, Ultrahuman, SensorBio, Google Health API and Fitbit, and reads on-device data from Apple Health, Google Health Connect and Samsung Health through the mobile SDKs. A source we do not cover yet is built on request, usually in two to three weeks. Every source has its page under [integrations](https://openwearables.io/integrations), and the [coverage matrix](https://openwearables.io/docs/providers/coverage) in the docs lists what each one returns. ### Is it running in production anywhere? Yes. Heart Monitor runs Open Wearables in production at around 90,000 monthly active users. They adopted the open-source project and shipped it with their own team. ### What about health scores? Health scores designed and validated by our science team, computed inside your own deployment. They are part of Pro, and custom scores are built with our science team. [The scoring layer has its own page](https://openwearables.io/platform/health-scores). ### Do you hold SOC 2 or ISO 27001? No, and Terra states a completed SOC 2 Type II audit. The deployment runs inside your certified environment, which is how most teams answer this in their own audit, but if you need the vendor itself to be certified then that is a genuine difference. ### How hard is the migration? Usually a re-integration rather than a data migration. Your historical data stays where it is, and what changes is where new data lands from the switch onwards. Most teams run both in parallel while they validate, then cut over. It starts with an architecture audit. ### Who maintains Open Wearables? Momentum, a healthcare software development company. The project is MIT licensed and developed in the open, with a public roadmap and public issues, so the source does not depend on us continuing to fund it. --- Source: https://openwearables.io/data-governance # Who controls the data, who can reach it. In writing. Data governance Most health data governance questions are settled by where the deployment runs: your cloud account, under your credentials. This page is the rest: what we can reach, and what happens when you leave. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) Data ownership ## The deployment is yours, and so is what leaves it. ### The account is yours Open Wearables runs in your cloud account under your own credentials. There is no tenant of ours holding a copy, in either operating model. ### Provider apps in your name Garmin, Oura, Whoop and the rest are registered to you, so the relationship with each provider is yours rather than sublet from us. ### Leaving changes nothing If you stop working with us, the deployment and the data stay where they are. There is no export to request and no window to act inside. ### What you build is yours Your data model, your pipeline and your own logic run on MIT-licensed open source in your account. Data processing ## You are the controller. Here is what that means for us. ### Where you run it yourself We are not in the picture: no access, no processing, nothing to agree. Your team is the only one that can reach the deployment. [How it is secured](https://openwearables.io/security) ### When we work on your system The contract sets out what we can reach, who on our side can reach it, and when: a named list rather than standing administrative access. [What we sign](https://openwearables.io/what-we-sign) ### Either way, every access is logged Access shows in your cloud account's logs, so verifying our answer does not require trusting it. When we work on your system, we act as your processor under a DPA you sign. [Sub-processors](https://openwearables.io/sub-processors) Residency ## You pick the region, once, at the start. ### A deployment decision The region is chosen when the deployment is stood up, which settles most of what a regulator or a customer will ask before they ask it. ### You can point at it Where the data sits is a fact about an account you control, so proving it means showing a console rather than citing a policy page. ### Per-country detail The specifics differ by market, and where a named instrument applies, the residency pages say which one. [Data residency](https://openwearables.io/data-residency) Data integration ## Where the data comes from, and where it goes. [Raw data](https://openwearables.io/platform/raw-data) 01 ### In, from the providers your users already use Cloud providers connect server to server. On-device sources arrive through an SDK inside your own app. Both land in your deployment, not in ours. 02 ### Kept as it arrived, if you want it The original provider payload can be written to a bucket you own before normalisation, so a question nobody anticipated can still be answered two years later. 03 ### Out, through your own API Data leaves on your schema, into your product, through an endpoint that belongs to you. There is no intermediate service holding a copy in transit. 04 ### One honest caveat about timing Webhooks fire per provider, but the path from a watch to a phone to a provider's cloud is theirs rather than ours. We mirror what they give us and minimise what we add, rather than promise real time. When the questionnaire arrives ## What a security review gets from us. Most questions on a vendor questionnaire are answered by the architecture rather than by us. This is the short version of who answers what. | | Hosted wearable API | Build it in-house | Open Wearables, self-hosted | | --- | --- | --- | --- | | [01] Where is the data stored? | On the vendor's infrastructure | In your infrastructure | Your cloud account, in the region you chose | | [02] Who has access to it? | Your team and the vendor's | Your team | You. When we work on it, a named list in the DPA | | [03] Who holds a copy of the data? | The vendor | Your team | Only you. We work in your account under a DPA you sign | | [04] What happens to the data if we leave? | An export to request | Nothing moves | Nothing moves | | [05] Can we audit it? | Through the vendor's reports | Your account, your logs | Your account, your logs | | [06] Do you hold SOC 2 or ISO 27001? | The vendor's, if it holds one | Yours | No. It runs inside your certified environment | ## Bring us your review If your security team has a questionnaire ready, send it. Most of it is answered by where the deployment runs, and the rest is a conversation worth having early rather than at signature. [Book a demo](https://openwearables.io/book) FAQ ## Common questions. ### What does health data governance mean for a self-hosted deployment? Less paperwork than for a hosted one, because several of the usual questions stop applying. Where the data sits and who the controller is are settled by the architecture rather than by policy. What remains is the part this page covers: what we can reach when we work on your system, and what happens when you stop working with us. ### Who is the controller and who is the processor? You are the controller. Where you run the deployment yourself, there is no processor, because nobody else touches it. When we work on your system, we act as your processor under a DPA you sign, with defined access rather than standing access. ### Does any health data reach Momentum? No copy of it does. The deployment runs in your account whoever works on it, so nothing is kept on our side. When we work on your system, what we can reach is defined in the DPA you sign. ### What can you actually see when you work on our deployment? What the DPA defines, and only while it applies. Because the deployment is in your account, what we did shows in your cloud account's logs rather than in a report we produce. ### Who are your sub-processors? When you run the deployment yourselves, it is in your account and we are not involved. When we support or maintain it, we act as your processor under a DPA you sign, and we name the sub-processors we use for that access. [The sub-processors page](https://openwearables.io/sub-processors) covers both. ### Do you hold SOC 2 or ISO 27001? No. The deployment runs inside your certified environment, which is how most teams answer this in their own audit. If your procurement treats a vendor certificate as mandatory regardless of architecture, say so early and we will tell you honestly whether that works. ### What happens to our data if we stop working with you? Nothing moves. The deployment is in your cloud account, under an MIT license, and where we set it up, built from infrastructure code in your repository. There is no export window because there is nothing to export from. ### Our customer asks us to name every sub-processor touching their data. What do we say? When you run the deployment yourselves, the health data stays in your account and we are not involved. When we support or maintain it, we work in your account as your processor under a DPA you sign, and we name the sub-processors we use for that access. ### We are regulated and our contracts have specific requirements. Can you meet them? That depends on the requirement, and the honest answer sometimes comes with a limit attached. Bring the clause to the conversation early. It is cheaper for both sides to find out at that point than at signature. --- Source: https://openwearables.io/data-residency # Where health data has to stay. Data residency Residency questions arrive as a clause, a questionnaire or a procurement condition, and each market has its own. Open Wearables runs in your own cloud account, in the region you pick. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) Why it runs in your cloud ## The layer has to be yours before what you build on it can be. A hosted API keeps the data, and every score computed from it, in a vendor's account. Running the layer yourself keeps it where HIPAA, GDPR and your own policy say it belongs. ### Sovereignty Your regulator, your board or your own policy says health data does not sit in a third party's cloud. ### Residency The data has to stay in a country or region you choose, and you have to prove where it is. ### Control You run the deployment under your own credentials and decide who gets access. What you build on top of Open Wearables is yours. ### Your own reasons No regulator forcing it and no security review coming. You want the data in your own account anyway. ## The short answer. ### You choose the region. The region is set when the deployment is, in your own cloud account. Not a preference we honour, a choice you make. ### The data sits in your account. Self-hosted, no copy lands in a Momentum tenant. The data stays in your account, in the region you chose. ### Provable rather than promised. You evidence residency by pointing at your own cloud account, not at a vendor's policy page or a contract clause. ### Each market works differently. A statute in one, a contract clause in another, a certified host in a third. The pages below take them one by one. ### No vendor tenant in the path. Self-hosted, the data goes from the provider or the phone straight into your own account, in the region you chose. By jurisdiction ## Pick your market. What applies, in a sentence, and a page each with the detail and the answers a reviewer asks for. ### UAE The law keeps health data in the country, and moving it abroad needs the health authority's approval. [The UAE page](https://openwearables.io/data-residency/uae) ### Singapore Public healthcare contracts can bar a vendor from processing data outside Singapore without written approval. [The Singapore page](https://openwearables.io/data-residency/singapore) ### Germany Healthcare providers and insurers may only process health data in cloud services with a C5 attestation. [The Germany page](https://openwearables.io/data-residency/germany) ### France Hosting health data for someone else needs HDS certification, and certified hosts now store it in the EEA. [The France page](https://openwearables.io/data-residency/france) ### Netherlands Care providers have to work to NEN 7510, and buyers ask their suppliers to show the same. [The Netherlands page](https://openwearables.io/data-residency/netherlands) ## When the region gets chosen. Residency is settled at deployment rather than negotiated afterwards, which is why it rarely becomes a contract argument. ### The cloud and the region You choose both, in the account you already have, wherever your cloud provider operates. ### Several markets Users in several countries may need one region or several. Which rules reach the data decides, not office locations. ### Credentials in your name Provider credentials are issued to you, so the relationship with each wearable provider is yours. ### Moving later Where we set it up, the infrastructure is code in your repository, so a region change is engineering work. The data path ## Where the data goes, step by step. Every step runs inside your deployment, in the region you chose. Nothing passes through a Momentum tenant on the way. [See the platform](https://openwearables.io/platform) 01 ### Collect Cloud providers connect server to server, and the mobile SDKs read the stores that live on the phone. Every source ends up in the same deployment, in your account. 02 ### Store Everything lands in one schema in your own database, in your chosen region, with the original payload kept underneath if you switch that on. 03 ### Compute With Pro, health scores from our science team, computed inside your deployment. 04 ### Use Your product reads it over the REST API, reacts to webhooks, or asks questions through the MCP server, all against the same deployment. ## Bring us the clause you are working against Your market is not listed, or your question is specific? Send the instrument, the customer requirement or the questionnaire wording, and you will get a straight answer about what a deployment in your own account does. [Book a call](https://openwearables.io/book) FAQ ## Common questions. ### Which regions can we deploy in? Wherever your cloud provider operates, because the deployment runs in your account rather than ours. That is the practical difference from a hosted API, where the answer is limited to the regions that vendor has chosen to open. ### Do you hold data on your side at all? Self-hosted, no. The data sits in your own cloud account, and nothing is copied to a Momentum tenant. ### Our regulator has not published anything specific. Does that help us? Less than it sounds. Nothing published is not the same as nothing required, and enterprise customers apply their own standards regardless of what a regulator has said. Some markets also restrict conditionally rather than outright, depending on how the data is classified. If no requirement reaches you and no customer review is coming, a hosted API is probably the better tool, and we would say so. ### How do we evidence residency? By pointing at your own cloud account and the region it runs in, which is a fact about infrastructure rather than a policy statement. ### We operate in several countries. Does that mean several deployments? Not necessarily. What matters is which rules reach your data, not where your offices are: a company with users in five countries may need one region, and a company in one country may need two. ### Is the region something we can change later? Yes. Moving a deployment is engineering work you schedule, not a commercial negotiation. ### Do you give legal advice? No. We name what applies, say how it works, and describe what a deployment does about it. Whether a rule applies to your product is for your counsel. --- Source: https://openwearables.io/data-residency/france # Host it where you are already certified. Data residency · France In France, hosting health data for someone else requires HDS certification. Open Wearables runs in your own certified environment, so it adds no host to certify. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) Why it runs in your cloud ## The layer has to be yours before what you build on it can be. A hosted API keeps the data, and every score computed from it, in a vendor's account. Running the layer yourself keeps it where HIPAA, GDPR and your own policy say it belongs. ### Sovereignty Your regulator, your board or your own policy says health data does not sit in a third party's cloud. ### Residency The data has to stay in a country or region you choose, and you have to prove where it is. ### Control You run the deployment under your own credentials and decide who gets access. What you build on top of Open Wearables is yours. ### Your own reasons No regulator forcing it and no security review coming. You want the data in your own account anyway. ## The short answer. ### Certification follows hosting. HDS applies to whoever hosts health data on behalf of others, from the data centre up to operating the system. ### A hosted platform is a host. If your wearable data sits on a vendor's servers, that vendor hosts it for you and needs certification of its own. ### Self-hosting adds no host. Open Wearables is software running in your certified environment, so the hosting chain stays as it already is. ### No vendor tenant in the path. Self-hosted, the data goes from the provider or the phone straight into your own account, in the region you chose. ### Storage stays in the EEA. Certified hosts now store health data in the EEA. A region you choose in France or elsewhere in the EEA keeps it there. The detail ## Three ways to build it. What each approach adds to a hosting chain that has to be certified. | | Hosted wearable API | Build it in-house | Open Wearables, self-hosted | | --- | --- | --- | --- | | [01] Who hosts the data | The vendor, on its own servers | You, on certified hosting | You, on certified hosting | | [02] Under HDS | The vendor needs its own certification | Your hosting chain, as it is | Your hosting chain, as it is | | [03] The integrations | Written by the vendor | Yours to write and maintain | Already written, MIT licensed | | [04] What it takes | A second certified host to check | Integration work and ongoing maintenance | A deployment in your own account | ## How it works in practice. The hosting question is settled when the deployment is set up, not negotiated afterwards. ### The certified host AWS, Azure and Google Cloud all hold HDS and run French regions, and several French providers hold it too. ### Credentials in your name Provider credentials are issued to you, so the relationship with each wearable provider is yours. ### Moving later Where we set it up, the infrastructure is code in your repository, so a region change is engineering work. ### Inside the EEA Pick a region in the EEA and the deployment, its database and its backups stay there with it. The data path ## Where the data goes, step by step. Every step runs inside your deployment, in the region you chose. Nothing passes through a Momentum tenant on the way. [See the platform](https://openwearables.io/platform) 01 ### Collect Cloud providers connect server to server, and the mobile SDKs read the stores that live on the phone. Every source ends up in the same deployment, in your account. 02 ### Store Everything lands in one schema in your own database, in your French region, with the original payload kept underneath if you switch that on. 03 ### Compute With Pro, health scores from our science team, computed inside your deployment. 04 ### Use Your product reads it over the REST API, reacts to webhooks, or asks questions through the MCP server, all against the same deployment. ## Tell us what you are building We will tell you what it takes to run it on certified French hosting. [Book a call](https://openwearables.io/book) FAQ ## Common questions. ### Are you HDS certified? No. HDS certifies hosts, and Open Wearables is software you run. Self-hosted, the certification in question is your hosting chain's, not ours. ### Do we need HDS ourselves? If you host or operate health data on behalf of healthcare organisations, likely yes, for the activities you perform. Your counsel and your certifier will tell you which. Open Wearables adds none of its own. ### So we do not need a certified wearable vendor? You need certified hosting for the activities in your chain. What you avoid is a wearable vendor hosting the data for you, which would need a certificate of its own. ### Does the data have to stay in France? In the EEA. Since late September 2026, certified hosts store health data inside the EEA, so a French region, or another one in the EEA, meets it. ### Which hosts hold the certification? AWS, Azure and Google Cloud do, and so do several French providers. Your buyer may have a preference, which is worth asking before you choose. ### Does this apply to us if we are not a healthcare provider? It follows the hosting, not the type of company: it covers health data collected in care, prevention or diagnosis and hosted for someone else. Whether that describes you is for your counsel. ### Our customer asks who hosts their patients' data. What do we say? You do, on certified infrastructure you chose. That is usually a shorter answer than naming a wearable vendor and explaining its certification alongside your own. ### Do you give legal advice? No. We tell you what the architecture does. Whether a requirement reaches your product is for your counsel. --- Source: https://openwearables.io/data-residency/germany # The attestation belongs to your host. Data residency · Germany Healthcare providers and insurers in Germany may only process health data in cloud services with a C5 attestation. Run Open Wearables in your own cloud account, and that attestation is your host's. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) Why it runs in your cloud ## The layer has to be yours before what you build on it can be. A hosted API keeps the data, and every score computed from it, in a vendor's account. Running the layer yourself keeps it where HIPAA, GDPR and your own policy say it belongs. ### Sovereignty Your regulator, your board or your own policy says health data does not sit in a third party's cloud. ### Residency The data has to stay in a country or region you choose, and you have to prove where it is. ### Control You run the deployment under your own credentials and decide who gets access. What you build on top of Open Wearables is yours. ### Your own reasons No regulator forcing it and no security review coming. You want the data in your own account anyway. ## The short answer. ### The rule sits on the cloud layer. Healthcare providers and insurers may only process health data in cloud services that hold a current C5 attestation. ### A hosted API is another cloud service. If a vendor processes the data on its own infrastructure, that service needs an attestation of its own, and a review. ### Self-hosting keeps it to one layer. Open Wearables runs in your own cloud account, so the attestation question lands on the provider you already document. ### No vendor tenant in the path. Self-hosted, the data goes from the provider or the phone straight into your own account, in the region you chose. ### Your host, your choice. A hyperscaler's German region, a domestic provider or your own servers. The deployment goes where you already host. The detail ## Three ways to build it. What your buyer reviews under each approach, when health data may only sit in attested cloud services. | | Hosted wearable API | Build it in-house | Open Wearables, self-hosted | | --- | --- | --- | --- | | [01] Attestations in the review | Your host's and the vendor's | Your host's | Your host's | | [02] What your buyer reviews | Two hosting postures, one you do not control | Your hosting only | Your hosting only | | [03] The integrations | Written by the vendor | Yours to write and maintain | Already written, MIT licensed | | [04] What it takes | A second supplier to defend | Integration work and ongoing maintenance | A deployment in your own account | ## How it works in practice. The hosting question is settled when the deployment is set up, not negotiated afterwards. ### The host and the region AWS, Azure and Google Cloud all run regions in Germany. Prefer a domestic provider? Say so early, it shapes the setup. ### Inside the attested scope An attestation lists the services and regions it covers, so the deployment uses the ones inside your provider's scope. ### Credentials in your name Provider credentials are issued to you, so the relationship with each wearable provider is yours. ### Moving later Where we set it up, the infrastructure is code in your repository, so a region change is engineering work. The data path ## Where the data goes, step by step. Every step runs inside your deployment, in the region you chose. Nothing passes through a Momentum tenant on the way. [See the platform](https://openwearables.io/platform) 01 ### Collect Cloud providers connect server to server, and the mobile SDKs read the stores that live on the phone. Every source ends up in the same deployment, in your account. 02 ### Store Everything lands in one schema in your own database, in your German region, with the original payload kept underneath if you switch that on. 03 ### Compute With Pro, health scores from our science team, computed inside your deployment. 04 ### Use Your product reads it over the REST API, reacts to webhooks, or asks questions through the MCP server, all against the same deployment. ## Tell us what you are building We will tell you what it takes to run it on German infrastructure. [Book a call](https://openwearables.io/book) FAQ ## Common questions. ### Do you hold a C5 attestation? No. C5 attests cloud services, so self-hosted it is your host's to hold. AWS, Azure and Google Cloud all publish one, and we run inside whichever you choose. ### Is a C5 attestation mandatory? For healthcare providers and insurers, and the processors working for them, using cloud services for health data: yes, a current C5 Type 2 attestation since July 2025, with a shorter Type 1 window for new systems. Whether that reaches your product is for your counsel. ### Our buyer asks which cloud providers we use. What do we say? The ones you chose, because the deployment is in your account. That is usually a shorter answer than naming a wearable vendor and explaining their infrastructure alongside your own. ### Can we deploy on a German provider rather than a hyperscaler? Open Wearables runs as standard containers with PostgreSQL and Redis, so a provider that runs those can host it. Tell us which one on the first call, because it shapes the setup work. ### We are building a DiGA. Does this help? It addresses the data layer, not the approval. Where your data comes from, where it sits and who can reach it are questions a DiGA submission raises, and self-hosting gives you a simpler answer to all three. It does not shorten the certification itself. ### Does this apply to us if we are not selling into statutory healthcare? Less directly, but enterprise buyers may apply the same standard. If a security review is coming, it is worth answering before it arrives. ### Do you give legal advice? No. We tell you what the architecture does. Whether a requirement reaches your product is for your counsel. --- Source: https://openwearables.io/data-residency/netherlands # Your standard, applied to your own deployment. Data residency · Netherlands Dutch care providers have to work to NEN 7510, and buyers expect their suppliers to show it too. Open Wearables runs inside your own environment, under your controls. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) Why it runs in your cloud ## The layer has to be yours before what you build on it can be. A hosted API keeps the data, and every score computed from it, in a vendor's account. Running the layer yourself keeps it where HIPAA, GDPR and your own policy say it belongs. ### Sovereignty Your regulator, your board or your own policy says health data does not sit in a third party's cloud. ### Residency The data has to stay in a country or region you choose, and you have to prove where it is. ### Control You run the deployment under your own credentials and decide who gets access. What you build on top of Open Wearables is yours. ### Your own reasons No regulator forcing it and no security review coming. You want the data in your own account anyway. ## The short answer. ### Required for care providers. Rules on electronic processing require care providers to work to NEN 7510. Certification is optional, but buyers ask. ### It reaches suppliers. Care organisations show the standard reaches their supply chain, which is where a hosted API becomes a separate review. ### Self-hosting keeps one perimeter. Open Wearables runs in your own environment, under the network rules, logging and policies you already have in place. ### No vendor tenant in the path. Self-hosted, the data goes from the provider or the phone straight into your own account, in the region you chose. ### Where it sits is yours. Dutch hosting, another EU region or your own servers. The standard is about controls, and you choose the location. The detail ## Three ways to build it. What your buyer assesses under each approach, when the standard has to reach your suppliers. | | Hosted wearable API | Build it in-house | Open Wearables, self-hosted | | --- | --- | --- | --- | | [01] What your buyer assesses | Your controls and the vendor's | Your controls | Your controls | | [02] Assessments to run | Two, one of which you do not run | One | One | | [03] The integrations | Written by the vendor | Yours to write and maintain | Already written, MIT licensed | | [04] What it takes | A supplier to assess | Integration work and ongoing maintenance | A deployment in your own account | ## How it works in practice. The question is settled when the deployment is set up, not negotiated afterwards. ### Your environment Network rules, infrastructure logging and backups are the ones your environment already runs, not a second set. ### The host and the region Azure and Google Cloud both run regions in the Netherlands, and EU regions or your own servers work too. ### Credentials in your name Provider credentials are issued to you, so the relationship with each wearable provider is yours. ### Moving later Where we set it up, the infrastructure is code in your repository, so a region change is engineering work. The data path ## Where the data goes, step by step. Every step runs inside your deployment, in the region you chose. Nothing passes through a Momentum tenant on the way. [See the platform](https://openwearables.io/platform) 01 ### Collect Cloud providers connect server to server, and the mobile SDKs read the stores that live on the phone. Every source ends up in the same deployment, in your account. 02 ### Store Everything lands in one schema in your own database, in your Dutch region, with the original payload kept underneath if you switch that on. 03 ### Compute With Pro, health scores from our science team, computed inside your deployment. 04 ### Use Your product reads it over the REST API, reacts to webhooks, or asks questions through the MCP server, all against the same deployment. ## Tell us what you are building We will tell you what it takes to run it inside your own environment. [Book a call](https://openwearables.io/book) FAQ ## Common questions. ### Is NEN 7510 legally required? For care providers, working to it is: the rules on electronic data processing in care point to NEN 7510 and two related standards. Certification is not required by law, but insurers and enterprise buyers often ask for it. ### Are you certified to it? No. The standard applies to the organisation handling health data. Self-hosted, our software runs inside your environment and under your controls, rather than beside them. ### Our customer asks whether our suppliers meet the standard. What do we say? That the wearable data layer runs inside your own environment rather than a supplier's, so it falls under the controls you already documented. That is usually a shorter answer than assessing a vendor. ### Does the data have to stay in the Netherlands? The standard is about security controls rather than location, and EU hosting is common. Where your contracts or customers require Dutch hosting, choose a Dutch region, and the deployment goes there. ### How is this different from ISO 27001? NEN 7510 builds on ISO 27001 with healthcare-specific requirements. The deployment sits inside whichever of the two you run. ### Do you give legal advice? No. We tell you what the architecture does. Whether a requirement reaches your product is for your counsel. --- Source: https://openwearables.io/data-residency/singapore # When the contract bars offshore processing. Data residency · Singapore Some public healthcare contracts in Singapore can bar a vendor from processing data abroad. Open Wearables runs in your own account, in a Singapore region, so nothing is processed abroad. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) Why it runs in your cloud ## The layer has to be yours before what you build on it can be. A hosted API keeps the data, and every score computed from it, in a vendor's account. Running the layer yourself keeps it where HIPAA, GDPR and your own policy say it belongs. ### Sovereignty Your regulator, your board or your own policy says health data does not sit in a third party's cloud. ### Residency The data has to stay in a country or region you choose, and you have to prove where it is. ### Control You run the deployment under your own credentials and decide who gets access. What you build on top of Open Wearables is yours. ### Your own reasons No regulator forcing it and no security review coming. You want the data in your own account anyway. ## The short answer. ### Contractual, not statutory. The bar comes from public health sector agreements, which require written approval before a vendor processes data abroad. ### It binds the vendor. The clause is about who processes the data, so the fix is taking the vendor out of the data path, not moving the data. ### Self-hosting removes the question. Open Wearables runs in your own cloud account, in a Singapore region. Nothing is processed outside Singapore, so there is nothing to approve. ### No vendor tenant in the path. Self-hosted, the data goes from the provider or the phone straight into your own account, in the region you chose. ### Provable rather than promised. You evidence residency by pointing at your own cloud account, not at a vendor's policy page or a contract clause. The detail ## Three ways to build it. What each approach looks like under a clause that bars a vendor from processing data abroad. | | Hosted wearable API | Build it in-house | Open Wearables, self-hosted | | --- | --- | --- | --- | | [01] Who processes the data | The vendor, wherever its servers are | You | You, in your own account | | [02] Under the clause | Approval needed wherever the vendor processes outside Singapore | Works | Works | | [03] The integrations | Written by the vendor | Yours to write and maintain | Already written, MIT licensed | | [04] What it takes | An approval step, if its servers are abroad | Integration work and ongoing maintenance | A deployment in your own account | ## How it works in practice. Residency is settled when the deployment is set up, not negotiated afterwards. ### The cloud and the region You choose both, in the account you already have. AWS, Azure and Google Cloud all run Singapore regions. ### Credentials in your name Provider credentials are issued to you, so the relationship with each wearable provider is yours. ### In writing When we set up the deployment for you, the cloud account and the region it runs in are stated in writing. ### Moving later Where we set it up, the infrastructure is code in your repository, so a region change is engineering work. The data path ## Where the data goes, step by step. Every step runs inside your deployment, in the region you chose. Nothing passes through a Momentum tenant on the way. [See the platform](https://openwearables.io/platform) 01 ### Collect Cloud providers connect server to server, and the mobile SDKs read the stores that live on the phone. Every source ends up in the same deployment, in your account. 02 ### Store Everything lands in one schema in your own database, in your Singapore region, with the original payload kept underneath if you switch that on. 03 ### Compute With Pro, health scores from our science team, computed inside your deployment. 04 ### Use Your product reads it over the REST API, reacts to webhooks, or asks questions through the MCP server, all against the same deployment. ## Tell us what you are building We will tell you what it takes to run it in a Singapore region. [Book a call](https://openwearables.io/book) FAQ ## Common questions. ### Does this clause apply to us? It appears in public health sector agreements in Singapore. If you sell into that side of the market, your own contract will say. If you do not, your customers may still ask for the same standard. ### Could we just ask for written approval? You could. It adds an approval step to your timeline and a dependency you do not control. Taking the vendor out of the data path avoids the question rather than answering it. ### Is there a law that keeps health data in Singapore? The bar on this page is contractual. Singapore's general data protection law allows transfers abroad under conditions, and health-specific legislation is changing, so what applies to you is a question for your counsel. ### Which Singapore regions can we deploy in? AWS, Azure and Google Cloud all run regions in Singapore, so whichever you use. The deployment goes into your account rather than ours. ### We also sell into the UK. Is that a different answer? Often a similar one. NHS-facing buyers usually ask who can reach the data, and the answer is the same: it runs in your cloud account, under your credentials, and when we work on your system, we do it under a DPA you sign. [More for health data platforms](https://openwearables.io/for/health-data-platforms). ### Do you give legal advice? No. We tell you what the architecture does. Whether a clause reaches your contract is for your counsel. --- Source: https://openwearables.io/data-residency/uae # Health data has to stay in the country. Data residency · UAE UAE law keeps health data inside the country. Open Wearables runs in your own cloud account, in a UAE region, so the data never leaves. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) Why it runs in your cloud ## The layer has to be yours before what you build on it can be. A hosted API keeps the data, and every score computed from it, in a vendor's account. Running the layer yourself keeps it where HIPAA, GDPR and your own policy say it belongs. ### Sovereignty Your regulator, your board or your own policy says health data does not sit in a third party's cloud. ### Residency The data has to stay in a country or region you choose, and you have to prove where it is. ### Control You run the deployment under your own credentials and decide who gets access. What you build on top of Open Wearables is yours. ### Your own reasons No regulator forcing it and no security review coming. You want the data in your own account anyway. ## The short answer. ### The rule is statutory. UAE law requires health data to stay in the country. Moving it abroad needs an exception from the health authority. ### A problem for hosted platforms. If a vendor processes the data on servers outside the country, the problem is structural and no contract term fixes it. ### Self-hosting answers it directly. Open Wearables runs in your own cloud account, in a UAE region. The data goes from the provider into it and stays. ### No vendor tenant in the path. Self-hosted, the data goes from the provider or the phone straight into your own account, in the region you chose. ### Provable rather than promised. You evidence residency by pointing at your own cloud account, not at a vendor's policy page or a contract clause. The detail ## Three ways to build it. What each approach looks like under a rule that keeps health data in the country. | | Hosted wearable API | Build it in-house | Open Wearables, self-hosted | | --- | --- | --- | --- | | [01] Where the data is processed | On the vendor's servers, usually outside the UAE | In your own infrastructure | In your own account, in a UAE region | | [02] Under the rule | A structural problem, not a configuration one | Works | Works | | [03] The integrations | Written by the vendor | Yours to write and maintain | Already written, MIT licensed | | [04] What it takes | A transfer to justify | Integration work and ongoing maintenance | A deployment in your own account | ## How it works in practice. Residency is settled when the deployment is set up, not negotiated afterwards. ### The cloud and the region You choose both, in the account you already have. AWS and Azure both operate regions inside the UAE. ### Credentials in your name Provider credentials are issued to you, so the relationship with each wearable provider is yours. ### In writing When we set up the deployment for you, the cloud account and the region it runs in are stated in writing. ### Moving later Where we set it up, the infrastructure is code in your repository, so a region change is engineering work. ### Free zones DIFC, ADGM and Dubai Healthcare City run their own data regimes, and the federal rules may apply too. Counsel decides. The data path ## Where the data goes, step by step. Every step runs inside your deployment, in the region you chose. Nothing passes through a Momentum tenant on the way. [See the platform](https://openwearables.io/platform) 01 ### Collect Cloud providers connect server to server, and the mobile SDKs read the stores that live on the phone. Every source ends up in the same deployment, in your account. 02 ### Store Everything lands in one schema in your own database, in your UAE region, with the original payload kept underneath if you switch that on. 03 ### Compute With Pro, health scores from our science team, computed inside your deployment. 04 ### Use Your product reads it over the REST API, reacts to webhooks, or asks questions through the MCP server, all against the same deployment. ## Tell us what you are building We will tell you what it takes to run it inside the country. [Book a call](https://openwearables.io/book) FAQ ## Common questions. ### Does this apply to wearable data? The law covers health data related to health services provided in the country, and wearable data collected by a health product often sits inside that. Whether it reaches your particular case is for your counsel. What we can tell you is what the architecture does either way. ### Our company is in a free zone. Does the federal rule reach us? Possibly both apply, and they are not identical. A deployment in a UAE region keeps the data in the country under the federal rule; whether a free zone adds conditions of its own is a question for your counsel. ### Which UAE regions can we deploy in? AWS runs one and Azure runs two. Google Cloud has none inside the UAE today. If your cloud provider has no UAE region, raise it early, because that changes the shape of the answer rather than the configuration. ### Can we keep a copy outside the country for analytics? Only where the health authority has decided an exception applies, so settle it before you build. The deployment itself does not need a second copy anywhere. ### Do you give legal advice? No. We tell you what the architecture does. Whether a rule applies to your product is for your counsel. --- Source: https://openwearables.io/enterprise # An open platform, with a healthcare company behind it. Enterprise The platform is open source, so the deployment stays yours whatever happens between us. Momentum stands it up, keeps it running against provider drift, and handles the paperwork your review will send. [Talk to us](https://openwearables.io/book?tier=enterprise) [See pricing](https://openwearables.io/pricing) Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo What your review will ask ## Three questions, and where each one is answered. ### What does this cost, and what is in it? The platform is free and self-hosted. What is priced is standing it up, wiring it into your product, and keeping it alive against provider drift. [Pricing](https://openwearables.io/pricing) ### Will it pass our security review? Most of it is settled by where the deployment runs, your own cloud account. The rest is written down: what we can reach, what we sign, and what we do not claim. [Security](https://openwearables.io/security) ### Who is behind this, and will they be here? The software is MIT licensed and public, so the worst case is that you keep running it. The people are below. [Who stands behind it](https://openwearables.io/enterprise#who-stands-behind-it) Who stands behind it ## Built and operated by a healthcare software company. Momentum has been building health data software since 2016. Open Wearables came out of writing the same integrations again and again for clients who needed to own the result, and the team that deploys it maintains it. ### ISO 13485 Momentum holds the quality management standard for medical device software. The certificate is the company's; the software's own position is on the security page. ### Healthcare only HIPAA and GDPR compliant delivery, HL7 FHIR, EHR integration and clinical software. The people who answer your questionnaire have answered one before. ### Delivery history Over 220 projects delivered since 2016, and a 4.9 out of 5 rating on Clutch from the clients behind them. ### Production scale Heart Monitor runs Open Wearables at around 90,000 monthly active users, on a deployment their own team stands up and operates. Check it yourself ## Evidence you can read before you sign. A small vendor is a fair worry. These answer it without anyone on our side in the room. ### The public repository All of the code, MIT licensed, readable before any contract. [GitHub](https://github.com/the-momentum/open-wearables) ### Release history Every release published with its changes, so the pace of work is visible. [Releases](https://github.com/the-momentum/open-wearables/releases) ### Documentation Architecture, API, deployment and providers, written down in public. [Docs](https://openwearables.io/docs) ### Public roadmap What is being built next, kept current by the product team. [Roadmap](https://openwearables.io/docs/roadmap) ### An open community Questions and issues in the open, on Discord and on GitHub. [Discord](https://discord.gg/qrcfFnNE6H) ## Ways to work with us Every engagement starts from the same platform in your own account. Prices and scopes are on the pricing page. [01] Teams who need it live in their cloud ### Deployment The platform live in your own cloud, connected to the providers, handed over to your team. - Production and staging in your cloud, in your region - Provider onboarding, credentials in your name - Infrastructure as code in your repository - 30 days of support and a team walkthrough [See pricing](https://openwearables.io/pricing) [02] Teams who need it inside their product ### Integration Your users connecting their own devices from inside your app, the data landing in your schema. - Connection and consent flow built into your app - Your existing login, no second account - One cloud source to your schema, tested end to end - 30 days of post-launch support, with a Slack channel [See pricing](https://openwearables.io/pricing) [03] With an Enterprise agreement ### Maintenance Someone on the hook when a provider breaks something, and the paperwork handled. - Technical SLA and a named on-call - Provider drift handled, upgrades tested in staging first - Signed DPA, BAA where supported - Security questionnaires and reviews, handled by us [See pricing](https://openwearables.io/pricing) [04] Teams building something specific ### Custom development The work that turns the data into a product feature, or into a product. - A health product built end to end - AI features and coaching logic - Migration off a hosted aggregator - Study design and validation, with our health science team [See pricing](https://openwearables.io/pricing) What happens next ## How this actually runs. [Pricing](https://openwearables.io/pricing) 01 ### Someone stands it up in your account Production and staging, in the region you choose, with provider credentials registered in your name and the infrastructure code left in your repository. Multi-region where you need it. 02 ### Someone is accountable when a provider changes An ongoing engagement means a technical SLA with a named person on call, upgrades tested in staging before they reach production, and a monthly report on integration health. 03 ### The paperwork is handled Processing agreements, signed BAAs where your cloud supports one, security questionnaires answered by us, and a security operations review on your governance's cadence. 04 ### Coverage can follow your organisation Support beyond European business hours is part of what an ongoing engagement can include. 05 ### You can end it without losing anything The deployment is in your account, built from code in your repository, under a licence nobody can revoke. That makes the relationship a choice rather than a dependency. ## Tell us what you are building We will tell you what it takes to run it in your own cloud, and what Deployment, Integration and an Enterprise agreement would cost. [Talk to us](https://openwearables.io/book?tier=enterprise) [See pricing](https://openwearables.io/pricing) FAQ ## Common questions. ### What happens to our deployment if we stop working with you? Nothing. It sits in your cloud account, built from infrastructure code in your repository, under an MIT licence nobody can revoke. Your team can maintain it, hand it to someone else, or leave it as it is. ### Do you hold SOC 2 or ISO 27001? No. The deployment runs inside your certified environment, which is how most teams answer this in their own audit. Momentum holds ISO 13485, a different standard, for medical device software. [The security page](https://openwearables.io/security) has the rest. ### Our procurement needs a single vendor for the whole thing. Does that work? Usually yes. Momentum can be the contracting party for the deployment, the maintenance and the development work, so your side sees one agreement rather than three. The software still runs in your account. ### We need a specific region, or a specific cloud. Is that a problem? It is a question rather than a problem. You pick the region when the deployment is set up, and multi-region is part of what a deployment can cover. Tell us the constraint early, because it shapes the estimate. ### Can we start smaller and expand later? That is the common path. Teams start with a deployment, run it themselves for a while, and move to Enterprise for maintenance when the first provider change costs them a week. Nothing about the earlier decision has to be undone. ### How long does a deployment take? It depends on how many sources you need and what has to be wired into your product, so the honest answer comes out of scoping. [The pricing page](https://openwearables.io/pricing) has what each engagement covers. ### Who actually does the work? The team that builds the platform. Not a partner network, not a reseller, and not an account manager who relays questions to engineering. ### We already run Open Wearables ourselves. Can you take it over? Yes, and that is a normal starting point. An existing deployment usually needs a review before we can be accountable for it, which is a short piece of work rather than a rebuild. ### What do you sign? A data processing agreement for the work we do on your deployment, and a BAA where HIPAA applies and your setup supports it. [What we sign](https://openwearables.io/what-we-sign) sets it out. --- Source: https://openwearables.io/faq # Questions we get on most calls. FAQ Written from the last hundred or so conversations rather than from what we imagine people want to know. [Get started](https://openwearables.io/docs/quickstart) [See platform](https://openwearables.io/platform) 01 ## Provider Access & API Keys ### Do we need our own developer account with each provider? Yes. The app is registered in your name, so the terms are between you and the provider directly. That is more work at the start than routing through somebody else's account, and it means the relationship is yours to keep. ### Garmin is not accepting new developer applications. What are our options? That is the hardest constraint in this space right now and it applies to everyone, including the hosted aggregators who onboarded before the door closed. If Garmin is essential to your product, raise it on the first call. There are approaches that sometimes work, and there are cases where the honest answer is that we cannot unblock it for you. ### How hard is Whoop access to get? Harder for consumer fitness and wellness, more straightforward for regulated healthcare use cases. It depends on what you are building and how you describe it in the application. ### Can you help us get provider access? We can help you prepare the application and tell you what has worked, because we have been through it many times. We cannot grant access, and any vendor telling you they can is either reselling their own account or overpromising. ### Which providers can we start with today, without waiting for approval? Apple Health and Health Connect are on-device sources accessed through your mobile app and user permissions. Samsung Health requires approval for a production release. Cloud providers have their own developer account and approval requirements; check the integration page for each source before planning your launch. ### How long does provider approval usually take? From days to months, depending on the provider and on what you are building. It is the part of a launch timeline that teams most often forget to plan for, which is why it belongs in the first conversation rather than the fourth. 02 ## Getting Started ### What is Open Wearables and what can I build with it? An open-source data layer for wearable and health data. It connects to the devices your users already own, normalises what comes back into one schema, and runs inside your own cloud account rather than ours. Teams build health products on it: coaching apps, remote monitoring, research platforms, employer wellness. ### How long does it take to get started? Minutes to a running instance locally. Clone the repository, run Docker Compose, and generate sample data so you can query the API before connecting a single real device. Getting real provider data flowing takes longer, and the variable is provider approval rather than our setup. ### Is this a SaaS platform or do I host it myself? You host it, in your own cloud account. There is no hosted version, and that is the design rather than a gap. The reason teams choose this is precisely that the data never reaches a vendor tenant. ### Can Open Wearables be used in a production app at scale? Yes. It runs in production at consumer app scale today, on standard infrastructure that your team can scale the way they scale anything else. The live versus roadmap page is specific about what works and what does not. ### Is there a testing environment so I can try it before connecting real devices? Yes. A sample data generator is built in, so your team can evaluate the API and the schema without waiting on a provider application or owning a device. ### We already have integrations built. What would we gain? Usually four things. The providers you have not built yet. One schema instead of per-provider mapping you maintain. The maintenance burden moving off your team when a provider changes something. And what you are losing today by pulling through Apple Health rather than direct, which surprises most teams: Garmin does not write heart rate variability, VO2 max or blood oxygen into Apple Health at all. 03 ## Supported Devices & SDKs ### I need the Apple Health API, Garmin API, Whoop API and Oura API for my app. Are those all supported? All four, alongside the other major platforms. The integrations pages list what is connected and the coverage matrix in the product shows what each one actually returns, which is the part that varies. For the cloud providers you will need your own developer account with each, and Garmin is currently the hard one. ### Which mobile SDKs are available? Native Swift for iOS and native Kotlin for Android, with Flutter and React Native wrapping the same cores. They exist because Apple Health, Health Connect and Samsung Health have no cloud API, so the only way to reach them is from inside an app the user has installed. ### How does the Apple Health integration work? Through HealthKit, on the device, inside your own app. There is no cloud API to call and no developer application to submit, which makes it the fastest source to get working. What arrives depends on what the user has granted and what other apps have written into Apple Health. → [Mobile SDKs](https://openwearables.io/platform/mobile-sdks) · [Apple Health](https://openwearables.io/integrations/apple-health) · Without an app of your own: [Connect App](https://openwearables.io/platform/connect-app) ### I want Oura data directly from Oura's API, not through Apple Health. Does that work? Yes, and it is usually the better choice. Going direct gets you what the provider actually has rather than the subset they choose to write into Apple Health. It needs your own Oura developer account. ### We're building a CGM integration. When is Dexcom support coming? Not in the open-source project today. Continuous glucose is on the roadmap rather than in the product, and a specific device integration is usually custom work. Ask about your device, because the answer varies by manufacturer. ### Can I add a custom provider? Yes. The codebase has a contribution guide, and adding a provider is typically one to two weeks of work. You can build it, contribute it back if you want to, or have it scoped as custom development. ### Can Open Wearables push data back to wearables, like creating training plans on Garmin? No. This is read-only. It pulls from providers and does not write back to them. ### We need Strava data in our health app. How does the integration work? Through Strava's API with OAuth, covering activities and the data attached to them. It needs your own Strava developer account, and worth knowing early: Strava's terms are specific about what you may do with the data, including restrictions around AI training. ### We're building AI coaching on Strava activity data. Can Open Wearables handle that? The data side yes, normalised into the same schema as everything else and queryable through the MCP server. The terms side is worth checking directly with Strava, because their policy on downstream use is stricter than most. ### We're integrating Google Health Connect on Android. How does it work? Through the Android SDK inside your own app, the same way Apple Health works on iOS. No developer application, no cloud API, and it covers whatever other apps on the phone have written into Health Connect. Without an app of your own, the [Connect App](https://openwearables.io/platform/connect-app) reads it for you. ### We were using Google Fit. Does this support the migration to Health Connect? Yes. Health Connect is the supported path on Android now that Google Fit APIs are retired. ### We need Samsung Health data. How do we access it? Through the Open Wearables Android SDK, which reads Samsung Health and Health Connect as separate sources. Samsung Health has no cloud API, so the SDK runs inside your app. Samsung approval is required for a production release. ### Does Open Wearables support the Samsung Health API on Android? Yes. The Android SDK reads Samsung Health directly through Samsung's Health Data SDK, alongside its separate Health Connect integration. Your production app needs Samsung approval. ### We need Polar data for our training platform. Is it supported? Yes, through Polar's API. Activities, sleep and training load, with your own Polar developer account. ### Does it support Polar training load and heart rate data? Yes, including nightly recharge. The coverage matrix lists exactly which fields arrive. ### We need Suunto data for our endurance sports app. Is it supported? Yes, through Suunto's API, with your own developer account. ### Does it support Suunto workout and GPS data? Yes, including heart rate and route data where the device recorded it. ### What exactly do we get from each provider? It varies more than most teams expect, and supported does not mean every metric is available. The coverage matrix is published in the product rather than described on a call, so you can check before you commit. If a specific metric decides your product, check it there first. ### What do we lose by pulling everything through Apple Health instead of going direct? More than it looks. Providers choose what they write into Apple Health, and several hold back their most valuable metrics. Garmin does not write heart rate variability, VO2 max or blood oxygen there at all. If those matter, you need the direct integration and the developer account that comes with it. → [Browse integrations](https://openwearables.io/integrations) ### Do we get raw signal data, like PPG or ECG waveforms? Usually not. Most providers expose processed metrics rather than raw waveforms through their APIs, and that limit is theirs rather than ours. Some SDKs are more open than others. If raw signal is essential to your product, bring it up early because the answer is provider by provider. ### Do you support blood pressure cuffs, scales or CGM? Some of this arrives through the phone if the device writes into Apple Health or Health Connect. Direct integrations with medical devices are custom work rather than part of the open-source project. Ask about the specific device, because the answer is not uniform. 04 ## Technical ### What stack does Open Wearables run on? Python and FastAPI on the backend, PostgreSQL as the primary database, Redis for queueing and caching, Celery for background work, React on the front end. It deploys with Docker Compose to start and infrastructure as code for production. The docs have the detail. ### I already have a Claude API and RAG system. Can Open Wearables feed wearable data into it? Yes, two ways. Query the API directly, or point the MCP server at your deployment so an assistant can look things up in plain language without you writing the retrieval layer. → [MCP server](https://openwearables.io/platform/mcp-server) ### We need wearable data flowing into our EHR. Does this integrate with FHIR? Not natively today. Open Wearables keeps wearable data in its own standard schema, with the raw provider payloads underneath. It is not a FHIR server, and EHR-ready FHIR output is on the roadmap. In a hospital or telemedicine rollout, we map the readings to FHIR resources (Observation, Device, Provenance and Consent) and write them into your record as part of the rollout. Otherwise the mapping is work your team does against a stable schema. ### We want to trigger actions when new data arrives. Does this support webhooks? Yes, in both directions. Incoming webhooks receive provider pushes, and outgoing webhooks notify your systems with full delivery history: every attempt, response code and payload, so a failed delivery is something you can inspect rather than guess at. → [Webhooks](https://openwearables.io/webhooks) · [Wearable API](https://openwearables.io/platform/wearable-api) ### I need live heart rate during sessions. Can this stream real-time from Garmin or Whoop over Bluetooth? No. Data arrives from provider cloud APIs, through webhooks or scheduled pulls. There is no direct Bluetooth connection to devices. Where a provider pushes webhooks the delay is usually seconds, but that is not the same as a live stream from a sensor. ### Providers return data in different formats. How does cross-device normalisation work? Everything maps into one schema, so a night of sleep from one provider is queried the same way as a night from another. What each provider actually returns differs, and the coverage matrix shows that rather than hiding it behind a unified label. ### Our users wear both an Apple Watch and a Garmin. How does deduplication work? There are configurable priority rules. You decide which source wins for which metric, rather than getting whichever arrived last. This matters more than teams expect, because two devices rarely agree on step counts. ### We're a web-only app. Do we need to build a mobile app just for Apple Health? For Apple Health, Samsung Health and Health Connect, yes. Those sources live on the phone and have no cloud API, so reaching them means an app the user has installed. Cloud providers like Garmin, Oura and Whoop need no app at all, so a web-only product can start there. ### If we customise it, can we still take updates? Yes, with the usual caveat that the further you diverge from the core, the more work each update becomes. Teams that keep their changes in clearly separated modules have an easier time than teams that edit the core directly. Worth deciding before the first customisation rather than after the third. ### Can we run a pilot with real users without touching our production app? Yes, and it is a common pattern. Teams stand up a deployment alongside their existing setup, connect a small group of users, and validate the data before committing engineering time to the integration. ### Who maintains the integrations when a provider changes their API? If you self-host, you do. If you have an Enterprise agreement, we do, and that is most of what it is for. Provider drift is not an occasional event, it is a steady background cost that teams consistently underestimate. ### How fast does data arrive? Where a provider pushes webhooks, the delay from event to your database is usually seconds rather than minutes. Sleep and recovery metrics take longer because the provider computes them first, which is their timing rather than ours. We mirror what they give us and do not promise real time. ### Is there a dashboard? There is an admin panel for your team: user connections, sync status, provider credentials, API keys. It is built for developers and operators rather than for your end users. A user-facing dashboard is something you build or something we build with you. ### What happens if we stop working with you? Nothing moves. The deployment is in your cloud account, built from infrastructure code in your repository, under a licence nobody can revoke. 05 ## Data & Privacy ### Where is user health data stored? In your own cloud account, in the region you chose when the deployment was set up. Data goes from the provider or the phone into your deployment and out through your own API. There is no copy on our side in either operating model, which is the difference between this and a hosted platform. ### We serve US patients. Is this HIPAA compliant? The deployment runs on your infrastructure, so access, encryption, retention and logging are yours to control and evidence. The software itself is not certified. A BAA depends on your cloud provider and scope, so bring those requirements to the first conversation. → [Security](https://openwearables.io/security) · [What we sign](https://openwearables.io/what-we-sign) · [Live versus roadmap](https://openwearables.io/live-vs-roadmap) ### We are a Canadian clinic. What about PIPEDA and data residency? Residency is settled by where the deployment runs, which is a region you choose rather than a region we assign. The same applies to GDPR in Europe, KVKK in Turkey, POPIA in South Africa and in-country hosting requirements across the Gulf. → [Data residency](https://openwearables.io/data-residency) ### Our enterprise clients require SOC 2. Is that on the roadmap? We do not hold SOC 2 or ISO 27001. The deployment runs inside your environment, and your team is responsible for including it in your controls and audit scope. If procurement requires a vendor certificate regardless of architecture, tell us early. ### How does an open-source project handle security patches? Through the repository's disclosure process, with fixes released like any other change. Release cadence runs every two to three weeks. Because the code is public, your own team can review a patch before applying it rather than trusting a changelog entry. ### Is GDPR compliance easier than with a hosted aggregator? The data stays in your cloud account. Where you run it yourself, we have no access. When we work on your system, we do it under a DPA you sign and act as your processor, or a sub-processor in your customer's chain. Your compliance programme still needs to cover the deployment and its processing. → [Sub-processors](https://openwearables.io/sub-processors) · [Data governance](https://openwearables.io/data-governance) ### Our data cannot leave a specific country. Does that work? That is the case this architecture exists for. You pick the region at setup, and proving where the data sits means showing an account you control rather than citing a policy page. Where a country names a specific legal instrument, the residency pages say which one. ### Can we keep the original provider data, not just the normalised version? Yes, if you switch it on. The raw payload can be written to a bucket you own before normalisation runs. It is off by default, so a deployment that does not need it carries no extra storage. Teams turn it on when they expect to re-derive something later that nobody thought to ask for today. ### Do you hold SOC 2 or ISO 27001? No. The deployment runs inside your certified environment, which is how most teams answer this in their own audit. ### Who can reach our users' data? Your team. It runs in your cloud account, under your credentials. When we work on your system, we do it under a DPA you sign. The sub-processors page covers both operating models. ### Will you sign a DPA? A BAA? Yes, whenever our people can reach your deployment: under Pro support, during a Deployment or Integration service, and for as long as Enterprise runs. Where you self-host on Core, there is no processing for us to agree to, because we never touch it. A BAA comes with Enterprise, where your cloud provider and your scope support it. The what we sign page has the full position. 06 ## Pricing & Business Model ### I'm building a B2C app at $4.99 per month. Is the cost model viable at that price point? Yes. The core has no licence fee. Paid extensions are licensed separately. What you pay us for the deployment is engineering time at the start, not a share of every user. What scales with your user count is your own cloud bill, paid directly to your provider. At consumer app volumes that is a small number, and it does not change shape when you grow. ### How does the cost compare to a hosted aggregator? Different shape rather than a smaller number. Hosted APIs price by how much you use them, through users, credits or plan tiers, so the bill follows your growth; each publishes its current plans on its own pricing page. Here Core is free, Pro is priced per deployment rather than per user, and your own infrastructure is billed by your cloud provider. Teams with few users often find a hosted API cheaper. The pricing page has the figures for our side. ### Why is it free? What does Momentum get from this? The core platform is MIT licensed. Momentum charges for Pro, Enterprise, the Deployment and Integration services and custom development. Running it yourself costs your own cloud bill. The pricing page covers what is available today. ### We are a two-person team. Can we realistically self-host and maintain this? If you can run a PostgreSQL database and deploy Docker containers, you can run this. What small teams underestimate is not the setup but the maintenance, because provider APIs change without asking and each change costs somebody a day or a week. That is the honest reason maintenance exists as a paid service rather than a nice-to-have. ### Can we embed Open Wearables into our platform and offer wearable data to our own clients? Yes. MIT means no licensing restriction on that, and several teams do exactly this. Worth knowing separately: provider terms usually have their own rules about passing data on, so check those alongside ours. ### What does it actually cost? Deployment starts at $4,800 and Integration at $9,600, both one-time. Maintenance comes with Enterprise, and Enterprise and custom development are scoped and quoted, because the work varies too much to publish one number. Every figure starts at, and we confirm it before you commit to anything. → [Pricing](https://openwearables.io/pricing) ### What does it cost to run, on top of what we pay you? Your own cloud bill, paid directly to your provider and never marked up by us. What drives it is your user count, how much history you keep and what retention policy you set. Anyone quoting you a single number for that without asking about your volumes is guessing. ### Do we have to keep paying to keep it running? No. A deployment is a one-time engagement, and plenty of teams run it themselves afterwards with the infrastructure code, the documentation and a walkthrough. Moving to Enterprise, which adds maintenance, is a decision you can take later, usually after the first provider change costs somebody a week. 07 ## Health Scores & AI ### What exactly is a health score? A single number computed from raw signals, designed so a person or an assistant can act on it without reading the underlying time series. Ours are designed and validated by our science team and computed inside your deployment. Health scores come with Pro. → [Health scores](https://openwearables.io/platform/health-scores) ### We're building AI coaching. Can the MCP server power personalised recommendations? It gives an assistant structured access to your users' data, which is the retrieval problem solved. The coaching logic, the tone and the clinical judgement are yours to write. What the MCP server removes is the plumbing between a model and a database. ### We need population-level analytics across our user base, not just individual dashboards. Everything lands in your own PostgreSQL under one schema, so population queries are ordinary SQL against a database you control. There is no analytics product on top, and for most teams that is the right answer because they already have their own. ### Can I build proprietary algorithms on top? Yes. MIT means what you build stays yours, including anything you compute from the data. Nothing has to be contributed back. ### What AI models can I use? Any that speak the Model Context Protocol, which today includes Claude and several others. The model is your choice and your contract, and we are not between you and it. ### Can a score be tuned for our population? That is one of the most common pieces of custom work. A sleep score for people with sleep apnoea is not the same algorithm as one for healthy young adults, and the difference is methodology rather than a setting. It is work with our science team rather than a configuration change. → [Health scores](https://openwearables.io/platform/health-scores) · [Pricing](https://openwearables.io/pricing) ### If you build a custom algorithm for us, who owns it? You do. Anything built for a client belongs to the client, including the methodology. 08 ## Evaluating Alternatives ### I'm currently on a hosted API. Why consider switching? Control comes up first. With a hosted API the data passes through somebody else's infrastructure and the provider relationship is theirs. Here the deployment runs in your cloud account, under your credentials, with the provider apps registered to you. Cost shape comes up after that: a hosted API's bill follows your usage, while here Pro is priced per deployment rather than per user. Whether those matter depends on your situation, and if they do not, a hosted API is a reasonable choice. → [Compare alternatives](https://openwearables.io/compare) ### We're evaluating hosted aggregators against Open Wearables. What are the honest trade-offs? A hosted API is faster to start and someone else runs it. This is slower to start, needs your own provider accounts, and you run it or pay us to. What you get for that is the data staying in your account, under your credentials, and source code you can read. If speed matters more than control and you have no regulator or enterprise security review coming, take the faster route. ### We need speed to market now but data ownership later. What's a realistic path? You do not have to choose. Teams start with a deployment we stand up, which is faster than building it themselves, and own it from day one. The alternative path, starting hosted and migrating later, means re-authorising every user, because OAuth tokens belong to the application that requested them. ### We're a large company. Can we trust an open-source project at pre-1.0 for production? It runs in production at consumer app scale today. The version number describes API stability rather than reliability, and the live versus roadmap page is specific about what is settled and what may still change. Worth weighing against the alternative: a closed product where you cannot inspect any of this. ### What if Open Wearables stops being maintained? You keep everything. MIT means the code is yours, the deployment is in your account, and your team can maintain it or hand it to someone else. That is a materially different position from a hosted vendor shutting down, where the data path disappears with them. ### We're looking at a managed health data platform. How does this compare? Managed platforms give you speed and take on operations. Open Wearables gives you control over the deployment, data path and code. If you run it yourselves, we have no access. When we work on your system, that access is named in a DPA you sign and reviewed as part of your processor chain. ### We're evaluating managed platforms for AI coaching. What are the trade-offs? Managed platforms usually keep the data and the scoring in their own cloud. Here health scores from our science team are computed inside your deployment, your own logic runs next to them, and the MCP server points at your own data rather than a vendor's. The trade-off is that you are running it. ### Is there an open-source alternative to the commercial wearable APIs? This is one. MIT licensed, self-hosted, with the provider integrations and the normalised schema in the repository. Health scores come with Pro. ### We're comparing on cost and data control. What are the trade-offs? On control, the difference is categorical: either the data passes through somebody else's infrastructure or it runs in your own account. On cost, the shape differs more than the number: a hosted API's bill follows your usage, while Core is free and Pro is priced per deployment rather than per user. 09 ## Migration & Compatibility ### If we switch from a hosted aggregator, do all our users have to re-authorise their devices? Yes, and this is the single biggest cost of switching. OAuth tokens belong to the application that requested them, so moving to your own provider accounts means every user reconnects. Plan a re-consent campaign rather than treating it as a technical migration. ### Can we run both in parallel during migration? Yes, and most teams do. Stand up a deployment alongside the existing integration, move users across in batches, and keep the old path running until the new one is proven. ### We already have Garmin and Apple Health integrated directly. Is there still value? Usually, for four reasons: the providers you have not built yet, one schema instead of per-provider mapping, the maintenance moving off your team, and what direct integration gets you that Apple Health does not. ### Can we keep our own data schema instead of adopting yours? Yes, though mapping between schemas adds time and cost to the engagement. Most teams find the normalised model is the part they wanted in the first place. 10 ## Roadmap & Status ### What are the known limitations right now? Be honest. Data leaves through the API and webhooks rather than bulk export. There are no direct sensor connections over Bluetooth, because data arrives from provider clouds. The API may still change before a stable release. → [Live versus roadmap](https://openwearables.io/live-vs-roadmap) ### What's new in the latest releases? Releases run every two to three weeks and each one has notes on GitHub. That is the authoritative list rather than a page we update by hand. ### How can I influence the roadmap? Open an issue or raise it on Discord. Demand shapes priority, and a customer with a concrete case tends to move things faster than a vote. ### What's the longer-term vision beyond wearables? Wider health data: nutrition, lab results, clinical system integration. The roadmap in the docs has the current sequencing. 11 ## Enterprise & Support ### What does working with Momentum actually look like? Three shapes. Self-host and use Discord, which costs nothing. A one-time engagement to stand it up or wire it into your product. An Enterprise agreement for maintenance, security paperwork and a named person on call. The pricing page has what each covers. ### What is Momentum? A healthcare software company working in health data since 2016. Momentum holds ISO 13485, the quality management standard for medical device development, and works inside HIPAA, GDPR and FHIR as a matter of course rather than as a special case. Open Wearables came out of building the same integrations repeatedly for clients who needed to own the result. → [Enterprise](https://openwearables.io/enterprise) ### Where can I get help? Discord for the open-source project, where the community and our engineers both answer. A dedicated channel and defined response times come with Enterprise. GitHub issues for bugs and feature requests. ### How active is the community? Releases every two to three weeks, an open issue tracker and community-contributed provider integrations. The repository shows all of it rather than a curated summary. ### Is anyone running this in production? Yes. Heart Monitor runs Open Wearables at around 90,000 monthly active users, on a deployment their own team operates. ### You have a lot of open issues on GitHub. Should we be worried? They are mostly feature requests and community proposals rather than defects. An open repository shows its backlog in public, which a closed product simply does not. Release cadence is the more useful signal, and it runs every two to three weeks. ## Still something we have not answered? Most of what ends up on this page started as a question somebody asked on a call. If yours is not here, it probably belongs here. [Ask on Discord](https://discord.gg/qrcfFnNE6H) [Book a call](https://openwearables.io/book) --- Source: https://openwearables.io/for # Find the page written for what you are building. Solutions The same self-hosted deployment in every case: your cloud account, your region, your credentials, MIT licensed. What changes is why owning it matters. Find the page written for your situation. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo Who it is for · 1 ## Digital health products Ship wearable features in your own product: scores your users check every morning, coaching from each user's own history, analytics across the devices they already wear. [See pricing](https://openwearables.io/pricing) [Book a demo](https://openwearables.io/book?tier=pro) ### Digital health products Commercial health products where the data model and what you build on it are part of what you sell. [Learn more](https://openwearables.io/for/digital-health) ### Health data platforms EHR, telemedicine and aggregator platforms that are already somebody's processor. [Learn more](https://openwearables.io/for/health-data-platforms) ### Corporate and employer wellness One set of metrics across a member population, with the processor obligations that follow. [Learn more](https://openwearables.io/for/employer-wellness) ### Sports and nutrition brands Training load, fuelling and recovery behind a coaching product. [Learn more](https://openwearables.io/for/sports-nutrition) Who it is for · 2 ## Care programmes Run a monitored programme without building the software: a patient app or SDK, a care view your team opens every morning, consent on every reading. [Book a demo](https://openwearables.io/book?tier=programme) ### Care providers Run a monitored programme without building the software. [Learn more](https://openwearables.io/for/care-providers) ### Remote patient monitoring Readings from the patient's own device, in the record their clinician reads. [Learn more](https://openwearables.io/for/remote-patient-monitoring) Who it is for · 3 ## Hospitals and telemedicine Wearable data in the record your clinicians already open: readings written into your EHR, with a source on every value. [Book a demo](https://openwearables.io/book?tier=clinical) ### Hospitals and telemedicine Wearable data in the EHR your clinicians already open. [Learn more](https://openwearables.io/for/hospitals-telemedicine) ### Clinical and research builders Teams heading for review, who need auditable inputs and documented validation. [Learn more](https://openwearables.io/for/clinical-research) The common part ## The deployment does not change between them. One architecture, whichever page you came from. Whatever your situation, this is what the layer underneath is. ### One schema across the devices your users own. Query a user, not a provider. Activity, sleep, heart rate and body measurements in one shape, in your own database. ### Your cloud account, your region. You choose where it runs when it is deployed, so residency stops being a clause and becomes a fact you can point at. ### Raw payloads kept underneath. Original provider responses are retained under the standard schema, so anything you need later can be re-derived. ### Open source, MIT licensed. Full source, a public roadmap and public issues. The deployment stays yours, whoever runs it. ## Connect the devices your users already own. Every provider arrives in the same schema, so a user who switches watch or adds a ring changes nothing in your code. [Browse integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## Deploy Open Wearables in your own cloud. The repository is public and the deployment is yours from the first commit. Start from the source, or tell us what you are building and we will say honestly what it takes. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) FAQ ## Do you have more questions? ### Which page should I read? Pick by the constraint rather than by the industry label. If somebody outside your company reviews where the data goes, start with [health data platforms](https://openwearables.io/for/health-data-platforms). If a rule keeps data inside a jurisdiction, start with [remote patient monitoring](https://openwearables.io/for/remote-patient-monitoring). If a number has to survive review, start with [clinical and research builders](https://openwearables.io/for/clinical-research). If nobody is forcing it and you want the data and what you build on it to be yours, start with [digital health products](https://openwearables.io/for/digital-health). ### Is the product different for each segment? No. It is one deployment, one schema and one repository in every case. The pages differ in which part of it answers the question you are being asked, and in the worked examples. Nothing is gated or priced by segment. ### What if we are in two of these at once? Common, and it changes nothing technically. Read the page that matches whoever is asking the hardest question, because that is the one written in their language. A company selling a consumer app to employers is both a digital health product and an employer wellness vendor, and it deploys exactly the same thing. ### None of these describe us. Is it still for us? Possibly. The product fits wherever wearable data cannot sit in somebody else's cloud. These pages are the situations where that comes up most, not a list of permitted uses. Retail, FMCG and consumer sports brands without a data product are usually a poor fit, and a hosted API serves them better. ### Where is the data stored in all of these? In your own cloud account, in the region you choose at deployment, under your credentials. That does not vary by segment. No copy sits in a Momentum tenant in either operating model. ### Can we run it ourselves? Yes. Clone the repository and run it under an MIT licence, with the full source. The alternative is buying a deployment, where we stand the same thing up inside your account. [Pricing](https://openwearables.io/pricing) has what that covers. ### Is it open source? Yes, MIT licensed, with the full source, a public roadmap and public issues. Health scores come with Pro. The deployment stays in your account, whoever runs it. ### Who maintains it? Momentum, a healthcare software development company. The project is developed in the open, so the source does not depend on us continuing to fund it. --- Source: https://openwearables.io/for/care-providers # Run a monitored programme without building the software. Care programmes Open Wearables for care programmes, clinics, senior care and prevention centres: a patient app, a care view for your team and support, running in your own cloud account from the first reading. [Book a demo](https://openwearables.io/book?tier=programme) Already running on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo The problem ## Your patients already wear the devices. Using that data in a programme is the hard part. Care programmes, senior living operators and prevention centres tell us the same thing: the readings exist, but turning them into something a care team can trust and act on takes software they do not have. ### Everyone wears something different An Apple Watch, an Oura ring, a Withings scale, a glucose sensor: each with its own app, API and level of detail. ### A number you cannot trust A vendor changes its algorithm without notice, or a device misses a night. Before calling a patient, your team needs to know where a value came from. ### The right view for each team Caregivers on each campus or site see their own residents, with wellness and medical readings kept apart on one screen. ### A pilot that waits on a build Building the patient app, the backend and the team view in-house takes months before the first patient joins. The solution ## Everything around the data, so your team can run the programme Open Wearables collects readings from the devices your patients wear. We deploy it in your account and set up the rest with you, so the programme starts without a software project in front of it. ### Connect App Patients join with a link or a QR code and connect their phone and wearables, with no account to create. If you already have an app, our SDK goes inside it instead. [Learn more](https://openwearables.io/platform/connect-app) ### Care view Trends, adherence, raw values and notes for each patient, with roles per site. It shows the data and leaves every decision to your team. ### Consent records Each patient sees who receives the data and chooses what to share. The consent is recorded next to their readings from the first day. ### Runs in your cloud Production and staging in your own cloud account, in the region you choose, under your credentials. The data, the keys and the code stay yours. ### Support Provider changes, upgrades and fixes handled by the team behind Open Wearables, with response windows agreed in your contract. What it does ## From a patient's wrist to your care team, in three steps. 01 Connect ### Patients connect what they already wear Invited with a link or a QR code, they pick Apple Health, Health Connect or their wearable account and confirm who receives the data. 02 Your cloud ### Readings land in your own cloud account Every connected source arrives in one schema, in your region, under your credentials, with consent recorded alongside. 03 Your team ### Your team sees the week at a glance Days worn, trends and the last sync for each patient, on one screen per site. The outcome ## Continuous, remote monitoring of your patients' health. The questions a care team asks first, answered before anyone opens a spreadsheet. ### Chronic care between visits Heart failure, diabetes or COPD programmes: who is syncing, who has gone quiet, and a reminder on its way. A week of syncs across a heart failure programme, 36 of 42 syncing, two quiet patients to remind, one reminder sent. ### Follow-up after discharge Each patient's readings beside the weeks before, with the device each value came from. A heart failure patient's readings, each with its device and sync time, beside fourteen days of weight rising 1.1 kg in three. ### Senior care and prevention Residents or members followed across sites, with what changed since the last visit ready before it. A brief before a 10:30 follow-up: sleep down 35 minutes a night and resting heart rate up 4 bpm since the last visit. Who it is for ## Organisations that look after a group of people between visits. If you run the programme rather than build software for others, this page is for you. ### Care programmes and virtual wards Hospital at home, post-discharge follow-up and chronic care programmes that need readings from home without a device logistics project. ### Clinics Clinics that want to see how patients do between appointments, with the data kept in an account the clinic controls. ### Senior care operators Residential and home care providers following residents' sleep, activity and heart rate across sites, with roles per site. ### Longevity and prevention centres Programmes built on members' own wearables, where the history between visits is what the member pays for. ## Connect the devices your patients already own. Each connected source arrives in the same schema, so a patient who switches watch or adds a ring changes nothing on your side. [Browse integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## See it running for your programme. Tell us about your patients or residents and what you want to follow, and we will show you Open Wearables set up for it. [Book a demo](https://openwearables.io/book?tier=programme) FAQ ## Do you have more questions? ### How long until we are live? About a month from the start to the first patients sending data. Your first cohort then runs for three to six months before the programme scales. ### Do we need our own developers? No. We deploy Open Wearables in your cloud account and set up the patient app and the care view with you. If you have developers, they can build on the same API. ### Which devices can patients use? The consumer wearables they already own, through Apple Health, Health Connect and each provider's own connection. The [integrations page](https://openwearables.io/integrations) lists the current sources. ### Can residents without a smartphone take part? Most wearables sync through a phone today. For residents without one, we work out the setup with you during the first cohort, such as devices that sync on site. ### What happens when a device vendor changes its algorithm? Every reading keeps the device, the provider and the raw response it arrived in, so a change can be traced to its source instead of reading as a change in your patient. ### Can each site or campus have its own access? Yes. Roles are set per site, so each team sees the patients assigned to them, and patients see only their own data. ### Where does patient data live? In your own cloud account, in the region you choose. When we work on your deployment, we do it under a data processing agreement you sign. --- Source: https://openwearables.io/for/clinical-research # Every number traceable to the data behind it. Clinical and research builders Open Wearables runs in your own cloud account and keeps the raw provider payload under every value, so a reviewer's question has an answer you can point at. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=clinical) Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo What you get ## What Open Wearables gives a regulated team. Reviewers, ethics boards and notified bodies all ask where a number came from. Open Wearables is built so the answer is a file you can open, not a vendor you have to ask. ### Scores with their validation. Scores come with what they measure and how they were validated. They are designed by our science team and computed inside your deployment. - Validated - Part of Pro ### A pipeline you can cite. The data pipeline is MIT-licensed open source, so how a raw payload becomes a standard value can go into a paper, a technical file or an ethics submission. - Open pipeline - Citable - MIT license ### Raw payloads kept. Original provider responses are retained under the standard schema, so a value can be re-derived years later and a reviewer's question has an answer in your own database. - Raw payloads kept - Re-derivable ### Your region, provably. You choose where it runs when it is deployed. Where participant data sits stops being a clause you negotiate and becomes a fact you can point at. - Your region - eu-central-1 ### The boundary stays yours. Which features exist and where they run is yours to decide, because the data layer runs inside your deployment rather than behind somebody else's roadmap. - Your deployment - Your scope ### Credentials in your name. Each source issues developer credentials to your organisation, so the data relationship sits between you and them, with nobody in the middle to disclose. - Your credentials - Your account How it works ## From protocol to first dataset. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=clinical) 01 ### Deploy it. Production and staging in your own cloud account, in the region you choose, defined as infrastructure code in your repository. Either your team stands it up, or you buy a deployment and we do it inside your account. 02 ### Get your own provider credentials. Each source issues developer credentials in your name, and you apply for them directly. Approval timelines vary and this is the slowest step, so it starts on day one. 03 ### Enrol participants. Participants authorise through each provider's own consent screen, inside your interface, so consent is recorded where the rest of your study documentation lives. 04 ### Query the dataset. Standardised data lands in your own database with the raw responses underneath, so analysis runs against data you hold rather than an export you requested. [See pricing](https://openwearables.io/pricing) The honest comparison ## Hosted API, in-house, or self-hosted. Where each one wins. If a hosted API fits your situation, use one. | | Hosted SaaS API | Build in-house | Open Wearables | | --- | --- | --- | --- | | [01] First API call | Hours | Months | Minutes, with Docker Compose | | [02] Scoring logic | Proprietary, not published | Build and validate it yourself | Part of Pro, with what it measures and how it was validated | | [03] Where a number came from | Ask the vendor | Whatever you documented | Source kept per value, raw payload underneath | | [04] Where participant data sits | Their cloud, their regions | Yours | Your cloud account, your region | | [05] Third-party risk assessment | Yours to write and defend | Not applicable | Not applicable when you run it | | [06] Provider credentials | Theirs, handled for you | Yours to obtain | Yours, in your own name | | [07] Certifications | Theirs | Yours to earn | Yours, in your certified environment | | [08] Cost shape | Scales with monthly active users | Salaries and infrastructure | Fixed. Flattens as you grow | What stays yours ## The deployment, the data and the algorithms stay in your account, whoever runs it. ### Sovereignty Participant data does not sit in a third party's cloud. ### Residency It stays in the region you chose, provable by pointing at an account. ### Control You decide who reaches participant data, under your own credentials. Your analysis and your own logic are yours. ### Your own reasons Before a reviewer or a notified body asks, the raw data behind every number is in your account. Who it is for ## The teams this fits. Two shapes, one job: produce outputs that survive somebody else's review. ### Clinical AI and SaMD teams Heading for a DiGA, CE or FDA decision, where the technical file has to explain every computation in the product. ### Academic research platforms Working under ethics approval, where the provenance of a measure has to be documented and the dataset has to outlive the grant. ### Digital biomarker and endpoint developers Where the measure is the product, so its derivation is the thing being scrutinised. ### Decentralised trial teams Collecting from participants' own devices, where provenance and completeness decide whether the data is usable. What you can build ## What teams build on it. The data lands in your database with its origin intact, so what you build on top is analysable from day one. ### A validated measure Your own measure, built with your own logic on the data in your deployment, and documented by your team for anybody who asks. A recovery score's method v2.1, its inputs and weights tuned for the study, cited in a manuscript's Methods. ### A study dataset Continuous data per participant with the raw responses kept underneath, so a question raised at review can be answered against what actually arrived. A reviewer asks where a resting heart rate came from; the answer shows the value, its device and sync time, and the raw payload line. ### A cohort view The same measure across a study population, computed in your own database rather than exported from a vendor on their schedule. Figure 2 of a study: recovery index by arm over six weeks, intervention rising above control, a difference of 7 at week 6. ## Connect the devices your participants already own. Every device arrives in the same schema, so participants keep the watch or ring they wear and your analysis reads one shape of data. [Browse integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) Care and clinical ## Two paths for care providers, hospitals and telemedicine platforms Care providers, hospitals and telemedicine platforms run the same platform, set up for their patients, their team and their records. ### Care providers and programmes Continuous remote monitoring for care programmes, clinics and senior care: a patient app, a view for your care team and support. [Learn more](https://openwearables.io/for/care-providers) ### Hospitals and telemedicine Wearable data in your patients' app and in your health records, with a source on every value and an SLA per site. [Learn more](https://openwearables.io/for/hospitals-telemedicine) ## Deploy Open Wearables in your own cloud. The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account with the providers connected and validated on real accounts. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=clinical) FAQ ## Do you have more questions? ### We run a clinical service. How do we start? With one site first: wearable data in your health records, with a source on every value, within about three months. See [Open Wearables for hospitals and telemedicine](https://openwearables.io/for/hospitals-telemedicine). ### Will you get our device certified? No, and nobody can do that for you. We provide auditable inputs and documented validation. The clearance, the technical file and the claims are yours, and a vendor who implies otherwise is worth a second look. ### Our score is not a medical device today. Does this change that? That depends on your claims and your intended purpose, not on us. What we can say is that which features exist and where they run stays your decision, because the data layer runs inside your deployment rather than behind somebody else's roadmap. ### Can we read how a score is computed? You get what each score measures and how it was validated. The method itself belongs to our science team, and health scores are part of Pro. The data pipeline underneath is MIT licensed and readable, and your team can build its own measures on the same data. ### Can we cite it in a paper? Yes. The source is MIT licensed, so the pipeline can be referenced in a publication or an ethics submission without asking us. For a health score, you cite what it measures and how it was validated. ### Is a computed score personal health data? That is your DPO's call for your product, not ours. What we can say is that the score is computed and stored inside your own account, so whatever the answer is, the protections are yours to apply rather than a vendor's to promise. ### Where does participant data physically live? In the cloud account and region you choose at deployment. You can point at the account rather than describing a policy, which is usually what an ethics committee is asking for. ### What happens to the dataset when the grant ends? It stays where it is, in your own account, because there is no vendor tenant holding it and no retention window set by somebody else. ### Do you hold SOC 2 or ISO 27001? No. The deployment runs inside your certified environment, which is how most teams answer this in their own audit. ### Does it speak FHIR? Not natively today. Open Wearables keeps wearable data in its own standard schema, with the raw provider payloads underneath. It is not a FHIR server, and EHR-ready FHIR output is on the roadmap. In a hospital or telemedicine rollout, we map the readings to FHIR resources (Observation, Device, Provenance and Consent) and write them into your record as part of the rollout. Otherwise the mapping is work your team does against a stable schema. ### Is it running in production anywhere? Yes, at consumer app scale, with the deployment running in the adopter's own infrastructure. [Customers](https://openwearables.io/case-studies) has the named adopters and what each of them built. ### Who maintains Open Wearables? Momentum, a healthcare software development company. The project is MIT licensed and developed in the open, with a public roadmap and public issues, so the source does not depend on us continuing to fund it. --- Source: https://openwearables.io/for/digital-health # Build your health product on a wearable data layer you own. Digital health products Open Wearables is self-hosted wearable data infrastructure for commercial health products. It connects the devices your users already own and keeps the data, the schema and the scoring inside a cloud account you control. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=pro) Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo What you get ## What Open Wearables gives your product team. Providers authorise differently and each returns its own shape. Open Wearables handles that inside infrastructure you own, so a quarter of integration work becomes a deployment. ### One standard schema Query a user, not a provider. Activity, sleep, heart rate and body data in one shape, joinable with the rest of your product. - Raw payloads kept - Time series - Webhooks ### Your database, your credentials The data lands in infrastructure you fully control, with retention you set. No copy sits in a vendor tenant. - Your account - Your region ### Custom health scores Scores designed and validated by our science team, computed inside your deployment. Custom scores for your population are built with the same team. - Health scores - Science team ### Data off the device Native SDKs for iOS, Android, Flutter and React Native sync on-device data in the background, inside your own app. - HealthKit - Health Connect ### Costs you can see Running it costs your own cloud bill, paid to your provider. Deployment and Integration are one-off services, and health scores and the other licensed modules come with Pro. - Your cloud bill - One-off services ### A public roadmap and an open community Issues, releases and what ships next are public. Community support on Discord, and the source does not depend on us continuing to fund it. - MIT license - Full source - GitHub How it works ## From decision to launch [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=pro) 01 ### Deploy it Production and staging in your own cloud account, in the region you choose, defined as infrastructure code in your repository. Either your team stands it up, or you buy a deployment and we do it. 02 ### Get your own provider credentials Each source issues developer credentials in your name, and you apply for them directly. Approval timelines vary, so this is the step to start first. Garmin is the slowest: [Garmin API integration](https://openwearables.io/integrations/garmin). 03 ### Wire it into your product The mobile SDK goes into your app, syncing in the background behind your existing login. The connection and consent flow sits in your own interface, not a vendor's widget. 04 ### Ship, then extend Standardised data lands in your database, so the next feature is a query rather than a procurement conversation. [See what a deployment covers](https://openwearables.io/pricing#services) The honest comparison ## Hosted SaaS API, in-house build, or self-hosted Where each one actually wins. If a hosted API fits your situation, use one. | | Hosted SaaS API | Build in-house | Open Wearables, self-hosted | | --- | --- | --- | --- | | [01] First API call | Hours | Months | Minutes, with Docker Compose | | [02] Where the data sits | Their cloud, their regions | Yours | Your cloud account, your region | | [03] Who can reach the data | The vendor and its sub-processors | Your team | Your team, and us under a DPA you sign when we work on it | | [04] The data model | Theirs, you build against their schema | Yours | Yours, in your database | | [05] Scoring logic | Proprietary, not published | Build and validate it yourself | Designed and validated by our science team, licensed as a module | | [06] Provider credentials | Theirs, handled for you | Yours to obtain | Yours, in your own name | | [07] Certifications | Theirs | Yours to earn | Yours, in your certified environment | | [08] Cost shape | Scales with monthly active users | Salaries and infrastructure | Fixed, flattens as you grow | What stays yours ## The deployment, the data and the algorithms stay in your account, whoever runs it ### Sovereignty Health data does not sit in a third party's cloud. ### Residency Your users' data stays in the region you chose, provable by pointing at an account. ### Control You run it under your own credentials and decide who gets access. What you build on top of Open Wearables is yours. ### Your own reasons Before a regulator or customer asks, the schema and the data are in your account. Who is it for ## The product types this fits The argument for owning the layer lands differently depending on who is asking. These are the situations where it lands hardest. ### Consumer health and fitness apps Direct to consumer, where the scoring is part of the product and GDPR sets the floor for every health score you compute. ### Longevity and biomarker platforms Where due diligence asks what a number measures, how it was validated and where the data behind it sits. ### B2B digital health platforms with enterprise clients Where your customer's procurement runs a vendor assessment and asks for compliance documentation you have to produce yourself. ### Employer wellness vendors Where you are a processor for the employer and need standard metrics somebody can audit across a member population. ## What teams build on it Coaching, scoring and analytics on the devices your users already wear, built inside your own deployment. ### A scoring model A health score computed inside your deployment from your users' own data, designed and validated by our science team. ### Health analytics Months of sleep and resting heart rate in one timeline, held in your database rather than a vendor's retention window. ### A coaching engine Today's session comes from that user's own history, generated by your model. What makes the coaching good stays yours. ## Whatever your users wear, one schema Cloud providers and on-device sources arrive in the same shape, so supporting another device later does not change your code. [Browse integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## Deploy Open Wearables in your own cloud The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account with the providers connected and validated on real accounts. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=pro) FAQ ## Do you have more questions? ### We have a launch date. How fast can this be live? First API call in five minutes with Docker Compose. The long pole is provider credentials, which are issued in your name and take from a day to several weeks depending on the source. A deployment starts that work on day one and runs the rest in parallel. ### Is it really free? The core is. It is MIT licensed, with the full source and no trial window. We charge for Pro, Enterprise, the Deployment and Integration services and custom development. ### What does it cost compared with a hosted API? A hosted API prices per monthly active user, so the bill grows with your success. This is a one-off deployment cost plus your own cloud bill, paid directly to your provider and never marked up by us. [Pricing](https://openwearables.io/pricing) has the figures. ### Can we use this for a HIPAA workload? The deployment runs on your infrastructure, so access, encryption, retention and audit logging are yours to control and to evidence. A BAA depends on your cloud provider and your scope. ### Who can reach our users' data? Your team. It runs in your cloud account, under your credentials. When we work on your system, we do it under a DPA you sign. [What we sign](https://openwearables.io/what-we-sign) sets out when the DPA applies. ### Do you hold SOC 2 or ISO 27001? No. The deployment runs inside your certified environment, which is how most teams answer this in their own audit. ### Our enterprise customer wants a DPA. Will you sign one? Yes, whenever our people can reach your deployment: under Pro support, during a Deployment or Integration service, and for as long as Enterprise runs. Where you self-host on Core, there is no processing for us to agree to, because we never touch it. ### We already use a hosted aggregator. How hard is moving? Usually a re-integration rather than a data migration. Your historical data stays where it is, and what changes is where new data lands from the switch onwards, which is your own database. Most teams run both in parallel while they validate, then cut over. ### Is it running in production anywhere? Yes. Heart Monitor runs Open Wearables in production at around 90,000 monthly active users. They adopted the open-source project and shipped it with their own team. ### What about the scores? Can we build our own? Yes. Health scores are part of Pro, designed and validated by our science team and computed inside your deployment. Custom scores for your population are built with the same team, and your own logic can run on the same data. ### Who maintains Open Wearables? Momentum, a healthcare software development company. The project is MIT licensed and developed in the open, with a public roadmap and public issues, so the source does not depend on us continuing to fund it. --- Source: https://openwearables.io/for/employer-wellness # The data layer under your wellness programme. Employer wellness Open Wearables connects the devices your members already wear and returns their activity, sleep and heart rate in one schema, so your programme works the same whichever watch or ring somebody chose. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=pro) Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo What you get ## What Open Wearables gives a wellness platform. Every question an employer asks about member data ends up as a question about your vendors. Open Wearables keeps the wearable layer inside your own account. ### Access you control. It runs in your cloud account, under your credentials, so member data does not reach a vendor tenant. When we work on your system, we do it under a DPA you sign. - Your account ### One schema, one population. Query a member, not a provider. Whatever device somebody chose, the metric arrives in the same shape, so a cohort report does not depend on who wears what. - One schema - Any device - Time series ### Know the moment it happens. A webhook fires when new steps, a workout or a night of sleep arrives, and when a member disconnects a device, so leaderboards update themselves and nobody drops out unnoticed. - steps.created - connection.revoked ### Your region, provably. You choose where it runs when it is deployed. Where member data sits becomes a fact you can show rather than a clause you negotiate per client. - Your region - eu-central-1 ### Credentials in your name. Each source issues developer credentials to your organisation, so the data relationship sits between you and them. - Your credentials - Provider apps in your name ### Costs you can see. Running it costs your own cloud bill, paid to your provider. Deployment and Integration are one-off services, and health scores and the other licensed modules come with Pro. - Your cloud bill - One-off services How it works ## From decision to first cohort. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=pro) 01 ### Deploy it. Production and staging in your own cloud account, in the region you choose, defined as infrastructure code in your repository. Either your team stands it up, or you buy a deployment and we do it inside your account. 02 ### Get your own provider credentials. Each source issues developer credentials in your name, and you apply for them directly. Approval timelines vary and this is the slowest step, so it starts on day one. 03 ### Enrol members. Members authorise through each provider's own consent screen, inside your interface, so what they agreed to is recorded in your product rather than somebody else's. 04 ### Query the population. Standardised data lands in your own database, so a cohort report for an employer is a query rather than an export you wait for. [See pricing](https://openwearables.io/pricing) The honest comparison ## Hosted API, in-house, or self-hosted. Where each one wins. If a hosted API fits your situation, use one. | | Hosted SaaS API | Build in-house | Open Wearables | | --- | --- | --- | --- | | [01] First API call | Hours | Months | Minutes, with Docker Compose | | [02] Who can reach the data | The vendor and its sub-processors | Your team | Your team, and us under a DPA you sign when we work on it | | [03] Where member data sits | Their cloud, their regions | Yours | Your cloud account, your region | | [04] The data model | Theirs. You build against their schema | Yours | Yours, in your database | | [05] Raw provider payloads | Varies by vendor | Whatever you keep | Kept in your own bucket when you turn it on | | [06] Provider credentials | Theirs, handled for you | Yours to obtain | Yours, in your own name | | [07] Certifications | Theirs | Yours to earn | Yours, in your certified environment | | [08] Cost shape | Scales with monthly active users | Salaries and infrastructure | Fixed. Flattens as you grow | What stays yours ## The deployment, the data and the algorithms stay in your account, whoever runs it. ### Sovereignty Member data does not sit in a third party's cloud. ### Residency It stays in the region you chose, provable by pointing at an account. ### Control You decide who reaches member data, under your own credentials. What you build on top of Open Wearables is yours. ### Your own reasons Before a client's procurement asks, the schema and the data are in your account. Who it is for ## The platforms this fits. This page is written for the team building the programme, not for the employer buying one. These are the shapes where owning the data layer changes the deal. ### Employer wellness vendors You are a processor for the employer, so their governance questions land on your desk and your vendor list is part of the answer. ### Benefits and insurance platforms Wearable data next to the benefits record you already hold, where the client is regulated and the review is thorough. ### Occupational health providers Health data about somebody's workforce, where who can reach it is the first question anybody asks. ### Wellbeing and engagement apps sold to companies Consumer-grade product, enterprise-grade procurement, and a security questionnaire that arrives before the contract. What you can build ## What teams build on it. Data arrives on its own from whatever device each person owns, so nobody has to log anything. ### A cohort report The same metric across a client's population, computed in your own database, so what you show the employer does not depend on a vendor's export schedule. An employer's quarterly wellbeing report from members on five kinds of device, and the aggregate PDF sent to HR. ### An engagement layer Streaks, team challenges and a weekly recap running on data that arrives on its own, which is what keeps a programme alive past week three. A team step challenge in week four: three teams on a leaderboard, 82% of members still active, every step synced from the member's own device. ### A member view What one person sees about their own trends, under your brand, computed inside your deployment from the member's own data. A member's week in a branded app: a recovery score of 74, the nights behind it, and how the score is calculated. ## Whatever your members wear, they can join. Each connected source arrives in the same schema, so a report or a challenge reads the same whichever device somebody chose. [Browse integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## Deploy Open Wearables in your own cloud. The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account with the providers connected and validated on real accounts. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=pro) FAQ ## Do you have more questions? ### Is this an employee wellness app we can roll out to our staff? No. Open Wearables is the wearable data layer that those apps are built on, so it belongs one level below the product your employees would open. If you are an employer comparing wellness apps, you want one of our customers rather than us. If you build the app, this is the part that connects the devices and standardises what comes back. ### Our HR client asks where member data lives. What do we tell them? The cloud account and region you chose at deployment, which you can point at rather than describe. Member data does not pass through a vendor tenant. When we work on your system, we do it under a DPA you sign. ### We are a processor for the employer. Who can reach member data? Your team. It runs in your cloud account, under your credentials, so member data does not reach a vendor tenant. When we work on your system, we do it under a DPA you sign. [The sub-processors page](https://openwearables.io/sub-processors) covers both. ### Can members use whatever device they already own? That is the normal case. Whatever somebody chose, the metric arrives in the same shape, so a cohort report does not depend on standardising the population onto one brand. ### Can we see individual data, or only aggregates? That is your decision to make and to defend, because the data sits in your database and the access rules are yours to set. Most programmes separate what the member sees from what the employer sees, and the architecture here does not force either shape on you. ### Do you hold SOC 2 or ISO 27001? No. The deployment runs inside your certified environment, which is how most platforms answer this in their own audit. ### Will you sign a DPA? Yes, whenever our people can reach your deployment: under Pro support, during a Deployment or Integration service, and for as long as Enterprise runs. Where you self-host on Core, there is no processing for us to agree to, because we never touch it. ### We already use a hosted aggregator. How hard is moving? Usually a re-integration rather than a data migration. Your historical data stays where it is, and what changes is where new data lands from the switch onwards. Most teams run both in parallel while they validate, then cut over. ### Is it running in production anywhere? Yes. Heart Monitor runs Open Wearables in production at around 90,000 monthly active users, and their own engineer did the integration in a week. [The case study](https://openwearables.io/case-study/heart-monitor) has the stack and the timeline. ### Who maintains Open Wearables? Momentum, a healthcare software development company. The project is MIT licensed and developed in the open, with a public roadmap and public issues, so the source does not depend on us continuing to fund it. --- Source: https://openwearables.io/for/health-data-platforms # Wearable data inside your platform, in your own cloud account. Health data platforms You are already a processor for somebody else. Open Wearables runs in your cloud account, under your credentials. When we work on your system, we do it under a DPA you sign. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=pro) Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo What you get ## What Open Wearables gives a platform team. Once you are a processor yourself, every system in the data path gets re-examined in governance reviews. Open Wearables keeps the wearable layer inside your own account. ### Access you control. It runs in your cloud account, under your credentials. When we work on your system, we do it under a DPA you sign. - Your account - No lock-in ### One schema, next to your record. Query a user, not a provider. Activity, sleep, heart rate and body measurements in one shape, in the same database as the rest of your platform. - One schema - Time series - Webhooks ### Raw payloads kept. Original provider responses are retained under the standard schema, so anything you need later can be re-derived without going back to the provider or to us. - Raw payloads kept - Re-derivable ### Your region, provably. You choose where it runs when it is deployed. Residency stops being a clause you negotiate and becomes a fact you can point at. - Your region - eu-central-1 ### Credentials in your name. Each source issues developer credentials to your organisation. The data relationship is between you and them, with nobody in the middle. - Your credentials - Provider apps in your name ### Costs you can see. Running it costs your own cloud bill, paid to your provider. Deployment and Integration are one-off services, and health scores and the other licensed modules come with Pro. - Your cloud bill - One-off services How it works ## From decision to first query. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=pro) 01 ### Deploy it. Production and staging in your own cloud account, in the region you choose, defined as infrastructure code in your repository. Either your team stands it up, or you buy a deployment and we do it inside your account. 02 ### Get your own provider credentials. Each source issues developer credentials in your name, and you apply for them directly. Approval timelines vary and this is the slowest step, so it starts on day one. 03 ### Wire it into your platform. Your users authorise through each provider's own consent screen, inside your interface. The mobile SDK handles on-device sources in the background, behind the login your platform already has. 04 ### Query the record. Standardised data lands in your own database, so joining a night of sleep to the rest of a patient record is a query rather than an integration project. [See pricing](https://openwearables.io/pricing) The honest comparison ## Hosted API, in-house, or self-hosted. Where each one wins. If a hosted API fits your situation, use one. | | Hosted SaaS API | Build in-house | Open Wearables | | --- | --- | --- | --- | | [01] First API call | Hours | Months | Minutes, with Docker Compose | | [02] Who can reach the data | The vendor and its sub-processors | Your team | Your team, and us under a DPA you sign when we work on it | | [03] Where the data sits | Their cloud, their regions | Yours | Your cloud account, your region | | [04] The data model | Theirs. You build against their schema | Yours | Yours, in your database | | [05] Raw provider payloads | Varies by vendor | Whatever you keep | Kept in your own bucket when you turn it on | | [06] Provider credentials | Theirs, handled for you | Yours to obtain | Yours, in your own name | | [07] Certifications | Theirs | Yours to earn | Yours, in your certified environment | | [08] Cost shape | Scales with monthly active users | Salaries and infrastructure | Fixed. Flattens as you grow | What stays yours ## The deployment, the data and the schema stay in your account, whoever runs it. ### Sovereignty Patient and member data does not sit in a third party's cloud. ### Residency It stays in the region you chose, provable by pointing at an account. ### Control You decide who reaches the data, under your own credentials. What you build on top of Open Wearables is yours. ### Your own reasons Before a regulator or customer asks, the schema and the data are in your account. Who it is for ## Platforms that are already somebody's processor. The argument on this page only works if somebody outside your company is asking where the data goes. These are the shapes where they are. ### EHR and clinical record platforms Wearable data next to the record you already hold, in the same account and under the same access controls. ### Telemedicine platforms You deliver care on behalf of a controller, so their governance rules reach your vendor choices. ### Health data aggregators You are the integration layer for somebody else, and a hosted aggregator underneath you is a dependency your customers can see. ### NHS-facing and public sector suppliers The driver is the governance review rather than residency. A wearable layer in your own account, under your credentials, is a shorter answer in that review than a faster first call. What you can build ## What teams build on it. Wearable data stops being a separate system and becomes part of the record you already show people. ### A fuller record Last night's sleep and this month's resting heart rate next to the notes, results and history already in your platform, on one timeline rather than in a separate tab. A patient record with a visit note, a result and a dose change, and today's sleep and resting heart rate from Apple Health filed into it. ### Between-visit context What happened in the weeks between appointments, summarised for the clinician who has ten minutes and a question about adherence. A brief before a 10:30 follow-up: sleep down 35 minutes a night and resting heart rate up 4 bpm since the last visit. ### Population views The same metric across a cohort, computed in your own database, so reporting to the organisation you act for does not depend on a vendor's export. A cardiac rehab cohort of 42: resting heart rate against each patient's baseline, three flagged, beside a monthly report. ## The devices your patients and members already wear. Each connected source arrives in the same schema, next to the record you already hold. [Browse integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## Deploy Open Wearables in your own cloud. The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account with the providers connected and validated on real accounts. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=pro) FAQ ## Do you have more questions? ### We are a processor for our customers. Who can reach the data? Your team. It runs in your cloud account, under your credentials, so wearable data does not pass through a vendor tenant. When we work on your system, we do it under a DPA you sign. [The sub-processors page](https://openwearables.io/sub-processors) covers both. ### Our customer's governance board asks who is in the data path. What changes? The wearable layer sits in your own account, under your credentials, rather than in a vendor's tenant. When we work on it, we do it under a DPA you sign. In an NHS-facing or public sector review, that counts for more than a faster first API call. ### Where does the data physically live? In the cloud account and region you choose at deployment. You can point at the account rather than describing a policy, which is usually what a residency question is really asking for. ### Can we run it ourselves, or do you have to? Either. Your team self-hosts it, or we deploy it into your cloud and, under Enterprise, maintain it there under a DPA you sign. In both cases it runs in your account, and the data stays there. ### Do you hold SOC 2 or ISO 27001? No. The deployment runs inside your certified environment, which is how most platforms answer this in their own audit. ### Will you sign a DPA? Yes, whenever our people can reach your deployment: under Pro support, during a Deployment or Integration service, and for as long as Enterprise runs. Where you self-host on Core, there is no processing for us to agree to, because we never touch it. ### What about historical data we already hold? It stays where it is. This is usually a re-integration rather than a data migration: what changes is where new data lands from the switch onwards. Most teams run both in parallel while they validate, then cut over. ### Does it speak FHIR? Not natively today. Open Wearables keeps wearable data in its own standard schema, with the raw provider payloads underneath. It is not a FHIR server, and EHR-ready FHIR output is on the roadmap. In a hospital or telemedicine rollout, we map the readings to FHIR resources (Observation, Device, Provenance and Consent) and write them into your record as part of the rollout. Otherwise the mapping is work your team does against a stable schema. ### Is it running in production anywhere? Yes. Heart Monitor runs Open Wearables in production at around 90,000 monthly active users, and their own engineer did the integration in a week. [The case study](https://openwearables.io/case-study/heart-monitor) has the stack, the timeline and what it took. ### Who maintains Open Wearables? Momentum, a healthcare software development company. The project is MIT licensed and developed in the open, with a public roadmap and public issues, so the source does not depend on us continuing to fund it. --- Source: https://openwearables.io/for/hospitals-telemedicine # Wearable data in the EHR your clinicians already open. Hospitals and telemedicine Open Wearables for hospital groups and telemedicine platforms: readings from patients' own devices written into your record, with the evidence an auditor asks for, running in your own cloud account. [Book a demo](https://openwearables.io/book?tier=clinical) Already running on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo The problem ## Clinicians want wearable data in the record. Today it lands everywhere else. Patients bring readings from their own devices to consultations as screenshots and exports. Getting those readings into the EHR, traceable and in a form an auditor accepts, is a project most hospitals have no team for. ### Readings outside the record Screenshots, exports and separate dashboards that clinicians have to switch to, and that never reach the chart. ### No trace behind a number Which device, which provider, which raw value. Without that, a reading cannot be trusted in a consultation or shown to an auditor. ### Every EHR connection is its own project Mapping, consent and access rules per site, all before the first value lands in the record. ### Patient data has to stay under your control Readings belong in your own cloud account and region, under your credentials, next to the record you already run. The solution ## Wearable data in your patients' app and in your clinical record One platform connects the devices your patients wear, feeds the app they already use, and writes the readings your clinicians need into the record. All of it is included. ### A patient app, ours or yours Patients connect their phone and wearables in the Connect App, joined with a link or a QR code, or inside your own app with our SDK for iOS, Android, Flutter and React Native. [Learn more](https://openwearables.io/platform/connect-app) ### One API across wearables Apple Health, Health Connect, Garmin, Oura, Withings and more arrive in one standard schema, with the source and the raw response kept behind every value. [Learn more](https://openwearables.io/platform/wearable-api) ### Into your EHR Readings written into the patient record your clinicians already open, with the device, source and consent on every value, mapped to the system you run, and a weekly summary per patient. ### A view for clinicians Where the record cannot take writes yet, a clinician view runs beside it: trends, adherence and the readings since the last visit. ### Runs in your cloud, supported by us Your account, region and credentials, with upgrades and provider changes handled by the team behind Open Wearables under a clinical SLA. What it does ## From the patient's wearable to the chart, in three steps. 01 Connect ### Patients connect what they already wear In the Connect App or inside your own app, they pick Apple Health, Health Connect or their wearable account and confirm who receives the data. 02 Your cloud ### Readings land in your own cloud account Every connected source arrives in one schema, in your region, under your credentials, with the device and raw response kept. 03 Your record ### Written into the chart your clinicians open Readings and a weekly summary go into your EHR, with source and consent on every value. The outcome ## Clinicians open the chart and the data is already there. No second dashboard to open: the readings sit where the clinician already works. ### Readings in the patient's chart Sleep, heart rate and activity from the patient's own devices, filed next to notes, results and doses. A patient record with a visit note, a result and a dose change, and today's sleep and resting heart rate from Apple Health filed into it. ### Context before a consultation For a video call or a follow-up: what changed since the last visit, ready when the clinician opens the chart. A brief before a 10:30 follow-up: sleep down 35 minutes a night and resting heart rate up 4 bpm since the last visit. ### Patients monitored at home Hospital at home and post-discharge patients, with the device and sync time beside every value. A heart failure patient's readings, each with its device and sync time, beside fourteen days of weight rising 1.1 kg in three. Who it is for ## Organisations that run their own record. If patient data already lives in a system you control, this is how wearable data joins it. ### Hospital groups Clinicians asking for data between visits, and an EHR that should hold it next to everything else. ### Telemedicine platforms Remote consultations that are better with last week's readings in front of the doctor, inside your own platform. ### Clinic networks with their own record Several sites on one patient system, where a new data source has to fit the access rules you already run. ### Hospital at home services Patients monitored at home whose readings have to reach the ward's record, not a separate dashboard. ## Connect the devices your patients already own. Each connected source arrives in the same schema, so a patient who switches watch or adds a ring changes nothing on your side. [Browse integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## See your patients' wearable data in your own EHR. Book a demo and we will walk you through it on a record like yours, from the patient's app to the chart your clinicians open. [Book a demo](https://openwearables.io/book?tier=clinical) FAQ ## Do you have more questions? ### How do you integrate wearable data into an EHR? Open Wearables collects readings from the patient's devices into your own cloud account, maps them to FHIR resources (Observation, Device, Provenance and Consent) and writes them into your record, as part of the rollout. Where the record cannot accept writes yet, a clinician view runs beside it. ### Does it work for remote patient monitoring? Yes. Patients connect the wearables they already own from home, and readings reach the record with the device and sync time beside every value: hospital at home, follow-up after discharge and chronic care. ### Can we connect it to our telehealth platform? Yes. Your platform adds wearable connections with our SDK, or patients use the Connect App, and the readings since the last visit are in the chart before the video consultation starts. ### Which wearables can patients use? The devices they already own, such as Apple Watch, Garmin, Oura, Withings and Samsung, through Apple Health, Health Connect and each provider's own connection. The [integrations page](https://openwearables.io/integrations) lists the current sources. ### Our record cannot accept writes yet. Can we still start? Yes. A view runs next to the record and reads the patient context from it, and the data moves into the record once it can accept writes. ### Where does patient data live? In your own cloud account or the region you choose, under your credentials. When we work on your system, we do it under a data processing agreement you sign. ### How long does the first site take? Around three months from the first conversation to readings in the record, depending on what your EHR accepts. ### What does EHDS change for us? The European Health Data Space applies from 26 March 2027. From 26 March 2029, EHR systems handling patient summaries must meet its requirements, and the patient summary includes patient-provided data. It is a good reason to plan how wearable data enters your record. --- Source: https://openwearables.io/for/remote-patient-monitoring # The data layer under your monitoring platform. Remote patient monitoring You are building what the clinician looks at. Open Wearables is the wearable data underneath it, running in your own cloud account, so readings from a patient's own device land in your database rather than somebody else's. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=programme) Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo What you get ## What Open Wearables gives a monitoring team. Consumer wearables authorise differently and each returns its own shape. Open Wearables absorbs that inside infrastructure you own, so every reading a clinician acts on has a known origin. ### A reading you can trace. Every value keeps the provider it came from and the raw response it arrived in, so when a clinician asks where a number came from, the answer is in your own database. - Source per reading - Provenance kept ### One schema, next to the chart. Query a patient, not a provider. Activity, sleep, heart rate and body measurements in one shape, joinable with the record your platform already holds. - One schema - Time series - Webhooks ### Raw payloads kept. Original provider responses are retained under the standard schema, so a reading can be re-examined later without going back to the provider or to us. - Raw payloads kept - Re-derivable ### Your region, provably. You choose where it runs when it is deployed. Where patient data sits stops being a clause you negotiate and becomes a fact you can point at. - Your region - eu-central-1 ### Access you control. It runs in your cloud account, under your credentials, so patient data does not reach a vendor tenant. When we work on your system, we do it under a DPA you sign. - Your account - Your credentials ### Costs you can see. Running it costs your own cloud bill, paid to your provider. Deployment and Integration are one-off services, and health scores and the other licensed modules come with Pro. - Your cloud bill - One-off services How it works ## From decision to first reading. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=programme) 01 ### Deploy it. Production and staging in your own cloud account, in the region you choose, defined as infrastructure code in your repository. Either your team stands it up, or you buy a deployment and we do it inside your account. 02 ### Get your own provider credentials. Each source issues developer credentials in your name, and you apply for them directly. Approval timelines vary and this is the slowest step, so it starts on day one. 03 ### Wire it into your platform. Patients authorise through each provider's own consent screen, inside your interface. The mobile SDK handles on-device sources in the background, behind the login your platform already has. 04 ### Query the record. Standardised data lands in your own database, so putting last night's readings in front of a clinician is a query rather than an integration project. [See pricing](https://openwearables.io/pricing) The honest comparison ## Hosted API, in-house, or self-hosted. Where each one wins. If a hosted API fits your situation, use one. | | Hosted SaaS API | Build in-house | Open Wearables | | --- | --- | --- | --- | | [01] First API call | Hours | Months | Minutes, with Docker Compose | | [02] Where patient data sits | Their cloud, their regions | Yours | Your cloud account, your region | | [03] Who can reach the data | The vendor and its sub-processors | Your team | Your team, and us under a DPA you sign when we work on it | | [04] Where a reading came from | Normalised, provenance varies | Whatever you built | Source kept per reading | | [05] Raw provider payloads | Varies by vendor | Whatever you keep | Kept in your own bucket when you turn it on | | [06] Provider credentials | Theirs, handled for you | Yours to obtain | Yours, in your own name | | [07] Certifications | Theirs | Yours to earn | Yours, in your certified environment | | [08] Cost shape | Scales with monthly active users | Salaries and infrastructure | Fixed. Flattens as you grow | What stays yours ## The deployment, the data and the schema stay in your account, whoever runs it. ### Sovereignty Patient data does not sit in a third party's cloud. ### Residency It stays in the region you chose, provable by pointing at an account. ### Control You decide who reaches patient data, under your own credentials. What you build on top of Open Wearables is yours. ### Your own reasons Before a regulator or a health system asks, the record and its provenance sit in your account. Who it is for ## The monitoring products this fits. This page is written for the team building the platform, not for the clinic buying one. These are the shapes where owning the data layer changes the deal. ### Remote monitoring platforms You sell to health systems and insurers, whose security review reaches every vendor behind you. ### Chronic care and disease management Months of continuous data per patient, where the history is the product and a retention window set by somebody else is a risk. ### Digital therapeutics The data feeding an intervention has to be traceable, because the evidence behind the product depends on it. ### Telemedicine platforms You deliver care on behalf of a controller, so their rules on where patient data sits reach your vendor choices. What you can build ## What teams build on it. The data arrives in the background, so what the clinician opens is already current. ### A clinician view Last night's readings next to the history your platform already holds, with the device each value came from shown alongside it. A heart failure patient's readings, each with its device and sync time, beside fourteen days of weight rising 1.1 kg in three. ### Alerts your clinicians define A resting heart rate or a sleep pattern that crosses a threshold your team sets, raised in your own platform rather than a vendor's dashboard. A care team's rule on resting heart rate and overnight HRV, and the alert it raised this morning with both conditions met. ### Adherence at a glance Which enrolled patients are syncing and which have gone quiet, so a care team follows up before a gap becomes a missed week. A week of syncs across a heart failure programme, 36 of 42 syncing, two quiet patients to remind, one reminder sent. ## Connect the devices your patients already own. Each connected source arrives in the same schema, so a patient who switches watch or adds a ring changes nothing in your code. [Browse integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) Care and clinical ## Two paths for care providers, hospitals and telemedicine platforms Care providers, hospitals and telemedicine platforms run the same platform, set up for their patients, their team and their records. ### Care providers and programmes Continuous remote monitoring for care programmes, clinics and senior care: a patient app, a view for your care team and support. [Learn more](https://openwearables.io/for/care-providers) ### Hospitals and telemedicine Wearable data in your patients' app and in your health records, with a source on every value and an SLA per site. [Learn more](https://openwearables.io/for/hospitals-telemedicine) ## Deploy Open Wearables in your own cloud. The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account with the providers connected and validated on real accounts. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=programme) FAQ ## Do you have more questions? ### We run a care programme. How do we start? Open Wearables for care providers covers it, from the first cohort to the whole programme: a patient app, a view for your care team and support. See [Open Wearables for care providers](https://openwearables.io/for/care-providers). ### Is this a remote patient monitoring platform? No. It is the wearable data layer underneath one. If you are a clinic looking for a monitoring service to buy, this is not that. If you are building the platform, this is the part that connects the devices and standardises what comes back. ### Does it work with clinical-grade devices? It connects the consumer wearables patients already own, through each provider's own API or on-device SDK. Regulated devices with their own certified pipelines are a separate question, and the honest answer depends on the device and what its maker exposes. ### Our health system customer's security review asks who can reach patient data. What do we say? Your team. It runs in your cloud account, under your credentials, so patient data does not pass through a vendor tenant. When we work on your system, we do it under a DPA you sign. [The sub-processors page](https://openwearables.io/sub-processors) covers both. ### Where does patient data physically live? In the cloud account and region you choose at deployment. You can point at the account rather than describing a policy. ### Can we use this for a HIPAA workload? The deployment runs on your infrastructure, so access, encryption, retention and audit logging are yours to control and to evidence. A BAA depends on your cloud provider and your scope. ### Can a clinician see where a reading came from? Yes. The provider each value came from is kept with the value, and the original payload is retained underneath, so provenance is a property of the record rather than something reconstructed later. ### Do you hold SOC 2 or ISO 27001? No. The deployment runs inside your certified environment, which is how most platforms answer this in their own audit. ### Does it speak FHIR? Not natively today. Open Wearables keeps wearable data in its own standard schema, with the raw provider payloads underneath. It is not a FHIR server, and EHR-ready FHIR output is on the roadmap. In a hospital or telemedicine rollout, we map the readings to FHIR resources (Observation, Device, Provenance and Consent) and write them into your record as part of the rollout. Otherwise the mapping is work your team does against a stable schema. ### Is it running in production anywhere? Yes, at consumer app scale, with the deployment running in the adopter's own infrastructure. [Customers](https://openwearables.io/case-studies) has the named adopters and what each of them built. ### Who maintains Open Wearables? Momentum, a healthcare software development company. The project is MIT licensed and developed in the open, with a public roadmap and public issues, so the source does not depend on us continuing to fund it. --- Source: https://openwearables.io/for/sports-nutrition # The data layer under your training and nutrition product. Sports and nutrition brands Open Wearables connects the watches and rings your customers already wear, so every plan and recommendation your brand makes starts from how they actually trained, slept and recovered. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=pro) Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo What you get ## What Open Wearables gives a brand team. Wearable data arrives in a different shape from every device. Open Wearables evens that out, so whatever your product recommends, a meal, a supplement or a session, your team can explain it. ### Know when a session lands. A webhook fires when a workout or a night of sleep arrives, so a plan can change the moment a session syncs rather than the next morning. - workout.created - sleep.created ### One schema, any device. Query a customer, not a provider. Whatever watch or ring somebody chose, workouts, sleep and recovery arrive in the same shape. - One schema - Any device - Time series ### Data without the logging. Readings arrive in the background from the device somebody already wears, so personalisation does not depend on anybody remembering to log a session. - Background sync - No manual entry ### History that follows the customer. When somebody swaps a watch for a ring, their history stays in your database and the new device lands in the same schema, so the plan keeps learning from one timeline. - Device switch - One timeline ### Your region, provably. You choose where it runs when it is deployed, which settles most of what a retail or enterprise partner asks about customer data. - Your region - eu-central-1 ### Costs you can see. Running it costs your own cloud bill, paid to your provider. Deployment and Integration are one-off services, and health scores and the other licensed modules come with Pro. - Your cloud bill - One-off services How it works ## From decision to first recommendation. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=pro) 01 ### Deploy it. Production and staging in your own cloud account, in the region you choose, defined as infrastructure code in your repository. Either your team stands it up, or you buy a deployment and we do it inside your account. 02 ### Get your own provider credentials. Each source issues developer credentials in your name, and you apply for them directly. Approval timelines vary and this is the slowest step, so it starts on day one. 03 ### Connect the watch. Customers authorise through each provider's own consent screen, inside your app. The mobile SDK handles on-device sources in the background, behind the login you already have. 04 ### Personalise on real data. Workouts, sleep and recovery land in your own database, so the meal plan, the supplement or the session is computed from what actually happened rather than from a questionnaire somebody filled in once. [See pricing](https://openwearables.io/pricing) The honest comparison ## Hosted API, in-house, or self-hosted. Where each one wins. If a hosted API fits your situation, use one. | | Hosted SaaS API | Build in-house | Open Wearables | | --- | --- | --- | --- | | [01] First API call | Hours | Months | Minutes, with Docker Compose | | [02] The scoring logic | Proprietary, not published | Build and validate it yourself | Designed and validated by our science team, licensed as a module | | [03] Where customer data sits | Their cloud, their regions | Yours | Your cloud account, your region | | [04] The data model | Theirs. You build against their schema | Yours | Yours, in your database | | [05] Raw provider payloads | Varies by vendor | Whatever you keep | Kept in your own bucket when you turn it on | | [06] Provider credentials | Theirs, handled for you | Yours to obtain | Yours, in your own name | | [07] Leaving later | You built on their data model | Not applicable | Already yours | | [08] Cost shape | Scales with monthly active users | Salaries and infrastructure | Fixed. Flattens as you grow | What stays yours ## The deployment, the data and the algorithms stay in your account, whoever runs it. ### Sovereignty Customer data does not sit in a third party's cloud. ### Residency It stays in the region you chose, provable by pointing at an account. ### Control You decide who reaches athlete data, under your own credentials. What you build on top of Open Wearables is yours. ### Your own reasons Before a partner or a regulator asks, the data model and the data sit in your account. Who it is for ## The brands this fits. The common shape is a brand whose product tells somebody what to do next, and whose recommendation is only credible if it reflects what that person actually did. ### Personalised nutrition brands Fuelling and supplement guidance that adapts to training and recovery rather than to a form somebody filled in once. ### Sports nutrition and supplement companies Where the product recommendation is the commercial engine, so the reasoning behind it is worth owning. ### Coaching and training platforms Plans that adjust to how the week actually went, driven by the watch the athlete already owns. ### Performance and recovery apps Where the daily number is the reason somebody opens the app, and it carries your name rather than a vendor's. What you can build ## What teams build on it. Everything below runs on data that arrives on its own, under your brand. ### A fuelling plan that adapts What somebody should eat around a session, adjusted for what the session actually was rather than what was scheduled three weeks ago. A fuelling plan in a phone app, raised after a longer ride than planned. ### A readiness number with your name on it Your own score, built with your own logic on your customers' data, explainable by your team when somebody asks what moved it. A branded score of 81 in a phone app, what moved it, and how it is calculated, with a link to the method. ### A product recommendation that earns trust Suggestions tied to what the data shows, so the commercial side of the product reads as coaching rather than as an upsell. A product suggestion in a phone app, with the week of workouts that prompted it. ## The watches your athletes already train with. Garmin, Strava, Polar and Suunto each have their own integration page, and each connected source arrives in the same schema, whichever one somebody chose. [Browse integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Strava integration](https://openwearables.io/integrations/strava) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Withings integration](https://openwearables.io/integrations/withings) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## Deploy Open Wearables in your own cloud. The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account with the providers connected and validated on real accounts. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=pro) FAQ ## Do you have more questions? ### We sell nutrition, not software. Is this for us? If your product gives personalised advice, then the data behind that advice is part of what you sell. This is the layer that collects it. The build itself is something your team does, or something we do with you, rather than a product you switch on. ### Does it track food and calories? No. Open Wearables brings in what the wearable measures: workouts, sleep, heart rate, recovery and body measurements. What somebody eats comes from your own logging or your nutrition database, and the value is in combining the two inside your database. ### Which devices do athletes actually use? Garmin, Strava, Polar and Suunto are where most endurance and training data lives, and each has its own integration page. Whatever somebody chose, the metric arrives in the same shape. ### Can we build our own score? Yes. Your team can build its own score with its own logic on the same data, and custom scores for your customers are built with our science team. Our health scores are part of Pro, designed and validated by that team. ### Do we need our own provider credentials? Yes, and they stay in your name, so the data relationship is between you and each provider. Approval is slow with some of them, so that work starts on day one. ### Where does customer data live? In the cloud account and region you choose at deployment, which is usually the shortest answer to a retail or enterprise partner asking the same question. ### What if a customer switches from a watch to a ring? Their history stays in your database and the new device lands in the same schema, so the timeline continues rather than restarting. ### Is it running in production anywhere? Yes. Heart Monitor runs Open Wearables in production at around 90,000 monthly active users, and their own engineer did the integration in a week. [The case study](https://openwearables.io/case-study/heart-monitor) has the stack and the timeline. ### Who maintains Open Wearables? Momentum, a healthcare software development company. The project is MIT licensed and developed in the open, with a public roadmap and public issues, so the source does not depend on us continuing to fund it. --- Source: https://openwearables.io/integrations # Every integration, one schema. Integrations Open Wearables connects the wearables and health platforms your users already own and returns them in one schema. Below is everything it supports today, grouped by how the data reaches you. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) Two delivery models ## Cloud or on-device. A cloud provider is a server-to-server connection you can finish without touching your app. An on-device platform keeps its data on the phone, so reading it means shipping a mobile SDK in your app. ### From the cloud Your deployment authorises against the provider's API and pulls the data, or receives it over webhooks. No mobile work, and the credentials are issued to you. [How connections work](https://openwearables.io/integrations#how-it-works) ### From the device Apple Health, Health Connect and Samsung Health have no cloud API. The mobile SDK reads the store on the phone with the user's permission and syncs to your deployment in the background. [Mobile SDKs](https://openwearables.io/platform/mobile-sdks) All integrations ## What you can connect today. Each one links to its own page, with the data it returns and what the setup involves. [Provider coverage matrix](https://openwearables.io/docs/providers/coverage) ### Connect from the cloud - [Garmin integration](https://openwearables.io/integrations/garmin) Garmin - [Whoop integration](https://openwearables.io/integrations/whoop) Whoop - [Oura integration](https://openwearables.io/integrations/oura) Oura - [Polar integration](https://openwearables.io/integrations/polar) Polar - [Suunto integration](https://openwearables.io/integrations/suunto) Suunto - [Withings integration](https://openwearables.io/integrations/withings) Withings - [Strava integration](https://openwearables.io/integrations/strava) Strava - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) Ultrahuman - [SensorBio integration](https://openwearables.io/integrations/sensorbio) SensorBio - [Google Health API integration](https://openwearables.io/integrations/google-health) Google Health API - [Fitbit integration](https://openwearables.io/integrations/fitbit) Fitbit ### Connect on-device - [Apple Health integration](https://openwearables.io/integrations/apple-health) Apple Health - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) Google Health Connect - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) Samsung Health - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) How it works ## What a connection actually involves. Every provider works differently underneath, and Open Wearables absorbs that so your application code does not have to. 01 ### Credentials in your name. Each cloud provider issues developer credentials to your organisation, and you apply directly. Approval takes from a day to several weeks, so this is the step to start first. On-device platforms need no application. 02 ### The user authorises. Cloud providers show their own consent screen, and on-device platforms ask in the operating system's dialog. Either way the flow sits in your interface, not a vendor's widget. 03 ### Tokens stay alive. Access tokens refresh before they expire, and concurrent syncs are coordinated so one user's refresh cannot race itself. A connection keeps working until the user revokes it. 04 ### Data arrives, and keeps arriving. Where a provider supports webhooks, your deployment is notified and fetches the changed window. Where it does not, a scheduled sync pulls on an interval. On-device platforms push from the app in the background. 05 ### You query the user, not the provider. Everything lands in one schema in your own database, so a watch, a ring and a scale come back in one shape, and adding a source later does not change the call. The same guarantees ## What holds across every integration. [Wearable API](https://openwearables.io/platform/wearable-api) ### One schema. Activity, sleep, heart rate, workouts and body measurements arrive in one shape regardless of source, joinable against the rest of your product. - One schema - Any provider ### Raw payloads kept. Original provider responses are stored underneath the standard schema, so a metric you invent next year can be computed against history you already hold. - Raw payloads kept - Re-derivable ### Your cloud, your credentials. Every integration runs inside your own deployment, with provider apps registered in your name. No copy lands in a vendor tenant. - Your account - Your credentials ### Provider changes handled. When a provider changes its API, the fix ships in a release you pull, rather than landing in your sprint. - Fixed in a release you pull ## Not seeing what you need? Open an issue and tell us what you are building. Meanwhile, many wearables write to Apple Health through their own app, which makes it a route to hardware without a direct connection, and the source is yours to extend under an MIT licence. [Request a provider](https://github.com/the-momentum/open-wearables/issues/new?template=feature.md) [Book a demo](https://openwearables.io/book) FAQ ## Do you have more questions? ### Do we need our own credentials for each provider? For cloud providers, yes. Each one issues developer credentials to your organisation and you apply directly, which keeps the data relationship between you and them. On-device platforms need no application: access is a permission the user grants on their own device. ### How long does getting those credentials take? From a day to several weeks, depending on the provider. It is the longest part of most cloud integrations and the usual reason a launch slips, so a deployment starts that work on day one and runs everything else in parallel. ### Can one user connect several providers at once? Yes, and it is the normal case. You query a user rather than a provider, so somebody with a watch, a ring and a scale returns in one shape. Where two sources report the same metric, read-time deduplication picks one by source priority rather than summing them. ### Which providers need a mobile app? Apple Health, Health Connect and Samsung Health, because their data never leaves the device on its own. Everything else is a server-to-server connection with no mobile work. If you need Android data without shipping an app, the Google Health API reaches some of it through the cloud. ### Does the schema really stay the same across providers? The shape does. Your code queries one model regardless of source. What differs is which fields a given provider populates, because a ring does not report cycling power and a scale does not report sleep. The [coverage matrix](https://openwearables.io/docs/providers/coverage) in the docs is field by field. ### What happens when a provider changes their API? The fix ships in a release, and you pick it up when you upgrade. That is the part teams underestimate when they build in-house: provider drift is continuous work, and here it is not yours to track. ### Is this production ready? Yes. It runs in production at consumer app scale, and the providers listed here are live rather than roadmap. Anything not yet implemented is marked in the coverage matrix rather than described as available. ### Can we add a provider ourselves? Yes. The source is MIT licensed and the architecture is built for it: each provider is a strategy class with a declared capability set and coverage map. [The guide in the docs](https://openwearables.io/docs/dev-guides/how-to-add-new-provider) walks through adding one. --- Source: https://openwearables.io/live-vs-roadmap # What runs today, and what does not. Live versus roadmap Software companies describe what they are building as though it already exists. This is the list of what actually runs, so you can check the rest of the site against it. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) Live ## The whole platform, as it runs today. Everything here is in the project you clone, from the first connection to the developer portal, except what is marked Pro: those are licensed modules that run in your own deployment. Anything not listed is not built yet. 01 ### Connect Every source your users already wear. - [Cloud providers and more](https://openwearables.io/integrations) - [Mobile SDKs](https://openwearables.io/platform/mobile-sdks) - [Connect App](https://openwearables.io/platform/connect-app) - [Apple Health XML import](https://openwearables.io/docs/api-reference/guides/apple-xml-import) - [Historical backfill](https://openwearables.io/docs/providers/historical-data) 02 ### Store One model, in your own cloud. - [Unified data model](https://openwearables.io/platform/wearable-api) - Daily summaries - [Raw payloads](https://openwearables.io/platform/raw-data) - Source priorities - Archiving and retention - [Coverage matrix](https://openwearables.io/docs/providers/coverage) 03 ### Compute Scores and answers, inside your deployment. - [Health scores Pro](https://openwearables.io/platform/health-scores) - [Health agent Pro](https://openwearables.io/platform/ai-insights) - Provider scores, passed through - [MCP server](https://openwearables.io/platform/mcp-server) 04 ### Deliver Into your product, on your schema. - [REST API](https://openwearables.io/platform/wearable-api) - [Outgoing webhooks](https://openwearables.io/webhooks) - [Live sync status](https://openwearables.io/docs/api-reference/guides/sync-status-stream) - Write-only mobile tokens 05 ### Operate A deployment you can see into. - [Developer portal](https://openwearables.io/docs/developer-portal) - Team and API keys - [Seed data generator](https://openwearables.io/docs/developer-portal/settings/seed-data-generator) - [Docker or Railway](https://openwearables.io/docs/deployment/docker) - [Add your own provider](https://openwearables.io/docs/dev-guides/how-to-add-new-provider) - [MIT licensed source](https://github.com/the-momentum/open-wearables) [See what's coming next](https://openwearables.io/live-vs-roadmap#roadmap) Roadmap ## What we are building next The modules planned for Open Wearables, grouped by what each one adds. Everything here is planned, not live, and has no date until it ships. ### Interoperability Data your clinical partners' systems can read. EHR-ready output In Core Planned The data model written out in the form record systems read (observations, devices, provenance and consent), so an EHR can take it in as is. ### Compliance The controls your auditors ask for. Data deletion and retention In Core Planned A user's data removed on request, and kept only as long as your policy says. Auditable access In Core Planned A record of who read which user's data, and when. ### Data sources New sources in the same model as the wearables. CGM Custom work Planned Add continuous glucose to the same user profile and timeline. Lab results Custom work Planned Show blood work next to wearable data in one user profile. Medical-grade devices In Pro Planned Bring certified medical devices into the same data model as consumer wearables. Raw signal processing Custom work Planned Turn raw sensor signals into metrics of your own, for teams building hardware. ### Infrastructure Faster data where your product needs it. Real-time data Custom work Planned React to heart rate and activity as they happen, not hours later. Why it runs in your cloud ## The layer has to be yours before what you build on it can be A hosted API keeps the data, and every score computed from it, in a vendor's account. Running the layer yourself keeps it where HIPAA, GDPR and your own policy say it belongs. ### Sovereignty Your regulator, your board or your own policy says health data does not sit in a third party's cloud. ### Residency The data has to stay in a country or region you choose, and you have to prove where it is. ### Control You run the deployment under your own credentials and decide who gets access. What you build on top of Open Wearables is yours. ### Your own reasons No regulator forcing it and no security review coming. You want the data in your own account anyway. ## The providers you can connect today. Cloud providers connect server to server, and the phone's health stores through the SDKs. Every one lands in the same schema. [Browse all integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## If something missing here decides your timeline, ask Where a thing sits for your case is a better conversation than a guess at a date. Bring the one you need and we will tell you honestly where it stands. [Book a demo](https://openwearables.io/book) FAQ ## Common questions. ### How do you decide what counts as live? It runs in Open Wearables today and you can use it. Something planned, in progress or shown once in a demo is not on this page. ### Where do we see what is coming next? In [the roadmap](https://openwearables.io/live-vs-roadmap#roadmap) on this page, grouped by what each module adds, with no dates. For technical detail and sequencing, [the roadmap in the docs](https://openwearables.io/docs/roadmap) is kept current by the product team. ### Which providers can we connect? The [integrations page](https://openwearables.io/integrations) lists every provider, and [the coverage matrix](https://openwearables.io/docs/providers/coverage) shows what each one returns. ### Is all of it free? Not all of it. Running the platform yourself costs your own cloud bill, and the Pro modules, health scores and the health agent among them, are licensed. The plans and the work Momentum does around them are on [the pricing page](https://openwearables.io/pricing). ### How do we keep up with what changes? Each release is published on [GitHub](https://github.com/the-momentum/open-wearables/releases), and this page is updated when something new starts to run. ### We need something that is not live yet. Can we get it sooner? Sometimes. Momentum builds custom features on top of the platform. Tell us what you need and where it sits for your timeline, and we will say honestly whether that is realistic. ### Can we add a provider that is not supported? Yes. The code is in your repository, and [the guide in the docs](https://openwearables.io/docs/dev-guides/how-to-add-new-provider) walks through adding one. --- Source: https://openwearables.io/migrate # Move off your SaaS aggregator, onto your own keys. Garmin policy change Affected by the Garmin policy change? Open Wearables runs the connection in your own cloud, with no shared keys and no one in between. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo Who this is for ## Your Garmin data runs through someone else's key. When a SaaS aggregator connects many companies to Garmin through one registration, a policy change upstream reaches your users before it reaches you. These are the teams we hear from. ### Your aggregator asked you to bring your own keys Garmin's developer agreement does not allow passing keys or data to a third party without written permission. If you now hold your own credentials, the aggregator is one more party between you and data you can hold yourself. ### Your users' Garmin data stopped arriving With a shared registration, the connection your users depend on sits in someone else's agreement. With your own app, the relationship with Garmin is yours, and so is the fix. ### It is not only Garmin Strava's API agreement, in force since June, says a developer may not share its API token with any third party. Device makers are moving the same way: each company holds its own key. ### Your customers ask who sits in the middle Enterprise customers and security reviews ask where wearable data flows and who can reach it. With no aggregator in the path, the answer is your own cloud account. What a migration means ## Usually a re-integration rather than a data migration. Your historical data stays where it is. What changes is where new data lands from the switch onwards: your own database, in your own account, under your own keys. ### What changes Garmin and your other providers connect to your own deployment instead of the aggregator's. New data lands in your own database, on one standard schema. - Your cloud - Your keys - One schema ### What stays the same Your users, their devices and your product. Most teams keep the aggregator running while the new path is validated, then cut over. - Parallel run - Cut over when ready ### What you gain Provider apps registered in your name, no shared keys, raw payloads kept before standardisation, and source code you can read line by line. - No shared keys - Raw payloads - MIT license ### What to plan for Each user authorises your app once, because their current connection belongs to the aggregator's app. Plan it as a short step in your product, not as a technical task. - One-time reconnect - Your consent screen How it runs ## From a SaaS aggregator to your own keys, in five steps. Each step is something you can see working before the next one starts. Your aggregator keeps running until the last one. [See the platform](https://openwearables.io/platform) 01 ### Start with an architecture audit. We look at the providers you use through the aggregator today, how your product reads the data and what has to keep working on day one. You leave with a written plan for your setup. 02 ### Register your own Garmin app, and your other providers. Apply to the Garmin Connect Developer Program under your organisation's name, and to each other provider you use. Open Wearables does not replace Garmin's approval; the relationship is between you and Garmin. If you already hold your own keys, the slow part is behind you. 03 ### Deploy next to the aggregator. Production and staging in your own cloud account and region, defined as infrastructure code in your repository. Either your team stands it up, or we do. 04 ### Validate on real accounts. Connect test accounts and compare what comes back with what each provider's own app shows. Provider quirks surface here rather than after launch. 05 ### Move users across, then switch the aggregator off. Users reconnect through your own consent screen, in batches you control. Where a provider offers history, it is requested as each user connects. When the new path is proven, the aggregator goes. What stays yours ## The deployment, the data and the keys stay in your account, whoever runs it ### Sovereignty Health data does not pass through an aggregator's cloud. ### Residency Your users' data stays in the region you chose, provable by pointing at an account. ### Control It runs in your cloud account, under your credentials. When we work on your system, we do it under a DPA you sign. ### Your own reasons If you stop working with us, the deployment and the data stay where they are. What you build on top of Open Wearables is yours. Two ways to move ## Run the move yourself, or have us stand it up in your cloud. Same code, same cloud account, either way. What changes is how quickly it is live and who carries the work. ### Self-host it The full source under an MIT license, Docker Compose to start and infrastructure as code for production. Your engineers own the plan and the pace. [Read the source](https://github.com/the-momentum/open-wearables) ### We stand it up in your cloud Same architecture, same account, your keys. We deploy it, connect your providers, validate them on real accounts and stay on while your users move off the aggregator. [Book a demo](https://openwearables.io/book) ## Connect the devices your users already own. The coverage matrix lists what each source returns, so you can check it against the providers you use through your aggregator today rather than against a total. [Browse integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## Plan your move off the aggregator. Tell us which providers you run through your aggregator today and how your product reads the data. We will say honestly what moving takes, and what it does not. [Book a demo](https://openwearables.io/book) [Get started](https://openwearables.io/docs/quickstart) FAQ ## Common questions. ### We were affected by the Garmin policy change. What do we do first? Apply for your own Garmin app under your organisation's name, because approval is the slowest step and nothing else depends on it. In parallel, stand up Open Wearables in your own cloud and validate your other providers. When your Garmin app is approved, add the keys and move users across. ### Does Open Wearables give us Garmin access? No. You apply to the Garmin Connect Developer Program yourself, and the relationship is between your organisation and Garmin. Open Wearables is the software that runs your approved connection alongside your other providers, in your own cloud account. ### What does "no shared keys" mean? Every provider app in your deployment is registered to your organisation, and its keys live only in your deployment. Nobody else's users run through them, and you do not run through anybody else's. ### Is moving off an aggregator a data migration? Usually a re-integration rather than a data migration. Your historical data stays where it is, and what changes is where new data lands from the switch onwards. Most teams run both in parallel while they validate, then cut over. It starts with an architecture audit. ### Do our users have to reconnect their devices? Yes, once. A connection belongs to the app that requested it, so moving from the aggregator's apps to apps registered in your name means each user authorises again. Treat it as a short step in your product with a clear reason. ### What happens to the history we already have? It stays where it is today. From the switch onwards, new data lands in your own database. Where a provider offers history, it is requested when each user connects to your app, and a full Apple Health export can be imported directly for users who want years of it. ### We already have our own Garmin keys. What changes? Then the slow part is behind you. Bring the client ID and secret, point the deployment at your callback, and the connection flow works from there. ### How long does a migration take? It depends on the providers you use and how long their credential approval takes, which is usually the slowest part. The architecture audit ends with a timeline for your setup rather than a general estimate. ### Who supports us during and after the move? Community support is on Discord and GitHub. Momentum, the team that builds Open Wearables, runs the Deployment and Integration services and Enterprise support with an SLA, a named on-call and tested upgrades. When we work on your system, we do it under a DPA you sign. ### What if we stop working with you later? Nothing stops. The platform sits in your cloud account, under your keys, built from infrastructure code in your repository, under an MIT license. ### Is an aggregator ever the better choice? Yes. A hosted service is faster to start and someone else runs it. If speed matters more than control and nobody is asking where the data sits, take the faster route. [Compare alternatives](https://openwearables.io/compare). --- Source: https://openwearables.io/platform # One platform for the wearable data your product runs on. Platform Open Wearables collects data from the devices your users own, keeps it in one schema in your own cloud, and gives you what to build on top of it. Below is every part, with what ships today and what is on the roadmap. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=pro) In Core ## What every deployment runs. Free and self-hosted, and each part has its own page. [See pricing](https://openwearables.io/pricing#core) ### Wearable API One schema across cloud providers and on-device stores, delivered over a REST API and webhooks. [Learn more](https://openwearables.io/platform/wearable-api) ### Mobile SDKs Read Apple Health, Health Connect and Samsung Health from inside your app, synced in the background. [Learn more](https://openwearables.io/platform/mobile-sdks) ### Raw data The provider's original payload kept under the schema, in a bucket you own. [Learn more](https://openwearables.io/platform/raw-data) ### MCP server Point Claude Desktop or Cursor at your deployment and ask about your users in plain language. [Learn more](https://openwearables.io/platform/mcp-server) ### Connect App A ready iOS and Android app, under your brand on request, that brings Apple Health, Health Connect and wearable data into your deployment. Free on every plan under the Open Wearables name. [Connect App](https://openwearables.io/platform/connect-app) Part of Pro ## What Pro adds to your deployment. Licensed modules and add-ons, running inside your own deployment. [Book a demo](https://openwearables.io/book?tier=pro) [See pricing](https://openwearables.io/pricing#pro) ### Health scores Sleep, recovery and activity scores from our science team, on one method. [Learn more](https://openwearables.io/platform/health-scores) ### AI insights An AI health coach on your users' own data. [Learn more](https://openwearables.io/platform/ai-insights) ### Medical-grade integrations A private catalogue of integrations with certified medical devices, added to your deployment as extensions and kept up to date by us. [See pricing](https://openwearables.io/pricing#modules) ### Observability Sync health per provider and per user across your deployment, so a broken connection is caught before your users notice. [See pricing](https://openwearables.io/pricing#modules) How it fits together ## From the device to the answer. 01 ### Collect Cloud providers connect server to server, and the mobile SDKs read the stores that live on the phone. Every source ends up in the same deployment. 02 ### Store Everything lands in one schema in your own database, with the original payload kept underneath, so a metric you invent later can be computed against history you already hold. 03 ### Compute Health scores from our science team, computed inside your deployment and validated before release. 04 ### Use Your product reads it over the REST API, reacts to webhooks, or asks questions through the MCP server. The same guarantees ## What holds across the whole platform. ### Your cloud, your region. Every part runs inside your own deployment, under your credentials, so health data does not reach a vendor tenant. - Your account - Your region ### One schema. A watch, a ring and a phone come back in one shape, whichever part of the platform reads them. - One schema - Any source ### Costs you can see. Running it costs your own cloud bill, paid to your provider. Deployment and Integration are one-off services, and health scores and the other licensed modules come with Pro. - Your cloud bill - One-off services ### No dependency on us. MIT licence, full source, public roadmap and public issues, plus community support on Discord. - MIT license - Full source - Discord ## Deploy Open Wearables in your own cloud The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=pro) [See pricing](https://openwearables.io/pricing) FAQ ## Do you have more questions? ### Do we have to use every part? No. Most teams start with the Wearable API and add the rest as the product needs it: the mobile SDKs when on-device data matters, the MCP server when someone wants to ask the data questions. Each part works on the same deployment and the same schema, so adding one later does not change what you already built. ### Where can we see what is coming next? On the [public roadmap](https://openwearables.io/docs/roadmap) in the docs, which lists what is being built next. Anything on this page that is not live yet is marked as on the roadmap. ### Can we add our own sources or scores? Yes. The code runs in your own deployment, so you can add a provider by following [the guide in the docs](https://openwearables.io/docs/dev-guides/how-to-add-new-provider), or compute your own scores on the raw data you already hold. ### Where does it run? In a cloud account you control, in the region you choose. Locally it starts with Docker Compose in a few minutes. ### Can Momentum run it for us? Yes. If you would rather not run it yourself, Momentum can set it up and maintain it inside your own account, so the data and the deployment stay yours. ### Do we need a mobile app? Only for Apple Health, Health Connect and Samsung Health, because their data never leaves the phone on its own. Cloud providers connect server to server with no mobile work. For teams without an app, the [Connect App](https://openwearables.io/platform/connect-app) is that app: people join from an invitation and the data lands in your deployment. --- Source: https://openwearables.io/platform/ai-insights # Build your intelligence layer on wearable data Health agent · Part of Pro Open Wearables gives your team a ready AI agent for wearable health data. It runs as a service in your own deployment, works with the LLM provider you connect, and becomes the intelligence layer your product competes on once you add your voice, tools and data. [Book a demo](https://openwearables.io/book?tier=pro) [See pricing](https://openwearables.io/pricing#pro) Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo Overview ## One agent module for teams building AI features on wearable data Everything a product team needs between the data in Open Wearables and an AI feature in their app, delivered as one module that runs in your deployment. These are the parts you would otherwise build yourself. 01 ### Tools for wearable data. Ready tools query sleep, activity, heart and workout data through the Open Wearables schema, for the user and time range a question needs, so the model does not get the whole history in its prompt. 02 ### A prompt profile you can edit. The prompt is split into blocks. Change the tone, your platform's context and how the data is analysed, while the instructions for using the tools stay as they are. 03 ### Your own tools and data sources. Register tools that read your labs, nutrition logs, training plans or product catalogue, and the agent uses them next to wearable data. 04 ### One core for every AI feature. Chat, scheduled summaries, post-workout reviews and summaries for the screen in view are all requests to the same agent, so you build the logic once. 05 ### Evaluation built in. A question set and judges score the agent's answers. Run it after you change the model, the prompt or a tool, and compare the runs side by side. What you get ## Why teams start here instead of from scratch ### A working baseline from day one The agent answers from the first request, and you tune it from there instead of assembling it from parts. - Ready baseline - Tunable ### Any LLM provider Connect the provider your team already uses. Switching models is a setting, and the evaluation shows whether the new one holds up. - Model-agnostic ### Runs in your deployment A separate service beside Open Wearables, in your own cloud, reading the data where it already is. - Self-hosted - Beside Open Wearables ### What you build on it is yours Your prompts, tools and question sets are your product's logic, and they live in your deployment. - Your deployment How it works ## From your deployment to an AI feature in your app 01 ### Run it beside your deployment The agent reads the wearable data your Open Wearables deployment already holds. There is nothing new to collect. 02 ### Connect your model and set the scope Choose the LLM provider, then decide what the agent talks about and how it sounds. 03 ### Add what only your product has Register your own tools and data sources. They are the part of the agent that is specific to your app. 04 ### Measure, then ship Test the answers on your own questions, then call the agent from your app with the screen or event in view. [Book a demo](https://openwearables.io/book?tier=pro) What you can build ## Insight that fits the moment Each answer is shaped by where the user is and what just happened: the screen in view, the time of day, a workout that just synced. It ends with a step the user can take. ### A morning summary with a plan for the day Last night against that person's own recent nights, with a suggestion for today's training and a next question ready to tap. ### Insight for the screen in view Your app passes the screen and the agent stays on it: sleep on the sleep screen, training on the training screen, each with one thing to try. ### A review when a workout syncs The finished session against the user's recent ones, with what to change next time. ### Answers that end in a next step A question in chat gets an answer from the user's own readings and a step they can take, such as moving tonight's session. Who is it for ## Who builds on the AI agent ### Digital health products An AI feature that is yours, with its logic, voice and tools under your control. [Learn more](https://openwearables.io/for/digital-health) ### Health data platforms An agent you can offer the teams on your platform, running in the deployment you already operate. [Learn more](https://openwearables.io/for/health-data-platforms) ### Remote patient monitoring Summaries of each patient's trends for the care team, inside the scope you define. [Learn more](https://openwearables.io/for/remote-patient-monitoring) ### Clinical and research builders A setup you can test and measure question by question before it reaches anyone. [Learn more](https://openwearables.io/for/clinical-research) ### Care providers Guidance for members on data that stays in the deployment you promised it would. [Learn more](https://openwearables.io/for/care-providers) ### Hospitals and telemedicine A coach in your brand's voice, connected to your own training plans or product catalogue. [Learn more](https://openwearables.io/for/hospitals-telemedicine) ## One agent, whatever your users wear Every source arrives in the same schema before the agent reads it, so an answer about last week's training works the same way whether the data came from a watch, a ring or a phone. You build one agent, and it answers about a person rather than a device. [Browse integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## Add the health agent to your product The health agent is part of Pro, running inside your own deployment. [Book a demo](https://openwearables.io/book?tier=pro) [See pricing](https://openwearables.io/pricing#pro) FAQ ## Do you have more questions? ### Is the AI agent available today? It is a licensed module; request access and we set it up with you. If you want an assistant querying your data now, the [MCP server](https://openwearables.io/platform/mcp-server) ships today. ### How do I build an AI health coach on wearable data? Start from a deployment that holds your users' data, then put an agent in front of it that knows how to query that data. The AI agent gives you that agent ready, and you add your voice, scope and tools. ### Can I use my own LLM? Yes. The agent works with the LLM provider you connect, and changing the model is a setting. ### Does our users' data leave our deployment? The agent runs in your deployment and reads your data there. The only data that leaves is what goes to the model provider you connect. ### How is this different from an agent framework like LangChain? A framework gives you parts to assemble. The AI agent is assembled already, with tools for wearable data, a working baseline and an evaluation setup, and you configure it rather than build it. ### How is this different from pasting our data into ChatGPT? A general chat model sees whatever you paste and has to guess how to read it. The agent fetches the right slice of each user's data through tools built for it, inside the scope you set, and you can measure its answers. ### How do I evaluate a health AI agent? Write the questions your users ask with the answers you expect, run the agent on them, and score the answers. The agent ships with that setup, so you repeat it after every change of model, prompt or tool. ### How is this different from the MCP server? The [MCP server](https://openwearables.io/platform/mcp-server) lets your team's own assistant query your data. The AI agent is what you put in front of your users, inside your app. ### Does it work with health scores? Yes. It reads your custom health scores next to the raw signals. ### Will it give medical advice? It follows the scope you set. You decide what is out of bounds and test it on your own questions before anything reaches a user. ### Can it connect to data that is not from wearables? Yes, through tools you register. If you need tools for your own systems, such as labs, nutrition logs or EHRs, our team can build them with you. --- Source: https://openwearables.io/platform/connect-app # Your own app for Apple Health and wearables, without building one Connect App A ready iOS and Android app for care programmes, remote monitoring and research teams with no app of their own. People join from an invitation, connect their phone and wearables once, and every reading lands in the deployment you run, under your name in the stores. [Book a demo](https://openwearables.io/book?tier=programme) [See pricing](https://openwearables.io/pricing#modules) Trusted by teams building on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo Why it exists ## Apple Health and Health Connect have no web API, so the data needs an app on the phone For a team on a web portal or a care dashboard, that usually means a mobile team, store reviews and SDKs to keep current. Connect App is that app, already built and maintained by the team behind Open Wearables. ### On the phone People allow access once, on the phone's own permission sheet, and the app keeps syncing in the background. ### On your deployment Phone and wearable data land in one schema, in the cloud account you run. ### In your backend Webhooks and the REST API deliver it like every other source. How it works ## How the Apple Health integration works 01 Invite ### Each person gets a link or a QR code Send it by email or text, or hand it over at the first visit. One tap opens the app on your programme, with nothing to sign up for. 02 Confirm ### They see your name and choose what to share Your organisation comes first, then the phone's own permission sheet. Nothing is shared until they agree. 03 Connect ### Their phone and wearables, connected once Apple Health or Health Connect, plus any wearable accounts you enabled. After that, the app syncs in the background and they can forget about it. 04 Receive ### Readings arrive in your backend Each new reading reaches your webhook as it lands, and the REST API holds the full history for every person. What you get ## A patient app without a mobile team ### Your brand in the stores Your name, icon and colours on your own App Store and Google Play accounts, so people install an app from an organisation they know. - White-label - Your store accounts ### Joining without accounts People join from your invitation, with no sign-up form and no password to remember. Each invitation works once. - Link or QR - Single-use ### Provider passwords stay off the phone People sign in to Garmin or Oura on the provider's own page, and your deployment keeps the access tokens. - Provider sign-in - Tokens on your deployment ### One health data API Phone and wearable readings share one schema, so your backend handles a person rather than a device. - Webhooks - REST API Who it is for ## Teams that need phone health data and have no app to collect it Already have a mobile app? Add our Flutter, React Native, iOS or Android SDK to it instead. [Mobile SDKs](https://openwearables.io/platform/mobile-sdks) [For hospitals](https://openwearables.io/for/hospitals-telemedicine) ### Remote patient monitoring Readings from home for clinicians, in an app that carries the provider's name. [Learn more](https://openwearables.io/for/remote-patient-monitoring) ### Clinical research Participants enrolled with a QR code at the first visit, on infrastructure the sponsor has approved. [Learn more](https://openwearables.io/for/clinical-research) ### Employer wellness Members bring the devices they already own into a programme app in your colours. [Learn more](https://openwearables.io/for/employer-wellness) ### Care providers Care programmes that need their patients' phone and wearable data between visits, with no app of their own. [Learn more](https://openwearables.io/for/care-providers) Plans ## Start free, then put it under your name One person counts once, however many devices they link. [01] On every plan ### Connect App The app under the Open Wearables name, on every plan. - Up to 5 users on Core, no limit on Pro - Every source your instance enables - Same instance when you move to your brand [Book a demo](https://openwearables.io/book) [02] Your programme, your brand ### Connect App under your brand The same app published under your brand, $5,000 per platform. - Your App Store and Google Play accounts - Your name, icon and colours - No user limit [Book a demo](https://openwearables.io/book?tier=programme) How it compares ## Where the data goes, and whose name is on the app Two questions decide most choices here: where health data ends up, and what it takes to put an app in front of people. | | A hosted extraction app | Build your own app | Connect App | | --- | --- | --- | --- | | [01] Where the data is stored | In the vendor's cloud | In your cloud | In your own Open Wearables deployment | | [02] Name people see | The vendor's | Yours | Yours, on your own store accounts | | [03] What it takes | An account and the vendor's terms | A mobile team, store reviews and SDK upkeep | Open Wearables running, and the app set up with us | | [04] Choose this when | Speed matters more than where the data lives | The app is your product and the mobile team exists | You need phone data under your name without hiring for mobile | ## One app, whatever people wear The phone's health store plus the providers you switch on. Each lands in the same schema, so a reading looks the same whichever device took it. [Browse integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## Put Connect App under your name We set up an instance with you and walk through the full path: invitation, consent, first sync and the data arriving in your backend. [Book a demo](https://openwearables.io/book?tier=programme) [See pricing](https://openwearables.io/pricing#modules) FAQ ## What teams ask about the Connect App ### Does Apple Health have an API? Not on the web. HealthKit is an on-device framework: only an app on the iPhone, with the person's permission, can read it. Connect App is that app, and it sends the readings to your deployment. The [Apple Health integration](https://openwearables.io/integrations/apple-health) page covers the data types. ### What is Health Connect? Android's on-device store for health and fitness data. Apps and wearables write to it, and another app reads from it with the person's permission. Like Apple Health, it has no web API, so Connect App reads it on the phone. ### Can a web app access Apple Health data? Not directly, because the data never leaves the phone on its own. A web-only product needs an app on the phone to read it and pass it on, which is the job Connect App does. ### Can we publish it under our own brand? Yes. The Connect App under your brand carries your name, icon and colours on your own App Store and Google Play accounts, with no user limit. It costs $5,000 per platform, iOS or Android. ### Do people need to create an account? No. They open your invitation, see your organisation's name, pick their sources and tap Connect. ### Where does the data go? Straight from the phone or the provider to your Open Wearables deployment, in your cloud account and the region you choose. ### Is there a free version? Yes. The standard app, under the Open Wearables name, is free on Core for up to 5 users, and has no user limit on Pro. Teams often start with it before launching under their own brand. ### We already have a mobile app. Do we need this? No. Add our [mobile SDKs](https://openwearables.io/platform/mobile-sdks) to the app you have. ### What does registering our instance share? Registration is only needed for the app from the App Store and Google Play. It shares a random instance ID, a public key and, if you add one, an admin email. Never health data, user names or your server address. It is opt-in and you can withdraw it at any time. --- Source: https://openwearables.io/platform/health-scores # Health scores your users trust, without hiring a science team Health scores · Part of Pro Sleep, recovery and activity scores designed by our health scientists and computed inside your own Open Wearables deployment. A licensed module, validated by our science team before each release, with what every score measures written down so your team can explain any number to whoever asks. [Book a demo](https://openwearables.io/book?tier=pro) [See pricing](https://openwearables.io/pricing#pro) Trusted by teams building on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo What you get ## Health scores built and validated by our science team Build a morning check-in, a recovery view or a coaching plan on Open Wearables Health Scores. Each score is ready to ship and validated before release. [Book a demo](https://openwearables.io/book?tier=pro) ### Scientifically backed Designed by our health scientists and ML engineers, and validated by them before each release. You know what each score measures, so when someone asks why the number moved, you can answer. ### Trends from day one Scores are calculated over the history already in your database, so the feature launches with weeks of trend for every user instead of an empty chart. ### In your app the way data already arrives Webhooks push each new score as soon as it is ready. The API returns today's score, a given day or the full history, so there is no new pipeline to build. ### Ready to ship Sleep, recovery and activity, each from 0 to 100. Your users get a reason to open the app every morning, and our science team keeps the scores validated as devices change. The scores ## Ready to ship, on one method Sleep, recovery and activity each run from 0 to 100 on a shared method, so a user's numbers read the same way across devices and over time. Our science team adds new scores on that method when your product needs one. ### Sleep score How well a user slept, in one number, from what the night's sleep data says about its length, depth, regularity and disruption. ### Recovery score A morning read on whether the body is ready for load, for training and coaching products. ### Activity score One daily number for movement and its balance, rather than a step count on its own. What you build with them ## What your product does with a score A score is the start of a feature, not the end of one. These are the moments teams build on top. ### A number users check every morning One score on the home screen, computed in your deployment overnight. ### Coaching in your own voice The same score reads differently for an athlete and for a patient. Your rules decide what each of them hears. ### An answer to why it moved Each score comes with what it measures, so your app can say what moved it last night. Who it is for ## Teams that put a score in front of their users ### Digital health products A daily score that gives users a reason to open the app, shown in your own interface and your own words. [Learn more](https://openwearables.io/for/digital-health) ### Sports and nutrition brands Recovery and activity behind training and fuelling advice, from the watch the athlete already owns. [Learn more](https://openwearables.io/for/sports-nutrition) ### Corporate and employer wellness One consistent score across a whole member population, whatever mix of devices they wear. [Learn more](https://openwearables.io/for/employer-wellness) ### Health data platforms Scores to offer your own customers, computed where their data already sits. [Learn more](https://openwearables.io/for/health-data-platforms) How it compares ## Where the score runs, and whether you can read it Two questions decide most score choices: where the data is processed, and whether you can explain the number to the people who see it. | | A hosted API's score | Build it in-house | Open Wearables Health Scores | | --- | --- | --- | --- | | [01] Where it is computed | In the vendor's cloud | In your cloud | Inside your own Open Wearables deployment | | [02] How it is validated | By the vendor, rarely explained | By your own science team, once you have one | By our science team before each release, with what each score measures written down | | [03] What it takes | An API key and a per-user contract | Health scientists, data and months of work | Open Wearables running, and the add-on switched on | | [04] Choose this when | Speed matters more than control over the data | Scoring is your core product and you have the science team | You want scores in your product and need to explain where they come from | Who builds the scores ## Built by our health science team The scores come from the scientists and engineers who maintain Open Wearables, the same people who answer questions about them on Discord. Anna Zych ### Anna Zych Neuroscience PhD Leads the science behind the health scores: which inputs each one reads and how they are weighted. Writes Science Behind Wearables, a newsletter on what wearable data can and cannot tell you. Filip Begiełło ### Filip Begiełło ML Lead Leads machine learning on Open Wearables. Builds the scoring layer: the code that computes each score inside your deployment and over the history it already holds. ## Build scores on the devices your users already wear Every provider lands in one standard schema, and the scores read that schema rather than any one device. Support another wearable later and the same score works on it, as long as its inputs are in the data. [Browse integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## Add health scores to your product Health scores are part of Pro, computed inside your own deployment. [Book a demo](https://openwearables.io/book?tier=pro) [See pricing](https://openwearables.io/pricing#pro) FAQ ## What teams ask about the scores ### How is a sleep score calculated? Ours reads the length of the night, its sleep stages, how regular it is and how often it was interrupted, and turns them into one number from 0 to 100. Our science team designed it and validates it before each release. ### What is a good sleep score? Higher is better on a 0 to 100 scale, but the useful reading is the trend for one person over weeks rather than a single night against a fixed line. That is why scores are calculated over the history you already hold. ### What is a recovery score? A morning number from 0 to 100 on how ready the body is for load. Training and coaching products use it to decide what to suggest that day. ### Is Open Wearables still free? Yes. The core stays open source under an MIT license. Health Scores is a licensed module that runs on top of it. ### Are the scores a medical device? No. They are wellness scores, built to show trends and patterns over time, and should not be used as a clinical or diagnostic tool. ### Which wearables do the scores work with? They work across providers, because they read the standard Open Wearables schema. A score depends only on whether its inputs are present in the data, and that differs by device, so we check coverage with you. ### How is this different from the Apple Watch or Fitbit sleep score? Apple Watch, Fitbit, Garmin and Oura each calculate their own sleep score, with a method you cannot inspect. Ours is computed by Open Wearables from the raw sleep data the device syncs, so every user gets the same calculation whatever they wear. The device's own score is still stored, labelled with its source, so your app can show both side by side. ### What happens to a user's score when they switch from a Fitbit to an Apple Watch? Their score keeps the same method and scale, so the history before and after the switch stays comparable. The amount of detail can change: deep and REM sleep feed part of the score, and how much stage data a device reports differs between models. ### Do we need Open Wearables running first? Yes, the scores run inside it. If it is not running yet, deploy it yourself for free or [have us deploy it](https://openwearables.io/pricing#services). ### Can you build a score we need? Yes. Our science team builds new scores with you and validates them the same way. Tell us what you want to measure when you book a demo. ### What does it cost? Health scores are part of Pro, priced per deployment rather than per user. [Pricing](https://openwearables.io/pricing#pro) has the figures. --- Source: https://openwearables.io/platform/mcp-server # Ask your own data a question. MCP server Point Claude Desktop, Cursor or any MCP client at your deployment and ask about your users in plain language. The question and the answer stay inside your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=pro) Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo What you get ## What changes when you can just ask. Sleep, activity, workouts, cycles and the samples underneath were always reachable. What changes is who can reach them, how fast, and where the question goes. ### No query to write. You ask the way you would ask a colleague. The assistant works out which lookups it needs and runs them. - “How did they sleep last week?” ### Nothing to build. The server ships with the project. Connecting it is a config entry, not a sprint. - One config entry ### The question stays in your account. It runs against your deployment, so answering it does not send your users' data through anyone else's infrastructure. - Your deployment - No middleman ### One server, every provider. No separate Garmin MCP or Strava MCP to run and keep working. The assistant asks about a user, not about a device. - One schema - Any provider ### It reaches exactly what your key reaches. Scope comes from the API key you issued, and the tools are read-only. An assistant can answer, not change. - Read-only - Scoped to your key ### People who do not write SQL can ask. A clinician checking a cohort or a product lead checking a hunch, without putting an engineer in the middle. - No query language needed How it works ## Three steps, then you are asking questions. Setup per client, including Claude Desktop and Cursor, is in the docs. 01 ### Point it at your deployment. The server needs two things: where your backend lives and a key that belongs to you. There is no Open Wearables account in the middle, because the deployment it queries is the one you run. Terminal ``` $ OPEN_WEARABLES_API_URL=https://api.yourcompany.com $ OPEN_WEARABLES_API_KEY=ow_... ``` 02 ### Add it to the client you already use. Claude Desktop and Cursor both read a config file listing the servers they can reach. Adding this one is an entry in that file, and the client picks it up on restart. Terminal ``` $ "open-wearables": { "command": "uv", "args": ["run", "--directory", "/path/to/mcp", "start"] } ``` 03 ### Ask in the language you would use with a colleague. The assistant works out which lookups it needs, runs them against your deployment and answers. What it cannot do is reach anything your key does not already reach. [MCP server guides](https://openwearables.io/docs/mcp-server) Terminal ``` $ "Compare this user's sleep in March against February, and flag anything unusual." ``` Who asks ## Everyone on the team gets their own answers. The clinician, the coach, the researcher and the product lead each ask in their own words. Nobody files a ticket, and nobody writes a query. 01 ### A clinician, before a check-in. “Which of my patients had fewer than four nights over seven hours this month?” One question instead of opening every patient's chart. 02 ### A coach, after a training block. “Who trained longest last week, and how did their HRV move the nights after?” Workouts and recovery in one answer, from whichever watch each athlete wears. 03 ### A researcher, across a study. “How does resting heart rate change across the cycle for participants who log one?” Cycle phases and heart rate side by side, without an export. 04 ### A product lead, testing a hunch. “What share of our users hit 8,000 steps on most days last month?” A number for the roadmap review, without waiting on a dashboard. The honest comparison ## Hosted API, in-house, or self-hosted. Where each one wins. If a hosted API fits your situation, use one. | | Hosted SaaS API | Build in-house | Open Wearables, self-hosted | | --- | --- | --- | --- | | [01] Where the question is answered | Their infrastructure | Yours | Your deployment | | [02] What the assistant can reach | What they expose | What you built | Your own data, scoped to your key | | [03] Who can reach the data | The vendor and its sub-processors | Your team | Your team, and us under a DPA you sign when we work on it | | [04] Building the server | Not yours to build | Weeks of work, then maintenance | Ships with the project | | [05] Reading what the tools do | Closed | Yours | MIT source you can open | Who is it for ## Different industries, one constraint: the data cannot sit in somebody else's cloud. ### Digital health products Coaching, scoring and analytics on the devices your users already wear, with a security review somewhere ahead. [Learn more](https://openwearables.io/for/digital-health) ### Health data platforms Wearable data next to the clinical record you hold, running in your own cloud under your own credentials. [Learn more](https://openwearables.io/for/health-data-platforms) ### Remote patient monitoring Readings from the patient's own device, in the record their clinician reads, in the country the data must stay. [Learn more](https://openwearables.io/for/remote-patient-monitoring) ### Clinical and research builders Endpoints that survive review, for teams heading for DiGA, CE or FDA and for research under ethics approval. [Learn more](https://openwearables.io/for/clinical-research) ### Care providers Remote monitoring for care programmes, clinics, senior care and virtual wards, with a patient app and a care view for your team. [Learn more](https://openwearables.io/for/care-providers) ### Hospitals and telemedicine Wearable data written into your EHR, with a source for every reading that clinicians and auditors can trust. [Learn more](https://openwearables.io/for/hospitals-telemedicine) What you own ## What you actually own at the end. The deployment, the data and the algorithms stay in your account, whoever runs it. What that means in practice. ### Sovereignty Health data does not sit in a third party's cloud. Where that is your regulator's rule, your board's policy or your own, the deployment satisfies it by architecture rather than by contract. ### Residency The data stays in the region you chose, and you can prove where it is by pointing at an account rather than at a trust page. ### Control You run it under your own credentials and decide who gets access. What you build on top of Open Wearables is yours. ### Your own reasons No regulator forcing it. You want the data in your own account anyway, and that is a sufficient reason. ## Every provider, through the same conversation. Whatever a user wears, the data arrives in one schema, and the assistant queries that schema rather than each provider's API. So there is no separate Garmin MCP server, Strava MCP server or Whoop MCP server to run and keep working. There is one server, and it answers about a user rather than about a device. [Browse all integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Strava integration](https://openwearables.io/integrations/strava) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) ## Deploy Open Wearables in your own cloud. The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=pro) [See pricing](https://openwearables.io/pricing) FAQ ## Do you have more questions? ### What is MCP, in one sentence? An open standard for letting an AI assistant use external tools, so a client like Claude Desktop or Cursor can look something up instead of guessing at it. ### Does our health data go to Anthropic or to you? The server runs against your deployment and returns answers to the client you are running. What the assistant sends onward is between you and whichever model you have chosen, which is a decision you make rather than one we make for you. Nothing routes through us. ### Do we need an Open Wearables account? No. The server authenticates with a key from your own deployment, so there is no account of ours anywhere in the path. ### Which clients work? Anything that speaks MCP. Claude Desktop and Cursor are the two most teams start with, and [the docs](https://openwearables.io/docs/mcp-server) have setup for both. ### We only care about one provider. Is there a Garmin MCP server, or a Strava one? There is one server, and it covers every provider connected to your deployment. That is the point of the normalised schema: an assistant asking about last week's training does not need to know whether it came from a Garmin watch, a Strava upload or a phone. If you connect only one provider, the same server answers about that one. ### What can the assistant actually reach? Exactly what your key reaches, and nothing beyond it. The tools are read-only lookups against your own API, so an assistant can answer questions about your data but cannot change it. ### Is this the agentic AI on your roadmap? No, and the distinction matters. This ships today and is part of the project you deploy. Agentic reasoning, where the system decides what to look at without being asked, is a separate layer for building an [AI health coach](https://openwearables.io/platform/ai-insights) on your data, as a licensed module. ### Can we see what the tools do? Yes, it is MIT licensed like the rest of the project. If your security review wants to know what an assistant can reach, the answer is code they can read. ### Can we add our own tools? Yes. The server is part of the repository you cloned, so extending it with lookups specific to your product is a change you make rather than a feature request you file. --- Source: https://openwearables.io/platform/mobile-sdks # The phone syncs to your cloud, not ours. Mobile SDKs Apple Health, Health Connect and Samsung Health have no cloud API. These SDKs read them from inside your app and sync in the background to your own deployment. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=pro) Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo What you get ## What the SDK handles for you. On-device sources have no webhook and no server to call, so the work moves into the app: permissions, background sync, incremental reads and credential storage. ### Background sync that survives the app being closed. Data keeps arriving with the app closed. An interrupted sync resumes where it stopped, even after a reboot. - Background sync - Resumable sessions ### Only what changed since last time. Anchored queries read only the delta, so battery and network cost stay flat. A failed sync never loses data or sends it twice. - Anchored queries - Incremental - No duplicates ### Four platforms, one integration. The Apple Health SDK is native Swift, the Health Connect SDK native Kotlin, with Flutter and React Native wrapping the same core. - Swift - Kotlin - Flutter - React Native ### Credentials that never reach the device. Your backend mints a short-lived token per user. The app secret stays on your server, tokens in the secure keystore. - Short-lived tokens - Secure storage ### The same schema as everything else. Phone data lands in the same shape as cloud providers, so a watch and an iPhone come back in one query. - One schema - Steps - Sleep - Workouts ### Your backend, not ours. The sync endpoint is your deployment. Data goes from the phone to your infrastructure, with nothing in between. - Your endpoint - Your account How it works ## From install to first sync. Swift, Kotlin, Dart and TypeScript packages. Setup per platform, including permissions and background configuration, is in the docs. 01 ### Point it at your deployment. One call at app start tells the SDK where your backend is. There is no Open Wearables account, no dashboard and no key of ours, because the host is yours. Terminal ``` $ configure(host: "https://api.yourcompany.com") ``` 02 ### Sign the user in with a token from your backend. Your server mints a short-lived token scoped to one user and hands it to the app over your own authenticated API. The SDK takes it from there and refreshes it when it expires. Your app secret never leaves your server. Terminal ``` $ signIn(userId: "user-id", accessToken: "...", refreshToken: "...") ``` 03 ### Ask for permission once. The user grants access to their health store through the system dialog, inside your app and under your brand. You name the types you need, and the SDK handles what each platform considers a permission, which is not the same list on iOS and Android. Terminal ``` $ requestAuthorization(types: [steps, heartRate, sleep, workout]) ``` 04 ### Data arrives in the background. One call starts it. From then on the SDK reads incrementally and pushes to your deployment, and nobody has to open the app for a night of sleep to show up the next morning. [Mobile SDK guides in the docs](https://openwearables.io/docs/sdk) Terminal ``` $ startBackgroundSync() ``` What your users see ## Your app asks, their phone decides. The SDK has no screens of its own. The request starts in your app and the consent is the phone's own permission screen, so there is no Open Wearables step to explain. 01 ### Your app starts it. A Connect button wherever you put it, in your onboarding or your settings, under your brand and behind your existing login. 02 ### They pick the store. Apple Health on an iPhone. On Android, Health Connect or Samsung Health, whichever the phone has, and the SDK connects to the one they pick. 03 ### The phone asks, in its own words. Apple Health, Health Connect or Samsung Health shows its own permission screen for the data types you named. The request is read only: the SDK never asks to write. 04 ### They share what they choose. The user can allow every type or only some, and the SDK reads only what was granted. The honest comparison ## Hosted API, in-house, or self-hosted. Where each one wins. If a hosted API fits your situation, use one. | | Hosted SaaS API | Build in-house | Open Wearables, self-hosted | | --- | --- | --- | --- | | [01] On-device sources | Their SDK in your app | Yours to build, per platform | Our SDK in your app, source included | | [02] Where the phone uploads to | Their servers | Yours | Your deployment, your region | | [03] Who can reach the data | The vendor and its sub-processors | Your team | Your team, and us under a DPA you sign when we work on it | | [04] Platform changes | They absorb them | Your team tracks every OS release | Fixed in a release you pull | | [05] Cross-platform | Depends on their wrappers | Two codebases, or a wrapper you maintain | Swift, Kotlin, Flutter and React Native | | [06] Reading the sync code | Closed | Yours | MIT source you can fork | | [07] Cost shape | Scales with monthly active users | Salaries and infrastructure | Fixed. Flattens as you grow | Who is it for ## Different industries, one constraint: the data cannot sit in somebody else's cloud. [For hospitals](https://openwearables.io/for/hospitals-telemedicine) ### Digital health products Coaching, scoring and analytics on the devices your users already wear, with a security review somewhere ahead. [Learn more](https://openwearables.io/for/digital-health) ### Health data platforms Wearable data next to the clinical record you hold, running in your own cloud under your own credentials. [Learn more](https://openwearables.io/for/health-data-platforms) ### Remote patient monitoring Readings from the patient's own device, in the record their clinician reads, in the country the data must stay. [Learn more](https://openwearables.io/for/remote-patient-monitoring) ### Clinical and research builders Endpoints that survive review, for teams heading for DiGA, CE or FDA and for research under ethics approval. [Learn more](https://openwearables.io/for/clinical-research) ### Care providers Remote monitoring for care programmes, clinics, senior care and virtual wards, with a patient app and a care view for your team. [Learn more](https://openwearables.io/for/care-providers) ### Hospitals and telemedicine Wearable data written into your EHR, with a source for every reading that clinicians and auditors can trust. [Learn more](https://openwearables.io/for/hospitals-telemedicine) What you own ## What you actually own at the end. The deployment, the data and the algorithms stay in your account, whoever runs it. What that means in practice. ### Sovereignty Health data does not sit in a third party's cloud. Where that is your regulator's rule, your board's policy or your own, the deployment satisfies it by architecture rather than by contract. ### Residency The data stays in the region you chose, and you can prove where it is by pointing at an account rather than at a trust page. ### Control You run it under your own credentials and decide who gets access. What you build on top of Open Wearables is yours. ### Your own reasons No regulator forcing it. You want the data in your own account anyway, and that is a sufficient reason. ## The three SDKs, and what each one reads. Cloud providers connect server to server and need no app. These three live on the phone, so each one needs an SDK inside your app. [Browse all integrations](https://openwearables.io/integrations) - [Apple Health integration](https://openwearables.io/integrations/apple-health) Apple Health SDK - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) Health Connect SDK - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) Samsung Health SDK - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## Deploy Open Wearables in your own cloud. The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account with the SDK live in your app. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=pro) [See pricing](https://openwearables.io/pricing) FAQ ## Do you have more questions? ### Do we need the SDK at all? Only for on-device sources. Garmin, Polar, Whoop, Oura and the other cloud providers connect server to server and work without an app. Apple Health, Health Connect and Samsung Health have no cloud API, so the only way to reach them is from inside an app the user has installed. No app yet? The [Connect App](https://openwearables.io/platform/connect-app) is a ready one, built on these SDKs. ### Does the user have to keep the app open? No. Each platform has its own way of waking an app to do work, and the SDK uses it rather than asking the user to open anything. A sync interrupted by a restart or a reboot resumes rather than starting again. What the operating system guarantees about timing is its decision rather than ours, so treat background sync as reliable rather than instant. ### Where does the data go? From the phone to your deployment, over an endpoint that belongs to you. There is no intermediate service holding a copy, which is what makes this different from a hosted SDK writing to a vendor's backend. ### Is our app secret on the device? No, and that is deliberate. Your backend mints a short-lived token scoped to a single user and forwards it to the app over your own authenticated API. The token refreshes itself and is held in the platform's own secure keystore, not in ordinary app storage. ### We use Flutter. Is it a second-class integration? No. Flutter wraps the same native Swift and Kotlin cores, so the sync behaviour is identical code doing the work. What differs is the API you call, not what happens underneath. React Native works the same way, and the package is not on npm yet, so ask us where it stands if that is your stack. ### What does the SDK need from the platforms? The Apple Health SDK needs an Apple Developer account, the HealthKit capability switched on, a reasonably current iOS version, and a physical device, because HealthKit does not run in the simulator. The Health Connect SDK needs a recent Android API level and nothing else. The Samsung Health SDK additionally needs a current version of the Samsung Health app on the device. The docs have exact versions, which move with each release. ### How much data does the first sync pull? As much history as the user's health store holds and your permissions allow, which can be years on a phone somebody has had for a while. After that, anchored queries read only what changed, so the ongoing cost is small. ### What happens when Apple or Google changes something? The fix ships in an SDK release, and you pick it up when you update. That is the part teams underestimate when they build this themselves: it is not the initial integration that costs, it is every OS release afterwards. ### Can we see what the SDK actually does? Yes, it is MIT licensed like the rest of the project. If your security review wants to know what an SDK in your app reads and where it sends it, the answer is code they can read rather than a document from us. --- Source: https://openwearables.io/platform/raw-data # Keep the original, not just the interpretation. Raw data Open Wearables keeps both: the standard schema you query every day, and underneath it the payload exactly as the provider sent it. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=pro) Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo What you get ## What survives the trip into your database. A normalised schema is someone's decision about what matters. Keeping the original next to it costs a bucket, and means you can still answer the question nobody asked yet. ### The payload, before anything touched it. What a provider sent is written down before normalisation runs, so the record is the provider's own structure rather than an interpretation of it. If a field never made it into the standard schema, it is still there. - Pre-normalisation - As sent - Your bucket ### You decide whether to keep them. Retention is off until you switch it on, so a deployment that does not need the originals carries no extra storage. One setting turns it on, and the destination is a bucket you own. - Off by default - One setting - No third party ### Samples, not just daily totals. Heart rate through the day rather than a single average, and workout detail where the provider sends it. The granularity the device recorded is the granularity you get to work with. - Intraday samples - Daily totals - Both kept ### A record that compounds. A metric you invent next year can be computed against the history you already hold, rather than starting from the day you thought of it. That is the part teams notice late, usually when a question arrives that the old schema cannot answer. - Full history - Re-derive later - No re-consent ### The mapping is code you can read. Normalisation is code in the repository you cloned, in files you can open. When somebody asks how a value in the standard schema was derived, the answer is a function rather than a support ticket. - Open source - MIT - In your repo ### Replay, not just archive. Stored on-device payloads can be sent back through ingestion for a user, filtered by source or date range, with a dry run first. - Replay tooling - Filter by provider - Dry run How it works ## Where the original goes. Retention is a setting, and the destination is yours. Storage backend, size limits and what the stored objects look like are in the docs. 01 ### The provider sends what it sends. A webhook fires, a scheduled pull returns, or a phone uploads through the SDK. Each one arrives in that provider's own shape, which is nothing like the next provider's. Terminal ``` $ {"sleeps": [{ "summaryId": "x5b70ccc", "durationInSeconds": 29400, ... }] ``` 02 ### It is written down before anything reads it. The payload goes to your bucket first, then processing starts. That order makes the stored copy the original, not a reconstruction, for webhooks, scheduled pulls and on-device uploads alike. Terminal ``` $ s3://your-bucket/raw-payloads/garmin/webhook/2026-01-13/{user_id}/{file_id}.json ``` 03 ### Then it becomes the same shape as everything else. Normalisation maps it into the standard schema, so sleep from one provider is queried like sleep from any other. The mapping is code in your repository, which is what you show someone asking how a number was derived. Terminal ``` $ sleep_duration_seconds: 29400 · efficiency_percent: 87.0 · stages.deep_minutes: 95 ``` 04 ### You query the standard shape, and keep the original. Day to day you work with the normalised model, because that is what joins against the rest of your product. The original is there for the question you have not been asked yet. [Raw payload storage in the docs](https://openwearables.io/docs/dev-guides/raw-payload-storage) Terminal ``` $ GET /api/v1/users/{user_id}/summaries/sleep ``` What's in your bucket ## The originals, filed where you can find them. The stored payloads sit in object storage in your own account, in a layout you can browse, query or show an auditor without asking us how it works. 01 ### By provider. Each source gets its own folder, from a watch's cloud to the health store on a phone. 02 ### By how it arrived. Webhooks, scheduled pulls and uploads from the phone are kept apart, so you can tell a push from a pull from an on-device sync. 03 ### By day and by user. Under each, a folder per day, and within it a folder per user where the payload belongs to one person. 04 ### Labelled on the object. Every file carries its source, provider, size and time, and the user and the batch it belongs to where there is one. The honest comparison ## Hosted API, in-house, or self-hosted. Where each one wins. If a hosted API fits your situation, use one. | | Hosted SaaS API | Build in-house | Open Wearables, self-hosted | | --- | --- | --- | --- | | [01] The original payload | Held on their side, if at all | Yours to store | Yours, in a bucket you name | | [02] Fields outside their schema | Gone | Whatever you mapped | Still in the stored original | | [03] Granularity | What their model exposes | What you built for | Samples where the provider sends them | | [04] Explaining a number to a reviewer | Their documentation | Your code | Your code, from a repository you cloned | | [05] A metric you invent later | Starts from today | Starts from your history | Starts from your history | | [06] Who holds the archive | Them | You | You | Who is it for ## Different industries, one constraint: the data cannot sit in somebody else's cloud. ### Digital health products Coaching, scoring and analytics on the devices your users already wear, with a security review somewhere ahead. [Learn more](https://openwearables.io/for/digital-health) ### Health data platforms Wearable data next to the clinical record you hold, running in your own cloud under your own credentials. [Learn more](https://openwearables.io/for/health-data-platforms) ### Remote patient monitoring Readings from the patient's own device, in the record their clinician reads, in the country the data must stay. [Learn more](https://openwearables.io/for/remote-patient-monitoring) ### Clinical and research builders Endpoints that survive review, for teams heading for DiGA, CE or FDA and for research under ethics approval. [Learn more](https://openwearables.io/for/clinical-research) ### Care providers Remote monitoring for care programmes, clinics, senior care and virtual wards, with a patient app and a care view for your team. [Learn more](https://openwearables.io/for/care-providers) ### Hospitals and telemedicine Wearable data written into your EHR, with a source for every reading that clinicians and auditors can trust. [Learn more](https://openwearables.io/for/hospitals-telemedicine) What you own ## What you actually own at the end. The deployment, the data and the algorithms stay in your account, whoever runs it. What that means in practice. ### Sovereignty Health data does not sit in a third party's cloud. Where that is your regulator's rule, your board's policy or your own, the deployment satisfies it by architecture rather than by contract. ### Residency The data stays in the region you chose, and you can prove where it is by pointing at an account rather than at a trust page. ### Control You run it under your own credentials and decide who gets access. What you build on top of Open Wearables is yours. ### Your own reasons No regulator forcing it. You want the data in your own account anyway, and that is a sufficient reason. ## Your raw data, from the devices your users wear. Cloud providers push through webhooks and return through scheduled pulls. On-device sources upload through the SDK. All three paths write the payload down before it is normalised. [Browse all integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## Deploy Open Wearables in your own cloud. The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=pro) [See pricing](https://openwearables.io/pricing) FAQ ## Do you have more questions? ### Do you keep the raw provider data? Only if you switch it on. Raw payload capture writes what a provider sent to a bucket you own, before any processing. It is off until you enable it, and adds nothing when off. ### Why would we want the original if we already have the normalised version? Because a standard schema is a decision about what matters, and decisions age. The usual trigger is a question nobody anticipated: a regulator asking how a number was derived, a clinician wanting the underlying samples, or a metric you want to compute across history you already hold. ### Where is it stored? In object storage you control, inside your own account. There is no copy on our side in either operating model, which is the difference between this and a hosted platform that keeps an archive for you. ### How long is it kept? For as long as your own storage policy says. Expiry is set on the bucket rather than by the application, so retention stays a decision you make and can evidence, not a default you inherited. ### Can we do anything with the stored payloads, or is it just an archive? Payloads that came from the phone can be sent back through ingestion for a user, filtered by provider, source or date range, with a dry run first. That is how a mapping fix is applied to on-device data you already have. Everything else stays a record you can read. ### How granular is the data underneath? Where a provider sends samples through the day, samples are what you get, rather than a daily average standing in for them. Workout detail is available where the provider exposes it. What any given provider actually sends is in the [coverage matrix in the docs](https://openwearables.io/docs/providers/coverage). ### Is any of this different in the managed model? No. When we deploy or maintain it for you, it still runs in your account, the bucket is still yours, and the repository is still the one you cloned. What changes is who does the work, under a DPA you sign. --- Source: https://openwearables.io/platform/wearable-api # The wearable data layer you own Wearable API One wearable API across the devices your users already own, deployed in a cloud account you control, in a region you choose. No data lands in a vendor tenant. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=pro) Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo What you get ## Open Wearables sits between the devices your users wear and the product you are building. It handles the integrations, standardises what comes back, and keeps all of it in infrastructure you own. ### One standard schema Query a user, not a provider. Activity, sleep, heart rate and body measurements come back in one shape, in your own database. - Raw payloads kept - Time series - Webhooks ### Connection flows, maintained Each source has its own authorisation model and its own quirks. All of them are implemented and kept working behind a single endpoint. - Wearable integrations - OAuth flows - Delivery history ### Custom health scores Health scores designed and validated by our science team, computed inside your deployment. Part of Pro, with custom scores built on request. - Health scores - Science team ### Data off the device On-device sources have no server-to-server API. Native SDKs for iOS, Android, Flutter and React Native handle background sync. - HealthKit - Health Connect ### Shared accounts, no wasted quota One provider account can sit behind several of your user profiles. The payload arrives once and fans out, and a lock stops duplicate calls. - Fan-out - Dedup lock - Quota-safe ### MCP server Point Claude Desktop or Cursor at your own deployment and ask about your data in plain language. - Claude Desktop - Cursor How it works ## From clone to production 01 ### Run it Clone the repository and bring it up with Docker Compose. The API and the developer portal start on your machine, with no third-party services, and the first API call takes five minutes. Terminal ``` $ git clone https://github.com/the-momentum/open-wearables.git $ cd open-wearables && docker compose up -d $ curl localhost:8000/api/v1/health ``` 02 ### Connect the providers You register applications in your own name, so the data relationship sits between you and the provider. Approval timelines vary, so this is the step worth starting first. Garmin is the slowest of them: [Garmin API integration](https://openwearables.io/integrations/garmin). Terminal ``` $ curl -X GET "http://localhost:8000/api/v1/oauth/garmin/authorize\ ?user_id=$USER_ID&redirect_uri=https://yourapp.com/connected" \ -H "X-API-Key: $API_KEY" ``` 03 ### Query the user, not the provider One call returns that person's data across every source they have connected. Workouts and sleep sit behind the same pattern, at /events/workouts and /events/sleep. Connect another device tomorrow and the call does not change. Terminal ``` $ curl -X GET "http://localhost:8000/api/v1/users/$USER_ID/timeseries\ ?start_time=2026-09-01T00:00:00Z&end_time=2026-09-04T00:00:00Z\ &types=heart_rate&types=steps" \ -H "X-API-Key: $API_KEY" ``` 04 ### Deploy it where it belongs Production and staging in your own cloud account, in your region, defined as infrastructure code in your repository. Either your team stands it up, or you buy a deployment and we do it. #### Self-host it Docker Compose to start, infrastructure as code for production. MIT license, full source. [Get started](https://openwearables.io/docs/quickstart) #### We stand it up in your cloud Same architecture, same account, your credentials. We deploy it, harden it and hand it over to your engineers. [See pricing](https://openwearables.io/pricing) The honest comparison ## Hosted SaaS API, in-house build, or self-hosted Where each one actually wins. If a hosted API fits your situation, use one. | | Hosted SaaS API | Build in-house | Open Wearables, self-hosted | | --- | --- | --- | --- | | [01] First API call | Hours | Months | Minutes, with Docker Compose | | [02] Where the data sits | Their cloud, their regions | Yours | Your cloud account, your region | | [03] Who can reach the data | The vendor and its sub-processors | Your team | Your team, and us under a DPA you sign when we work on it | | [04] Raw provider payload | Varies by vendor | Whatever you keep | Your own storage, when you turn it on | | [05] Provider credentials | Theirs, handled for you | Yours to obtain | Yours, in your own name | | [06] Certifications | Theirs | Yours to earn | Yours, in your certified environment | | [07] Cost shape | Scales with monthly active users | Salaries and infrastructure | Fixed, flattens as you grow | Who is it for ## Different industries, one constraint. The data cannot sit in somebody else's cloud, and each of these teams arrives at that from a different direction. ### Digital health products Coaching, scoring and analytics on the devices your users already wear, with a security review somewhere ahead. [Learn more](https://openwearables.io/for/digital-health) ### Health data platforms Wearable data next to the clinical record you hold, running in your own cloud under your own credentials. [Learn more](https://openwearables.io/for/health-data-platforms) ### Remote patient monitoring Readings from the patient's own device, in the record their clinician reads, in the country the data must stay. [Learn more](https://openwearables.io/for/remote-patient-monitoring) ### Clinical and research builders Endpoints that survive review, for teams heading for DiGA, CE or FDA and for research under ethics approval. [Learn more](https://openwearables.io/for/clinical-research) ### Care providers Remote monitoring for care programmes, clinics, senior care and virtual wards, with a patient app and a care view for your team. [Learn more](https://openwearables.io/for/care-providers) ### Hospitals and telemedicine Wearable data written into your EHR, with a source for every reading that clinicians and auditors can trust. [Learn more](https://openwearables.io/for/hospitals-telemedicine) What you own ## What you actually own at the end The deployment, the data and what you build on it stay in your account, whoever runs it. What that means in practice. ### Sovereignty Your regulator, board or own policy keeps health data out of third-party clouds. The deployment meets that by architecture, not by contract. ### Residency The data stays in the region you chose, and you prove it by pointing at an account, not at a trust page. ### Control What you build on top of Open Wearables is yours, on a data model and pipeline in your own account. Nobody can reprice it, change it or be acquired out from under you. ### Your own reasons No regulator forcing it and no security review coming. You want the data in your own account anyway. ## Deploy Open Wearables in your own cloud The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account with the providers connected and validated on real accounts. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=pro) [See pricing](https://openwearables.io/pricing) FAQ ## Do you have more questions? ### Is it really free? Yes. The core is MIT licensed, with the full source. We charge for Pro, Enterprise, the Deployment and Integration services and custom development. ### What does it cost compared with a hosted API? Running it costs your own cloud bill, which we size with you before you commit and never mark up. Deployment and Integration are one-off services, and health scores and the other licensed modules come with Pro. A hosted API usually prices per monthly active user. [Pricing](https://openwearables.io/pricing) has the figures. ### Which devices are supported? The wearables your users are most likely to own, across cloud OAuth providers and on-device sources. The [coverage matrix in the docs](https://openwearables.io/docs/providers/supported) lists what each one returns. ### Can we use this for a HIPAA workload? The deployment runs on your infrastructure, so access, encryption, retention and audit logging are yours to control and to evidence. A BAA depends on your cloud provider and your scope. ### Do you hold SOC 2 or ISO 27001? No. The deployment runs inside your certified environment, which is how most teams answer this in their own audit. ### Do you keep the raw provider data? Only if you switch it on. Raw payload capture writes the exact JSON a provider sent to your own log or S3 bucket before any processing. It is off by default and adds no overhead when off. ### What happens if we stop working with you? Nothing stops. The deployment sits in your cloud account, under your credentials, built from infrastructure code in your repository, under an MIT license. ### We already use a hosted aggregator. How hard is moving? Usually a re-integration rather than a data migration. What changes is where new data lands from then on, which is your own database. It starts with an architecture audit. ### Who maintains Open Wearables? Momentum, a healthcare software development company. The project is MIT licensed and developed in the open, with a public roadmap and public issues, so the source does not depend on us continuing to fund it. ### Who runs it? The deployment lives in your cloud account either way. Either your team operates it, or you buy a deployment and we stand it up. Ongoing maintenance comes with Enterprise and is a separate decision. [Pricing](https://openwearables.io/pricing) has the tiers. --- Source: https://openwearables.io/pricing # What it costs to run Open Wearables in your own cloud Everything runs in your own cloud account. Run the core yourself for free, or put our team behind it with Pro or Enterprise. ## Core Self-hosted For teams building their first wearable features. You run the open-source platform yourself. $0 Forever - One API across cloud and on-device sources - Unified data model, raw payloads in your bucket - SDKs for iOS, Android, Flutter and React Native - Sync, backfill and webhooks - Admin panel and MCP server - Connect App for up to 5 users - Open source, MIT license, Discord support [Get started](https://openwearables.io/docs/quickstart) ## Pro Subscription For products in production. Licensed modules, with our engineers behind your deployment. From $999 a month, per deployment Everything in Core, plus The Pro modules, in your deployment - [Health scores](https://openwearables.io/platform/health-scores) - [Health agent](https://openwearables.io/platform/ai-insights) - [Medical-grade integrations](https://openwearables.io/pricing#modules) - [Observability](https://openwearables.io/pricing#modules) - [Connect App, no user limit](https://openwearables.io/platform/connect-app) - Modules run in your own cloud - Onboarding session with our team - Slack channel with our engineers [Book a demo](https://openwearables.io/book?tier=pro) ## Enterprise Annual agreement For health organisations at scale, from digital health to hospital groups. We run and secure it in your cloud, under an SLA. Custom Everything in Pro, plus - SLA support - Updates verified on your data before you upgrade - Deployed and set up for your use case, such as remote patient monitoring, then maintained - Security reviews and questionnaires answered by us - SSO, roles and audit logging - Multi-tenant and multi-region - GDPR tooling, signed DPA and BAA - Roadmap input Delivered by The team behind Open Wearables. [Talk to us](https://openwearables.io/book?tier=enterprise) A care provider, hospital or telemedicine platform? [See the three paths](https://openwearables.io/pricing#paths) ## Compare every feature, plan by plan Platform, Pro modules, support, services and security, side by side. The full picture ## Compare what each plan includes | Feature | Core You run it yourself. $0 Self-hosted [Get started](https://openwearables.io/docs/quickstart) | Pro Scores, insights and cleaner data. From $999 Per month, per deployment [Book a demo](https://openwearables.io/book?tier=pro) | Enterprise Run, maintained and secured at scale. Custom Annual agreement [Talk to us](https://openwearables.io/book?tier=enterprise) | | --- | --- | --- | --- | | Wearable integrations Garmin, Oura, Whoop, Polar and more, connected through one standard schema. | Included | Included | Included | | OAuth flow management | Included | Included | Included | | Data sync New data from each provider lands in your own database as it arrives. | Included | Included | Included | | Mobile SDKs iOS, Android, Flutter and React Native, for on-device sources like Apple Health and Health Connect. | Included | Included | Included | | Developer dashboard | Included | Included | Included | | Raw payload retention Original provider payloads kept for debugging. Off by default. | Included | Included | Included | | MCP server Lets an AI assistant query a user's wearable data through your own deployment. | Included | Included | Included | | Community on Discord | Included | Included | Included | | Slack channel with our engineers A shared Slack channel where your team talks directly to the engineers who build Open Wearables. | Not included | Included | Included | | Updates verified on your data Before you upgrade, we run the new release and its migrations against your deployment's data and tell you what changes. | Not included | Not included | Included | | Ongoing maintenance Provider API changes, updates and fixes handled after launch. | Not included | Not included | Included | | SLA support Response times agreed in your contract, for when something breaks. | Not included | Not included | Included | | Roadmap input Your product's needs weighed when we decide what to build next. | Not included | Not included | Included | | Health scores Scores designed and validated by our science team, running on your users' data in your cloud. | Not included | Included | Included | | Health agent Plain-language answers for each user about their own data, inside your app. | Not included | Included | Included | | Medical-grade integrations A private catalogue of integrations with certified medical devices, added to your deployment as extensions and kept up to date by us. | Not included | Included | Included | | Connect App A ready-made iOS and Android app, under the Open Wearables name, that brings your users' Apple Health, Health Connect and wearable data to your servers, without building a mobile app. | Up to 5 users | No user limit | No user limit | | Connect App under your brand The same app under your brand, in your own store accounts. A paid option, per platform. | Not included | $5,000 per platform $5,000 per platform, iOS or Android. Your name, icon and colours, in your own store accounts. [Talk to us](https://openwearables.io/book?tier=custom) | $5,000 per platform $5,000 per platform, iOS or Android. Your name, icon and colours, in your own store accounts. [Talk to us](https://openwearables.io/book?tier=custom) | | Observability Sync health per provider and per user across your deployment, so a broken connection is caught before your users notice. | Not included | Included | Included | | What is planned next is on [the roadmap](https://openwearables.io/live-vs-roadmap#roadmap). | | | | | Deployment in your cloud Production and staging, infrastructure as code in your repository, provider onboarding and handover documentation. | From $4,800 From $4,800, one-time. Production and staging in your cloud and region, providers onboarded under your credentials. Final figure confirmed before you commit. [Talk to us](https://openwearables.io/book?tier=deployment) | From $4,800 From $4,800, one-time. Production and staging in your cloud and region, providers onboarded under your credentials. Final figure confirmed before you commit. [Talk to us](https://openwearables.io/book?tier=deployment) | Included | | Integration into your app The connection and consent flow in your own interface, behind your existing login, tested end to end before launch. | From $9,600 From $9,600, one-time, deployment included. The connection flow built into your app, behind your existing login. [Talk to us](https://openwearables.io/book?tier=integration) | From $9,600 From $9,600, one-time, deployment included. The connection flow built into your app, behind your existing login. [Talk to us](https://openwearables.io/book?tier=integration) | Included | | Custom development Features, AI and coaching logic, or a whole healthcare or wellness app, built by Momentum. | Per scope Your product built by the team behind Open Wearables, at a fixed price per scope or from a monthly pool of engineering time. [Talk to us](https://openwearables.io/book?tier=custom) | Per scope Your product built by the team behind Open Wearables, at a fixed price per scope or from a monthly pool of engineering time. [Talk to us](https://openwearables.io/book?tier=custom) | Per scope Your product built by the team behind Open Wearables, at a fixed price per scope or from a monthly pool of engineering time. [Talk to us](https://openwearables.io/book?tier=custom) | | SSO and roles Single sign-on and role-based access for your team in the developer portal. | Not included | Not included | Included | | Audit logging A record of who accessed what in your deployment, for your auditors. | Not included | Not included | Included | | Multi-tenant and multi-region Separate tenants for your own customers, and deployments in more than one region. | Not included | Not included | Included | | GDPR tooling Data export, deletion and retention handled for your users' requests. | Not included | Not included | Included | | Signed DPA A data processing agreement, signed whenever our people work on your running deployment. | With a service Signed when a Deployment or Integration service gives our people access to your running deployment. | Included | Included | | Signed BAA, where supported A business associate agreement for HIPAA work, where the setup supports it. | Not included | Not included | Included | | Security questionnaires Answers to your customers' and auditors' security questionnaires. | Not included | Not included | Included | | Infrastructure hardening The deployment's configuration reviewed and tightened against common attacks. | Not included | Not included | Included | - FROM: One-time, from that price - PER SCOPE: Priced once scoped with you - INCLUDED: Part of Enterprise Is Open Wearables for you ## Three paths our clients usually choose Each path runs the same open-source core in your own cloud account. What changes is what sits on top of it, and how you start. ### Digital health products Build your product on a wearable data layer you own. It connects the devices your users already wear and runs secured in your own cloud account as your user base grows. [Learn more](https://openwearables.io/for/digital-health) ### Care programmes Run a monitored programme without building the software: a patient app and a care view for your team, running and secured in your own cloud account from the first reading. [Learn more](https://openwearables.io/for/care-providers) ### Hospitals and telemedicine Wearable data in the EHR your clinicians already open, with a source on every value and the evidence an auditor asks for, running in your own cloud account as you roll out site by site. [Learn more](https://openwearables.io/for/hospitals-telemedicine) The team behind it ## Built by Momentum, the team behind Open Wearables A healthcare software company building health data software since 2016. The engineers who built Open Wearables deploy it and build on it for clients. [Visit Momentum](https://www.themomentum.ai/) [Talk to us](https://openwearables.io/book?tier=custom) Building health data software since 2016 Healthcare only 100% Certified quality system ISO 13485 Rating on Clutch 4.9 / 5 FAQ ## Do you have more questions? ### Is the free version really free? Yes. MIT license, full source, no trial window. We charge for Pro, for Enterprise, and for deployment work if you want it done for you. ### How is Pro priced? From $999 a month per production deployment, staging included. It includes health scores, the health agent, medical-grade integrations and observability. The [Connect App](https://openwearables.io/platform/connect-app) is included under the Open Wearables name with no user limit; a version under your brand is a paid option at $5,000 per platform. A second region, a second brand or a second client of your platform counts as a second deployment. ### Can we run it ourselves after the deployment? Yes, and plenty do. You get the infrastructure code, the diagram, the operations guide and a walkthrough, plus 30 days of support. Enterprise is a decision you can take later. ### We have more than one app. What changes? Integration covers one app, because that is where the connection flow gets built. A second app, whatever it runs on, is a second piece of front-end work and we scope and price it separately. Deployment is identical either way. ### What happens if we stop paying? Nothing stops. The platform sits in your cloud account, under your credentials, built from infrastructure code in your repository, under an MIT license. You lose the licensed modules, the on-call and the tested upgrades, not the platform and not the data. ### What does it cost to run on top of your fee? Your cloud bill, paid directly to your provider and never marked up by us. We size it with you before you commit. ### Is Enterprise only for large companies? No. It suits any health app or platform that wants the platform run, maintained and secured for it, whether that is because of scale or because its customers run a security review. One agreement covers the licence, the deployment and the support. ### We run a care programme or a clinical service. Does this pricing apply? These plans are built for health apps and platforms. Care programmes and clinical services need more around the data, so we scope them with you, usually starting with a fixed-fee pilot. Clinical logic on top, such as alerts and triage, is built with you under an ISO 13485 quality system. See how it works for [care providers](https://openwearables.io/for/care-providers) and for [hospitals and telemedicine](https://openwearables.io/for/hospitals-telemedicine), or talk to us and we will walk you through it. ### Do you hold SOC 2 or ISO 27001? No. The deployment runs inside your certified environment, which is how most teams answer this in their own audit. ### Will you sign a DPA? A BAA? Yes, whenever our people can reach your deployment: under Pro support, during a Deployment or Integration service, and for as long as Enterprise runs. Where you self-host on Core, there is no processing for us to agree to, because we never touch it. A BAA comes with Enterprise, where your cloud provider and your scope support it. ### Who obtains the provider credentials? You do, in your name, so the data relationship is between you and them. Approval is slow with some sources, so we start on day one. ### We use a hosted aggregator today. How hard is moving? Usually a re-integration rather than a data migration, because you own the raw payloads from then on. It starts with an architecture audit. --- Source: https://openwearables.io/privacy-policy # Privacy Policy Legal openwearables.io · Last updated: July 2, 2026 Data controller for openwearables.io is Momentum Sp. z o.o., located in Wrocław, ul. Gen. Władysława Sikorskiego 26, 53-659 Wrocław, KRS: 0000602983, NIP: 8992778355, REGON: 3363012720. Open Wearables is an open-source platform developed and maintained by [Momentum](https://www.themomentum.ai). The controller commits to safeguarding data obtained from you, respecting your rights as data subjects and applicable laws, particularly GDPR (Regulation EU 2016/679 of April 27, 2016), the Polish Act of May 10, 2018 on personal data protection, and other relevant legislation. All employees with data access receive proper training. The controller implements appropriate technical and organizational safeguards ensuring the highest protection level, plus GDPR-compliant procedures and policies guaranteeing lawful, fair processing and enforcement of your rights. The controller cooperates with Poland's Personal Data Protection Office when necessary. Questions, motions, and complaints regarding data processing should be sent to [documents@themomentum.ai](mailto:documents@themomentum.ai) or the controller's address. Responses will be provided within 14 days. Collected personal data includes: 1. Name, surname, company name: for contact purposes and scheduling discovery calls 2. Email address: for sending calendar invitations and follow-up communication 3. Information about what you are building and topics to cover: for preparing relevant call content 4. IP address: for technical and security purposes Data sharing is necessary for: 1. Using contact and booking forms on openwearables.io 2. Scheduling and conducting discovery calls 3. Sending product updates, release notes, and developer news about Open Wearables, where consent has been given Data processing duration varies by basis: 1. Contract-based: duration of contract plus limitation period for claims 2. Consent-based: until consent withdrawal 3. Legitimate interest: while interest persists 4. Legal obligation: as required by regulation The service uses cookies to customize functionality to individual needs. Users may consent to data retention for future visits or disable cookies via browser settings. Personal data sources are the data subjects themselves. Personal data are not transferred to third countries per GDPR. Data are not disclosed to third parties without explicit consent, except to public authorities and administrative bodies with legal legitimacy. Data processing may be entrusted to processors operating under processing agreements, limited to defined needs, extent, and purposes. This includes the scheduling platform used for booking discovery calls. Data will not be subjected to automated decision-making. Data subjects have rights to: 1. Access, correct, update, or delete personal data by contacting [documents@themomentum.ai](mailto:documents@themomentum.ai) 2. Object to processing, limit processing, or request data transfer via [documents@themomentum.ai](mailto:documents@themomentum.ai) 3. Withdraw consent at any time without affecting prior lawful processing 4. Lodge complaints with supervisory authorities Right to erasure limitations apply when: 1. Processing is necessary for freedom of speech and information 2. Processing fulfills legal obligations for the controller 3. Data processing relates to legal claim exercise or defense Safety breaches are recorded, and affected persons and PUODO are informed when GDPR or Act events occur. Applicable law governs matters not covered herein. Legal provisions prevail over policy discrepancies. The controller reserves unilateral amendment rights. Changes take effect upon publication at openwearables.io. --- Source: https://openwearables.io/security # Built to pass your security review. Security Open Wearables runs inside your own cloud account, behind the network rules and monitoring you already have. This page is what a reviewer asks for next: how a deployment is built, who can reach it, and what we hold. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) What the architecture settles ## Half the questionnaire stops applying. Much of a security review asks where the data sits and who can reach it. When the software runs in your account, you answer those from your own environment. ### There is no vendor tenant holding your data. Health data goes from the provider or the phone into your deployment. Nothing in between keeps a copy, so there is no second environment to assess. ### Your existing controls apply unchanged. The deployment sits behind your network policy and your monitoring, because it is in your account rather than adjacent to it. ### Your certification covers it. If you hold SOC 2 or ISO 27001, the deployment can run inside that scope. You are not inheriting somebody else's posture or hoping it holds. The build ## How a deployment is built. A reviewer usually asks about four things. These are the decisions that get made when we stand a deployment up, and the ones we recommend when you do it yourself. ### Key-based access Access to the machines is individual and key-based. Nobody logs in with a shared password, and administrative access is not the default state. ### Closed network The network is closed by default. Reaching a deployment means coming from somewhere approved rather than from anywhere on the internet. ### Encrypted throughout Data is encrypted at rest and in transit, including the database and the connections to it. ### Secrets kept apart Credentials live outside the codebase, separated per environment and handed over through a channel chosen for the purpose rather than through email or chat. The application ## What the software does on its own. The build covers the machines. These are the controls inside Open Wearables itself, in code your reviewers can read. 01 ### Hashed credentials. Developer passwords are stored as bcrypt hashes and API keys as hashes, so the database never holds either in the clear. 02 ### Mobile tokens that cannot read. The phone gets a short-lived token that can only write its own user's data. The app secret stays on your backend. 03 ### Provider webhooks verified. Incoming provider webhooks are checked against each provider's signature or secret before anything is stored. 04 ### Signed outgoing events. Every event sent to your endpoint is HMAC-signed, and the verification library rejects deliveries older than five minutes. 05 ### Off until you turn it on. Outgoing webhooks and raw payload storage are both off by default, so nothing extra runs or is kept unless you choose. Who can reach it ## Access, in both operating models. ### If you deploy it yourself, nobody else has access. There is no support account and no break-glass credential. What you would be assessing is your own team. - No standing access ### When we work on your system, access is named in a DPA you sign. It is a defined list of people for the work agreed, rather than standing administrative rights. - Named in the contract ### Either way, what happened is visible in your own logs. The deployment is in your account, so verifying our answer does not mean trusting it. - Visible in your logs Certifications ## What we hold, plainly. 01 ### We do not hold SOC 2 or ISO 27001. The deployment runs inside your certified environment, which is how most teams answer this question in their own audit. If your procurement treats a vendor certificate as mandatory regardless of where the software runs, tell us early and we will be straight with you about whether that works. 02 ### The code is MIT licensed and public. A security review that wants to know what the software does can read it rather than ask us. That is a different kind of assurance than a certificate, and for engineering-led reviews it is often the one that matters. [Read the code](https://github.com/the-momentum/open-wearables) ## Send us the questionnaire Most of it is answered by where the deployment runs. For the rest, we would rather answer in writing early than discover a blocker at signature. [Book a demo](https://openwearables.io/book) FAQ ## Common questions. ### Do you hold SOC 2 or ISO 27001? No. The deployment runs inside your certified environment, which is how most teams answer this in their own audit. ### Where does our health data live? In your cloud account, in the region you chose at setup. It does not pass through infrastructure of ours on the way in or out. ### Can your team access our deployment? Only when we work on your system, under a DPA you sign, and then only as named in it. There is no standing access and no support backdoor. ### Is the data encrypted? In the deployments we set up, yes, at rest and in transit. Managed storage is encrypted, connections to the database and cache are encrypted, and public access is HTTPS only. ### What happens to credentials? In the deployments we set up, they stay out of source control, separated per environment, and are handed over through an agreed secure channel rather than email or chat. ### How do you handle backups? In the deployments we set up, automated database backups with point-in-time recovery, running in your own account under your retention policy. ### Will you sign a data processing agreement? Yes, whenever our people can reach your deployment: under Pro support, during a Deployment or Integration service, and for as long as Enterprise runs. Where you self-host on Core, there is no processing for us to agree to, because we never touch it. If your legal team would rather work from your own template, that is normal and we review it. ### What else do you sign? A BAA comes with Enterprise, and depends on your cloud provider and your scope. It is a question of contract rather than of configuration, so it is worth settling early. ### Can we audit this? It is your account, so you can inspect it the way you inspect anything else you run. The software is MIT licensed, so your reviewers can read what it does rather than take our word for it. ### We are a small team without a security function. Is that a problem? It changes what you need from us rather than whether this works. That conversation belongs in scoping, and it is a normal one to have. --- Source: https://openwearables.io/sub-processors # Who can reach your data, in each model. Sub-processors Open Wearables runs in your cloud account, under your credentials. When you run it, we have no access. When we work on your system, we do it under a DPA you sign, and we name the sub-processors we use for that access. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) Two models, two answers ## It depends on who runs the deployment. ### If you run it yourself We are not in the data path. You deploy from the repository into your own cloud account, under your credentials. We have no access, no tenant and no copy of the data. ### If we support or maintain it The deployment still sits in your account. Our people reach it under a DPA you sign: we act as your processor, on your instructions, and we list the sub-processors we use for that access. Where you process for your own customers, we appear on their list too. [See Pro and Enterprise](https://openwearables.io/pricing#pro) In both models ## What stays true either way. ### The wearable data stays in one place It goes from the provider or the phone into your deployment, and out through your own API. Nothing about that path involves a service holding a copy on the way. ### Your cloud provider is not something we introduced AWS, Azure or Google Cloud is your contract, in your account, chosen by you. We do not sit between you and them, which is usually the difference between a short answer in a governance review and a long one. ### The sub-processors we use, where we work on it What we can reach, and the sub-processors we use to do it, are set out in the DPA you sign. Ask and we will send the list with the agreement. In your customer's review ## Who can reach the data, by how you add wearable data. The same question your customer's governance review asks, answered for each way of adding wearable data to your product. | | Hosted wearable API | Build it in-house | Open Wearables | | --- | --- | --- | --- | | [01] Who holds the wearable data | The vendor, in its tenant | You | You, in your own cloud account | | [02] Who can reach the data | The vendor and its sub-processors | Your team | Your team, and us under a DPA you sign when we work on it | | [03] Where access shows up | In the vendor's reports | In your own logs | In your own logs | For your own answer ## What to send your customer. Somebody asked you first. These sentences usually end the conversation. ### The wearable data stays in our own cloud account. It is deployed inside our infrastructure rather than called as a hosted service, so there is no vendor tenant between the device and our systems. - No vendor tenant ### No copy of member data leaves our account. Nothing in the path keeps a copy elsewhere. The platform runs in our own cloud account, under our own credentials. - No copy elsewhere ### Where the vendor works on it, their access is under a DPA we signed. It happens in our account, under our instructions, and shows in our own logs. The vendor acts as our processor and names the sub-processors it uses for that access. - Under a DPA What is not here ## What is never in the path. ### No analytics on health data Nothing samples or profiles your users' health data as it flows through your deployment. ### No shared infrastructure Deployments do not share a database, a queue or a cache with each other or with us. ### No model provider in the path Where you use the MCP server, the assistant you point at it is your choice and your contract. We are not between you and it. Related ## The rest of the review. ### [Security](https://openwearables.io/security) ### [What we sign](https://openwearables.io/what-we-sign) ### [Data residency](https://openwearables.io/data-residency) ### [Data governance](https://openwearables.io/data-governance) ## Send us the questionnaire If your customer's security review has landed and sub-processors are the question, bring us the clause. We will answer it for the way you run Open Wearables. [Book a demo](https://openwearables.io/book) FAQ ## Common questions. ### Our customer's security review asks about sub-processors. What do we say? That it runs in your cloud account, under your credentials, so wearable data does not reach a vendor tenant. When we work on your system, we do it under a DPA you sign, as your processor, with access to your deployment rather than a copy of the data, and we name the sub-processors we use for that access. ### Are you a processor or a sub-processor? Neither, where you run it yourself. Where we support or maintain it, we are your processor under a DPA you sign. If you process the data on behalf of your own customers, that also makes us a sub-processor in their chain. [What we sign](https://openwearables.io/what-we-sign) has the agreements. ### Does any of your tooling touch our users' health data? Where you run it yourself, we have no access at all. Where we work on it, what we can reach and the sub-processors we use are set out in the DPA you sign. ### What about our cloud provider? That contract is yours, in your account, with a provider you chose. We do not sit between you and them. ### Our governance board has to approve every sub-processor. Does this work? Yes. The data stays in your estate, so there is no aggregator holding it. Where we support or maintain the deployment, your board reviews us as a processor under a DPA, together with the sub-processors we use for that access. ### Can we get this in a signed document rather than a web page? Yes. The DPA you sign with us covers it, including the sub-processors we use. --- Source: https://openwearables.io/webhooks # Wearable events, pushed to your endpoint. Webhooks and delivery Health data does not arrive on a schedule. Open Wearables pushes each event to your endpoint once it is saved in your deployment, signed, retried if your service was down, with every attempt there to inspect. [Get started](https://openwearables.io/docs/quickstart) [Read the docs](https://openwearables.io/docs/api-reference/guides/webhooks) Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo Why push ## Polling asks. Push tells you. Polling checks every user on an interval, whether anything happened or not. Wiring each provider's own webhooks means a format and a signature scheme per provider. Open Wearables gives you one push for all of them. | | Poll each provider | Wire each provider's webhooks | Open Wearables webhooks | | --- | --- | --- | --- | | [01] How new data reaches you | You ask on an interval | Each provider calls you in its own format, some with only an ID to fetch | A signed POST when data is saved, in one schema | | [02] Requests to your service when nothing changed | Every interval, for every user | None | None | | [03] Providers without webhooks | Polled | Still polled, by you | Polled by Open Wearables, pushed to you | | [04] Signatures and retries | Not applicable | Different for every provider | One signature scheme, retries built in | | [05] Delivery log | Your own logs | Your own logs | Every attempt, from the API | Events ## What lands on your endpoint. Every delivery is a POST with a JSON body of two fields, type and data, in the same schema as the pull API, so the payload does not change shape with the provider. ### Session events. Fired once when a workout, a night of sleep, a generic activity or a menstrual cycle record is saved or merged. A field the provider did not report is null rather than missing. - workout.created - sleep.created ### Timeseries events. Fired per ingestion batch for each user, provider and series type, with the full samples array in the payload, so you store it without a follow-up request. Batches over 2,500 samples arrive in numbered chunks. - heart_rate.created - steps.created ### Connection and sync events. A revoked connection comes with its reason: a refresh token the provider rejected, a user who disconnected or signed out, or a deregistration on the provider's side. Sync events say when a sync starts, finishes or fails. - connection.revoked - sync.failed Delivery ## What happens when your endpoint is down. Delivery decides whether a webhook integration is something you trust or something you check by hand. All of it is in the deployment rather than on a pricing tier. 01 ### Automatic retries. A delivery counts as failed when your endpoint returns a non-2xx status or does not respond in time. It is retried at increasing intervals, for more than a day on the default schedule. 02 ### The same ID on every try. Each delivery carries an svix-id that stays the same across retries, so storing the IDs you received makes your handler safe against duplicates. 03 ### Every attempt on record. The attempts endpoint returns each try with the status code your server sent back and when it happened. 04 ### Data first. Delivery never holds up ingestion. The data is saved in your database either way, and the pull API returns it in the same schema. Security ## Every payload is signed. Each delivery carries three headers: a message ID, a timestamp and an HMAC signature. Checking them tells your endpoint the request came from your own deployment, not from anyone who found the URL. ### One call to verify wh.verify(body, headers) from the Svix library, in Python or Node, checks the signature and rejects deliveries older than five minutes. The manual recipe is in the docs for any other language. ### A secret per endpoint Each endpoint has its own signing key, fetched from the API and stored on your side. ### Verify before processing That is what stops a forged or replayed payload from reaching your business logic. Getting started ## From the first flag to the first event. Registration is an API call, so it belongs in the same infrastructure code as the rest of your deployment. There is also an admin panel for it if you would rather click. [Webhooks in the docs](https://openwearables.io/docs/api-reference/guides/webhooks) 01 ### Turn webhooks on Outgoing webhooks are off by default, so a deployment that does not need them does not emit anything. Set OUTGOING_WEBHOOKS_ENABLED=true in the backend environment and restart. 02 ### Register an endpoint One request with your URL. Add filter_types or a user_id to receive only some events. The response carries the endpoint's id. Terminal ``` $ curl -X POST localhost:8000/api/v1/webhooks/endpoints \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{"url": "https://yourapp.com/webhooks/health", "filter_types": ["sleep.created", "workout.created"]}' ``` 03 ### Fetch its signing secret Store it where your handler can read it. Terminal ``` $ curl localhost:8000/api/v1/webhooks/endpoints/{id}/secret \ -H "Authorization: Bearer $TOKEN" ``` 04 ### Send a test event An example payload for the event type you name, signed and sent the way a real one is, before a single user connects. Terminal ``` $ curl -X POST localhost:8000/api/v1/webhooks/endpoints/{id}/test \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{"event_type": "sleep.created"}' ``` 05 ### Read the attempts Every attempt with the status code your server returned, so the first failing handler shows up here. Terminal ``` $ curl localhost:8000/api/v1/webhooks/endpoints/{id}/attempts \ -H "Authorization: Bearer $TOKEN" ``` ## Run it in your own cloud Webhooks, the delivery log and the signing keys all sit inside your deployment, under an MIT licence. Run it yourself, or see what it costs to have us stand it up inside your account. [Get started](https://openwearables.io/docs/quickstart) [See pricing](https://openwearables.io/pricing) FAQ ## Do you have more questions? ### How fast do events arrive? Open Wearables sends an event once the data is saved in your deployment. What happens before that is the provider's: the path from a watch to a phone to the provider's cloud runs on each provider's own schedule. So we mirror the provider's latency rather than promise real time. ### Which providers support webhooks? It varies by provider. Some push data to Open Wearables, others have to be polled, and either way the event reaches your endpoint as a push. [The provider coverage in the docs](https://openwearables.io/docs/providers/supported) says how each one delivers. ### What happens if our endpoint is down for an hour? An hour is well inside the retries, which run at increasing intervals for more than a day on the default schedule, and the attempts endpoint shows each try with its status code. The data itself is already in your database, so the pull API returns it in the same schema whatever happened to the delivery. ### What should our endpoint return? A 2xx, as quickly as possible, before any heavy processing, with the slow work queued. Return it for events you ignore too, or they get retried. ### Can we receive only some events? Yes. An endpoint can be scoped by event type, by user, or both, and different endpoints can take different event types, routed however your services are split. ### Do we still need to poll for anything? Not for ongoing data. The pull API stays available for three things: backfilling a user's history when they first connect, reconciling after an outage, and recovering deliveries you missed. Same schema either way, so it is the same code path. ### Is this metered? No. Webhooks are part of the deployment, and the bill does not track how many events you receive or how many users generate them. ### Can we change what gets sent? The code that emits events is in a repository you cloned, so changing what a payload carries is a change you make rather than a feature you request. --- Source: https://openwearables.io/what-we-sign # Before your legal team asks. What we sign Paperwork is where a good technical conversation goes quiet for three weeks. This is our position on the documents a security review asks for, written down so it can be read early. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) What we sign ## The documents, and where we stand on each. ### Self-hosted: nothing to sign On Core you deploy MIT-licensed software into your own account. We never reach it, so there is no agreement and no processor relationship. ### A DPA whenever we reach it Whenever our people work on your running system, under Pro support, a Deployment or Integration service, or Enterprise, we sign a data processing agreement. The signing follows the access. ### A BAA if HIPAA applies A business associate agreement under Enterprise, where your cloud provider and your scope support it. ### Questionnaires answered by us Under Enterprise we fill in your customers' and auditors' security questionnaires, rather than leave them with you. Where the paperwork sits ## It follows who can reach your deployment. [Pricing](https://openwearables.io/pricing) 01 ### Core, self-hosted None of this applies. There is nothing to sign, because we are not party to anything you run yourself. 02 ### Pro, or a Deployment or Integration service A DPA covers the work while our people can reach the deployment, from onboarding to deployment and integration support. A deployment we set up comes with its region stated in writing. 03 ### Enterprise A signed DPA and, where supported, a BAA for as long as the agreement runs, security questionnaires and reviews answered by us, and SLA support. Boundaries ## Where our responsibility ends. ### We do not hold SOC 2 or ISO 27001. The deployment runs inside your certified environment, which is how most teams answer this in their own audit. If your procurement requires a vendor certificate regardless of architecture, tell us early. ### We do not hold your certification for you. For DiGA, CE marking or FDA clearance, we provide auditable inputs and tested releases. The clearance stays yours. ### We do not sign up to outcomes we cannot control. The path from a watch to a phone to a provider's cloud belongs to the provider. We commit to what happens once the data reaches your deployment, and say plainly where our responsibility starts. ## Send it to your legal team first This page exists so the paperwork conversation happens early rather than at signature. If there is a clause you know will be a problem, bring it to the first call. [Book a demo](https://openwearables.io/book) FAQ ## Common questions. ### Will you sign a DPA? Yes, whenever our people can reach your deployment: under Pro support, during a Deployment or Integration service, and for as long as Enterprise runs. Where you self-host on Core, there is no processing for us to agree to, because we never touch it. ### Will you sign a BAA? Under Enterprise, where it is supported. It depends on your cloud provider and your scope: the deployment runs on your infrastructure, so access, encryption, retention and logging are yours to control and to evidence. Tell us the scope and we will give you a straight answer. ### Do you hold SOC 2 or ISO 27001? No. The deployment runs inside your certified environment, which is how most teams answer this in their own audit. ### Our customer sent a sixty-page security questionnaire. Will you fill it in? Yes, under Enterprise, because it takes real time. Most of it is answered by where the deployment runs, so it is usually shorter work than it looks. ### We need a DiGA listing. Can you help? With the inputs, yes. With the clearance itself, no. We provide data a reviewer can audit and tested releases, and you hold the certification. That is a limit worth knowing before you plan a timeline around it. ### What happens if we stop working with you? The deployment and the data stay in your account, because they were never anywhere else. The agreement covers what we stop doing rather than what you have to retrieve. ### Our contract has a clause about sub-processors. Where do we stand? When you run the deployment yourselves, it is in your account and we are not party to it. When we support or maintain it, we act as your processor under a DPA you sign, and we name the sub-processors we use for that access. [The sub-processors page](https://openwearables.io/sub-processors) covers it in full. --- Source: https://openwearables.io/integrations/apple-health # Apple Health data, in your own cloud Apple Health integration HealthKit is where an iPhone keeps health data, and where the apps and devices a user already trusts write theirs. Open Wearables reads it through a mobile SDK in your own app and lands it in the same schema as the rest of your sources, self-hosted under an MIT licence. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo Data coverage ## Apple Health data we support HealthKit is the widest data set of any source we connect, and one permission grant reads across everything the user already routes into it. ### The widest set we support More data types than any other source, down to spirometry and falls. ### Sleep Stages, efficiency, time in bed, naps and breathing disturbances. ### Heart Heart rate, resting and recovery, HRV as SDNN, AFib burden. ### Vitals SpO2, respiratory rate, temperature, glucose and blood pressure. ### Body Weight, height, BMI, body fat, lean mass and waist. ### Activity Steps, energy, exercise and stand time, flights and distance. ### Gait and mobility Walking speed, step length, asymmetry, steadiness and stair speed. ### Performance VO2 max, power, speed, cadence and Apple's effort scores. ### Environment Audio exposure, time in daylight, UV and water temperature. One connection, many devices ## Devices we do not connect directly still arrive here Most wearables write to Apple Health through their own app, which makes HealthKit a route to hardware with no direct integration. A companion app usually writes a subset of what its own API exposes, so where we connect a provider directly and you need the full depth, connect it directly. [Browse integrations](https://openwearables.io/integrations) ### Watches and trackers Sports watches and fitness trackers, each through its own app. ### Rings and bands Smart rings and recovery bands that sync to Apple Health. ### Sleep and metabolic Sleep monitors and continuous glucose monitors. ### Medical devices Blood pressure monitors, ECG devices and body composition scales. ## What working with Open Wearables gives you Two views of the same deployment. One for the people wiring it in, one for the people signing it off. ### One schema, not one per provider Apple Health arrives in the same shape as every cloud source, so your code carries no iOS-specific branches and adding a watch integration later does not change the call. - Sleep - Vitals - Activity - Gait ### The SDK is the integration HealthKit has no cloud API, so reading it means code inside your app. That code is written, maintained and open, and your backend mints a short-lived user token, so the app secret never reaches the device. - Swift - Flutter - React Native ### Background sync that survives the OS HealthKit tells the SDK when new data is written, and a scheduled task covers the rest, so data arrives without the user opening your app. Each sync moves only what is new, from a first-sync depth you choose. - Background sync - Incremental ### An XML route for migrations A user's full Apple Health export can be imported directly, which is how you backfill years of history for someone switching to your product. Large files upload straight to your own object storage. - XML import - Your storage ### Access you control It runs in your cloud account, under your credentials. When we work on your system, we do it under a DPA you sign. - Your credentials - Your region ### No developer programme to apply to HealthKit access is a platform entitlement in your own app, not a partner agreement, so there is no approval queue between you and the data. - Your app - No approval queue ### Costs you can see Running it costs your own cloud bill, paid to your provider. Deployment and Integration are one-off services, and health scores and the other licensed modules come with Pro. - Your cloud bill - One-off services ### No dependency on us MIT licence, full source, public roadmap and public issues, plus community support on Discord. - MIT license - Full source - Discord How it works ## From nothing to your first Apple Health query [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) 01 ### Bring it up Clone the repository and run it with Docker Compose. First API call in five minutes, before any provider is connected. Terminal ``` $ git clone https://github.com/the-momentum/open-wearables.git $ cd open-wearables && docker compose up -d ``` 02 ### Add the SDK to your iOS app HealthKit data lives on the device, so this is where the integration happens rather than in a developer portal. Add the SDK, enable the [HealthKit](https://developer.apple.com/documentation/healthkit) capability in Xcode and declare the record types you need. [iOS SDK integration guide](https://openwearables.io/docs/sdk/ios/integration) 03 ### Ask the user for permission iOS shows its own HealthKit permission sheet, per data type, and the user decides what to share. Your app keeps its existing login, so there is no second account to manage. 04 ### Query the user, not the provider Apple Health data arrives in the same schema as every other source, in your own database, so your application code carries no iOS-specific branches. [Mobile SDKs](https://openwearables.io/platform/mobile-sdks) The honest comparison ## Hosted SaaS API, in-house build, or self-hosted Where each one actually wins. If a hosted API fits your situation, use one. | | Hosted SaaS API | Build in-house | Open Wearables, self-hosted | | --- | --- | --- | --- | | [01] The mobile SDK | Theirs, in your app | Yours to write and maintain | Open source, in your app, forkable | | [02] Where HealthKit data goes first | Their cloud | Yours | Your cloud account, your region | | [03] Permission sheet | Theirs or yours, depending | Yours | Apple's own, inside your app | | [04] The data model | Theirs, you build against their schema | Yours | Yours, in your database | | [05] Historical backfill | Whatever window they offer | Yours to build | Full XML export, into your storage | | [06] HealthKit changes | They absorb them | Your team tracks and adapts | Fixed in a release you pull | | [07] Cost shape | Scales with monthly active users | Salaries and infrastructure | Fixed, flattens as you grow | What stays yours ## The deployment, the data and what you build on it stay in your account, whoever runs it ### Sovereignty Apple Health data goes from the device to your cloud, with no aggregator in between. ### Residency It stays in the region you chose, provable by pointing at an account. ### Control What you build on top of Open Wearables is yours, and the schema and the data are in your account. ### Your own reasons No regulator forcing it. You want the data in your own account anyway. ## Apple Health is one integration in the same API You query a user rather than a provider, so somebody on an iPhone and somebody wearing a ring you connect through the cloud both come back in one shape. Adding either later does not change your code. [Browse all integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## Deploy Open Wearables in your own cloud The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account with the SDK live in your app and validated on real devices. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) FAQ ## Do you have more questions? ### What is HealthKit? Apple's health data store on iPhone and Apple Watch. Apps and devices write what they measured into one place on the device, and other apps read it with the user's permission, so it works as a hub rather than as one more device API. ### Do we need a developer account or an approval? You need an Apple Developer account to ship any iOS app, and HealthKit is an entitlement you enable on your own app. There is no separate partner programme, no review queue and no agreement to negotiate with Apple for access to the data. ### Do we have to build a mobile app for this? Not necessarily. HealthKit data never leaves the iPhone on its own, so an app has to read it: our SDK inside your own iOS app, or the [Connect App](https://openwearables.io/platform/connect-app) if you have none. If you only need history rather than continuous sync, a user's XML export can be imported without any app at all. ### Which SDKs are available? Native iOS in Swift, plus Flutter and React Native wrappers over the same native core. The Android SDK covers Health Connect and Samsung Health on the other platform, so a cross-platform app uses one integration for both. ### How does the data actually get to us? The SDK reads HealthKit and pushes to your deployment. Two things keep it arriving without the user opening your app: HealthKit notifies the SDK when new data is written, and a background task runs on a schedule to catch the rest. iOS decides how often that task runs, so treat it as regular rather than exact. Each run moves only what is new. ### How far back does the first sync go? As far as you choose: the last ninety days, the last thirty, or everything HealthKit holds, which is the default. The depth persists, so later syncs follow the same rule. ### Can we import a user's full history? Yes. Apple Health exports everything to XML, and that file can be imported directly, which is the usual route when someone migrates to your product with years of history behind them. Large exports upload to your own object storage rather than through the API. The [XML import guide](https://openwearables.io/docs/api-reference/guides/apple-xml-import) has the detail. ### Will data from a Garmin or an Oura arrive this way? Often yes, because most companion apps write to Apple Health. That makes this integration a route to hardware we do not connect directly. One caveat worth planning for: a companion app usually writes a subset of what its own API exposes, so where we have a direct integration and you need full depth, connect it directly. ### How is heart rate variability reported? As SDNN, typically measured during sleep or rest. That matters if you are comparing against a source that reports RMSSD, because the two are different measures and should not be treated as interchangeable inside one score. ### Is anything missing from sleep? Stages, duration and time in bed all arrive. Heart rate, heart rate variability and blood oxygen measured during sleep are not yet attached to the sleep record itself, though they arrive as time series you can query across the same window. ### Can we combine Apple Health with other sources? Yes, and that is the normal case. You query a user rather than a provider, so somebody with an iPhone and a connected ring returns in one shape. --- Source: https://openwearables.io/integrations/fitbit # Fitbit data now comes through the Google Health API Fitbit integration Google ended support for the legacy Fitbit Web API on 30 September 2026 and turns it off on 30 October. Fitbit data has not gone away: Google aggregates it at the account level, and the Google Health API reads that layer, in the same schema and the same deployment you already run. [Google Health API integration](https://openwearables.io/integrations/google-health) [Read the migration guide](https://openwearables.io/blog/fitbit-web-api-shutdown-2026-migration-guide) Where things stand ## What this means in practice [Google's timeline](https://developers.google.com/health/about) ### The Web API turns off Support ended on 30 September 2026, and on 30 October the API stops syncing data to or from Fitbit users. ### Existing connections sync until then Workouts keep flowing for accounts already connected, up to the turn-off date Google has set. ### No new Fitbit builds Every integration has to move to the Google Health API, so starting on the Fitbit Web API now is work that expires within weeks. ### The integration is frozen Sleep, intraday heart rate and daily summaries exist in the Web API, and we will not be adding them. ### Your data stays where it is Everything already synced sits in your own deployment and schema, and the turn-off does not touch it. Until the turn-off ## What Fitbit still returns For connections that already exist, workouts continue in the same schema as every other source. ### Workouts Calories, steps, distance and minimum, average and maximum heart rate. ### Activity types Mapped to one sport taxonomy, with a fallback for anything unrecognised. ### Device name Which Fitbit recorded the session. The path forward ## The Google Health API Google now aggregates Fitbit data at the account level, and the Google Health API reads that layer, so Fitbit data keeps arriving after the Web API is gone. [Google Health API integration](https://openwearables.io/integrations/google-health) ### Not to be confused with Health Connect Health Connect is an on-device Android layer that needs a mobile SDK in your app. The Google Health API is a cloud integration with OAuth, and it is the one that carries Fitbit data. ### What changes Users connect to Google rather than to Fitbit, and Fitbit tokens cannot be carried over, so every user re-consents once through Google. ### What you gain Sleep with stages, continuous heart rate, heart rate variability, blood oxygen, respiratory rate and VO2 max, none of which the Fitbit path gives you today. ### What stays the same Same schema, same deployment, same cloud account, so your application code does not change. ## Keep Fitbit data flowing The Google Health API carries Fitbit data in the same schema and deployment you already run. Your code stays as it is. [Google Health API integration](https://openwearables.io/integrations/google-health) [Book a demo](https://openwearables.io/book) FAQ ## Do you have more questions? ### When exactly does the Fitbit Web API shut down? Support ended on 30 September 2026, and on 30 October 2026 the API is turned off and stops syncing data to or from Fitbit users. [Google's announcement](https://developers.google.com/health/about) has the full timeline. ### Our integration is live today. Will it break before then? Existing connections keep syncing workouts until the turn-off on 30 October. Google no longer supports the API, though, so plan the move now rather than at the deadline. ### Can we still set up a new Fitbit integration? Not one worth building. Every integration has to move to the Google Health API, and the Web API turns off within weeks, so a new build would stop working almost as soon as it shipped. ### Why are you not adding sleep and heart rate for Fitbit? Both exist in the Fitbit Web API, and both stop working when it turns off. Building them would mean shipping features with a known expiry date, so that effort goes into the Google Health API path instead. ### What happens to the Fitbit data we have already synced? It stays in your own deployment, in your own schema, under your own credentials. The turn-off affects what arrives next, not what you already hold. ### Is the Google Health API a replacement or a workaround? A replacement, and Google's own successor to the Fitbit Web API. It also gives you sleep with stages, continuous heart rate, heart rate variability and blood oxygen, which the Fitbit path does not. One thing to plan for: Fitbit tokens cannot be carried over, so every user re-consents through Google. ### Is that the same as Health Connect? No, and the difference matters when you plan the work. Health Connect is an on-device layer on Android, so reading it means integrating a mobile SDK into your own app. The Google Health API is a cloud integration with OAuth, no mobile work involved, and it is the one that carries Fitbit data. For a Fitbit migration, the cloud path is the answer. ### How much work is the migration? The schema does not change, so your application code does not either. What changes is which provider a user authorises, and every user re-consents once. The [migration guide](https://openwearables.io/blog/fitbit-web-api-shutdown-2026-migration-guide) has the detail. ### Does Fitbit have an API at all after this? Google serves Fitbit data through the Google Health API rather than a standalone Fitbit API. That is the interface to build against. --- Source: https://openwearables.io/integrations/garmin # Garmin's full data set, running in your own cloud Garmin integration One API for Garmin and for the rest of the wearables your users own, connected through the official Connect Developer Program and returned in a single schema. Self-hosted in a cloud account you control, under an MIT licence. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo Data coverage ## Garmin data we support Everything below arrives in one schema, including Garmin's own readouts such as Body Battery, Fitness Age and Stress Level. ### Workouts Sessions with distance, energy burned and the heart rate range. ### Sleep Stages, efficiency, time in bed and naps. ### Daily summaries Steps, energy, active time and floors climbed. ### Time series Heart rate, heart rate variability, resting heart rate and respiratory rate. ### Body composition Weight, body fat, skeletal muscle mass and skin temperature. ### Vitals Blood pressure and oxygen saturation. ### Performance VO2 max, cadence, power and speed. ### Location Latitude, longitude, elevation and air temperature. ### Women's health Cycle phase, fertile window and pregnancy snapshot. ## What working with Open Wearables gives you Two views of the same deployment. One for the people wiring it in, one for the people signing it off. ### One schema, not one per provider Garmin arrives in the same shape as every other source, so your code carries no Garmin-specific branches and adding a source later does not change the call. - Activities - Sleep - HRV - Dailies - Stress ### The awkward parts already handled Token lifecycle, the callback endpoint Garmin pushes to, and backfill coordination so several of your user profiles behind one Garmin account do not collide. - OAuth 2.0 - Push webhooks - 30-day backfill - Rate limits handled ### Garmin changes handled for you When Garmin changes something, the fix ships in a project release rather than landing in your sprint. - Garmin test suite - Update with git pull ### Health scores computed in your deployment Garmin's own sleep score, Body Battery and stress level arrive as data, as Garmin calculates them. Health scores from our science team run alongside them inside your deployment, validated before release, and are part of Pro. - Garmin scores - Health scores ### Access you control It runs in your cloud account, under your credentials. When we work on your system, we do it under a DPA you sign. - Your credentials - Your region ### The Garmin relationship stays yours Credentials issued in your name, data going straight from Garmin into your account. - Garmin Developer Program - Your OAuth app - Approval required ### Costs you can see Running it costs your own cloud bill, paid to your provider. Deployment and Integration are one-off services, and health scores and the other licensed modules come with Pro. - Your cloud bill - One-off deployment ### No dependency on us Stop working with us and the deployment keeps running, with the code already in your repository. - MIT license - Full source - Public roadmap - Public issues - Discord How it works ## From nothing to your first Garmin query [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) 01 ### Bring it up Clone the repository and run it with Docker Compose. First API call in five minutes, before any provider is connected. Terminal ``` $ git clone https://github.com/the-momentum/open-wearables.git $ cd open-wearables && docker compose up -d ``` 02 ### Get your Garmin credentials The slow part, so start here. Garmin issues them to organisations rather than individuals, and they stay in your name, so the data relationship is between you and Garmin. 03 ### Connect a user Your user authorises through Garmin's own consent screen. Open Wearables handles the flow and the token lifecycle, and your deployment hosts the callback endpoint Garmin pushes to. 04 ### Query the user, not the provider Garmin data arrives in the same schema as every other source, in your own database, so your application code carries no Garmin-specific branches. [Garmin setup guide](https://openwearables.io/docs/providers/garmin-api-integration) The honest comparison ## Hosted SaaS API, in-house build, or self-hosted Where each one actually wins. If a hosted API fits your situation, use one. | | Hosted SaaS API | Build in-house | Open Wearables, self-hosted | | --- | --- | --- | --- | | [01] Garmin credentials | Theirs, already approved | Yours to obtain | Yours, in your own name | | [02] The approval wait | None for you | Yours to sit through | Yours, and we start it on day one | | [03] Callback endpoint | They host it | You build and host it | Your deployment hosts it, code included | | [04] Where Garmin data sits | Their cloud, their regions | Yours | Your cloud account, your region | | [05] The data model | Theirs, you build against their schema | Yours | Yours, in your database | | [06] Garmin API changes | They absorb them | Your team tracks and adapts | Fixed in a release you pull | | [07] Cost shape | Scales with monthly active users | Salaries and infrastructure | Fixed, flattens as you grow | What stays yours ## The deployment, the data and what you build on it stay in your account, whoever runs it ### Sovereignty Garmin data goes straight to your cloud, with no aggregator in between. ### Residency Garmin data stays in the region you chose, provable by pointing at an account. ### Control What you build on top of Open Wearables is yours, and the schema and the data are in your account. ### Your own reasons No regulator forcing it. You want the data in your own account anyway. ## Garmin is one integration in the same API You query a user rather than a provider, so somebody with a Garmin watch and a ring comes back in one shape. Adding the ring later does not change your code. [Browse all integrations](https://openwearables.io/integrations) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## Deploy Open Wearables in your own cloud The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account with Garmin connected and validated on real accounts. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) FAQ ## Do you have more questions? ### Do we need our own Garmin credentials? Yes. Garmin issues them to your organisation, and you apply directly. Open Wearables handles the connection flow, the token lifecycle and the callback endpoint, but the account and the data relationship are yours. ### What is the state of the Garmin developer programme? Garmin controls it and the status changes. As of the last check for our documentation, new developer accounts were not being issued while existing accounts continued to work. The Garmin setup guide in our docs carries the current position, and Garmin's own access request form is the authority. ### I want access to my own Garmin data. Can I use this? Not through the official route. Garmin's developer programme is for organisations and rejects personal-use applications, which is their rule rather than ours. You can still clone the repository and run Open Wearables yourself, and the Discord is open, but the Garmin credentials are the part we cannot solve for an individual. ### Which Garmin APIs does this cover? Garmin Connect provides the Health, Activity, Women's Health, Training and Courses APIs. What Open Wearables reads from them, and which data types arrive, is in the [coverage matrix](https://openwearables.io/docs/providers/supported). ### Does it handle Garmin's push callbacks? Yes. Garmin pushes data rather than waiting to be polled, so a callback endpoint has to exist and stay reachable. Your deployment hosts it, and the code for it is in the repository. ### What about historical data? Garmin backfill runs as a request-and-wait chain rather than a single call, and Garmin does not allow concurrent backfills on one account. Open Wearables coordinates that so several of your user profiles behind one Garmin account do not collide. ### Can we combine Garmin with other sources? Yes, and that is the normal case. You query a user rather than a provider, so a person with a Garmin watch and a second device returns in one shape. ### We already have Garmin credentials. What changes? Then the slow part is behind you. Bring the client ID and secret, point the deployment at your callback, and the connection flow works from there. --- Source: https://openwearables.io/integrations/google-health # Google Health API data from every app, in your own cloud Google Health API integration One API for Google Health and for the rest of the wearables your users own, connected through the official Google Health API and returned in a single schema. Self-hosted in a cloud account you control, under an MIT licence. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo Data coverage ## Google Health data we support Google aggregates data at the account level, so one connection reads whatever the user's apps and devices contribute, in the same schema as every other source. ### Many sources, one link Fitbit, Health Connect, Google Fit and other apps, reconciled by Google. ### Sleep Stages, duration, time in bed, efficiency and naps. ### Heart Heart rate, resting heart rate and HRV as both RMSSD and SDNN. ### Vitals SpO2, respiratory rate and VO2 max. ### Activity Steps, active and basal energy, distance and hydration. ### Body Weight, body fat, body temperature and blood glucose. ### Workouts Energy, distance, steps, average heart rate, speed, elevation and cadence. ## What working with Open Wearables gives you Two views of the same deployment. One for the people wiring it in, one for the people signing it off. ### One schema, not one per provider Google Health arrives in the same shape as every other source, so your code carries no Google-specific branches and adding a source later does not change the call. - Sleep - Heart - Activity - Workouts ### Deduplicated across apps, by Google When a watch and two apps all write steps, Google reconciles them into the figure the user sees in their own app. Or switch, once, to the raw per-source points when you need to know which device recorded a reading. - Reconciled - Raw per source ### Webhooks and polling, both handled Google sends a notification carrying only the changed window, and Open Wearables pulls that window over REST. Subscriptions live at the project level, registered by the deployment or by your own team with gcloud. - Webhooks - Polling ### Tokens on rails Access tokens refresh before they expire, with concurrent syncs coordinated so one user's refresh cannot race itself. A connection keeps working until the user revokes it. - OAuth 2.0 - Refresh handled ### Access you control It runs in your cloud account, under your credentials. When we work on your system, we do it under a DPA you sign. - Your credentials - Your region ### The Google relationship stays yours Credentials and the Google Cloud project are in your name, data going straight from Google into your account. - Your GCP project - Your credentials ### Costs you can see Running it costs your own cloud bill, paid to your provider. Deployment and Integration are one-off services, and health scores and the other licensed modules come with Pro. - Your cloud bill - One-off services ### No dependency on us MIT licence, full source, public roadmap and public issues, plus community support on Discord. - MIT license - Full source - Discord How it works ## From nothing to your first Google Health query [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) 01 ### Bring it up Clone the repository and run it with Docker Compose. First API call in five minutes, before any provider is connected. Terminal ``` $ git clone https://github.com/the-momentum/open-wearables.git $ cd open-wearables && docker compose up -d ``` 02 ### Set up your Google Cloud project Enable the [Google Health API](https://developers.google.com/health) in your own Google Cloud project and create an OAuth client. Everything stays under your project, so the data relationship is between you and Google. [Google Cloud Console](https://console.cloud.google.com/) 03 ### Connect a user Your user authorises through Google's own consent screen, granting access per data category rather than all at once. Open Wearables handles the token lifecycle from there, including the refresh that keeps the connection alive months later. 04 ### Query the user, not the provider Google Health data arrives in the same schema as every other source, in your own database, so your application code carries no Google-specific branches. [Google Health API setup guide](https://openwearables.io/docs/providers/google-api-integration) The honest comparison ## Hosted SaaS API, in-house build, or self-hosted Where each one actually wins. If a hosted API fits your situation, use one. | | Hosted SaaS API | Build in-house | Open Wearables, self-hosted | | --- | --- | --- | --- | | [01] Google credentials and project | Theirs | Yours to set up | Yours, in your own project | | [02] Overlapping sources | Whatever they pass through | Yours to resolve | Merged by Google, or raw if you prefer | | [03] Webhook subscriptions | They host them | Service account work you build | Registered through your project | | [04] Where Google Health data sits | Their cloud, their regions | Yours | Your cloud account, your region | | [05] The data model | Theirs, you build against their schema | Yours | Yours, in your database | | [06] Google API changes | They absorb them | Your team tracks and adapts | Fixed in a release you pull | | [07] Cost shape | Scales with monthly active users | Salaries and infrastructure | Fixed, flattens as you grow | What stays yours ## The deployment, the data and what you build on it stay in your account, whoever runs it ### Sovereignty Google Health data goes straight to your cloud, with no aggregator in between. ### Residency It stays in the region you chose, provable by pointing at an account. ### Control What you build on top of Open Wearables is yours, and the schema and the data are in your account. ### Your own reasons No regulator forcing it. You want the data in your own account anyway. ## Google Health is one integration in the same API You query a user rather than a provider, so somebody whose data arrives through Google and somebody wearing a ring you connect directly both come back in one shape. Adding either later does not change your code. [Browse all integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## Deploy Open Wearables in your own cloud The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account with Google Health connected and validated on real accounts. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) FAQ ## Do you have more questions? ### What is the Google Health API? Google's cloud interface to the health data on a user's Google account. Rather than connecting to each app separately, you connect once to Google and read whatever that account holds, already merged across contributing sources. ### Is this the same as Health Connect? No, and the difference decides how much work the integration is. Health Connect is an on-device layer on Android, so reading it means shipping a mobile SDK inside your own app. The Google Health API is a cloud integration with OAuth and no mobile work at all. Both land in the same schema, but they are separate integrations with separate setup. The [Health Connect integration](https://openwearables.io/integrations/google-health-connect) covers the on-device path. ### Does this give us Fitbit data? Yes, and once the legacy Fitbit Web API turns off on 30 October 2026, this is how Fitbit data continues to arrive. Google aggregates Fitbit at the account level, so it comes through this connection alongside everything else the user contributes. One thing to plan for: Fitbit tokens cannot be carried over, so every user re-consents through Google. The [Fitbit page](https://openwearables.io/integrations/fitbit) has the detail, and Google publishes its own [migration guide](https://developers.google.com/health/migration). ### What does deduplication actually mean here? If a user has a watch and two fitness apps all recording steps, you would normally receive three overlapping figures and have to decide which is right. Google resolves that before the data reaches you, matching what the user sees in their own Google Health app. You can also ask for the raw per-source datapoints instead, if you would rather do that reconciliation yourself. ### Do we get one merged figure or every source separately? Both are available, and merged is the default. Reconciled data matches what the user sees in their own Google Health app, which is usually what a product wants to display. Switching to the raw per-source points keeps device attribution, at the cost of resolving the overlap yourself. Daily totals for basal energy are derived on Google's side and arrive anchored to calendar days. ### Does it support webhooks? Yes. Google notifies your endpoint when data changes, carrying only the window that changed, and Open Wearables pulls that window over REST. Subscriptions are registered per project rather than per user, by the deployment or by your own team with gcloud. ### What do we need on the Google side? Your own Google Cloud project with the Health API enabled and an OAuth client. For the deployment to register webhook subscriptions itself, it also needs credentials for that project, such as a service account key. All of it stays in your name. ### Which scopes does this need? Google splits access by data category, so activity and fitness, health metrics, sleep, nutrition and settings each have their own read scope. You request the ones your product needs rather than one blanket permission, which is easier to justify on a consent screen. The [setup guide in the docs](https://openwearables.io/docs/providers/google-api-integration) has the exact strings. ### How many workout types does it recognise? The widest set of any source we connect, all mapped to the same taxonomy your other providers use. The [coverage matrix](https://openwearables.io/docs/providers/coverage) in the docs carries the current figure. ### Can we combine Google Health with other sources? Yes. Google covers whatever the user routes through their Google account, and a ring or a watch you connect directly covers the rest. You query the user, not each provider. --- Source: https://openwearables.io/integrations/google-health-connect # Health Connect data, in your own cloud Health Connect integration Health Connect is the shared health store on Android, where the phone and the apps a user already trusts write their data. Open Wearables reads it through a mobile SDK in your own app and lands it in the same schema as every other source, self-hosted under an MIT licence. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo Data coverage ## Health Connect data we support One permission grant reads across everything the user already connected, and the first sync can reach as far back as the store holds. ### Time series Timestamped samples rather than daily totals. ### Sleep Stages, efficiency, time in bed and naps. ### Heart Heart rate, resting heart rate, HRV as RMSSD and blood pressure. ### Body Weight, height, BMI, fat, lean and skeletal muscle mass. ### Vitals SpO2, respiratory rate, body temperature and blood glucose. ### Activity Steps, energy, distance, floors climbed and hydration. ### Performance VO2 max, power, speed, cadence, METs and running form. ### Workouts Heart rate range, energy, distance, elevation and speed. One connection, many apps ## Apps we do not connect directly still arrive here Most fitness apps and wearables on Android write to Health Connect, which makes it a route to sources with no direct integration. A companion app usually writes a subset of what its own API exposes, so where we connect a provider directly and you need the full depth, connect it directly. [Browse integrations](https://openwearables.io/integrations) ### Watches and trackers Wearables that sync to Health Connect through their own app. ### Rings and bands Smart rings and recovery bands that sync to Health Connect. ### Training apps Running, cycling and indoor training apps that log their sessions. ### Smart scales Scales that log weight and body composition through their own app. ## What working with Open Wearables gives you Two views of the same deployment. One for the people wiring it in, one for the people signing it off. ### One schema, not one per provider Health Connect arrives in the same shape as every cloud source, so your code carries no Android-specific branches and adding a watch integration later does not change the call. - Sleep - Body - Vitals - Activity ### The SDK is the integration Health Connect has no cloud API, so reading it means code inside your app. That code is written, maintained and open, and your backend mints a short-lived user token, so the app secret never reaches the device. - Kotlin - Flutter - React Native ### Background sync that survives the OS WorkManager schedules it and a foreground service carries it while it runs. Each sync moves only what is new, from a first-sync depth you choose: ninety days, thirty, or everything the store holds. - WorkManager - Incremental ### Per-app attribution kept Every record carries the name of the app that wrote it, along with the device model where the app reported one, so a reading from a chest strap app and one from the phone stay distinguishable. - Source app - Device model ### Access you control It runs in your cloud account, under your credentials. When we work on your system, we do it under a DPA you sign. - Your credentials - Your region ### No developer programme to apply to Health Connect access is a platform permission, not a partner agreement, so there is no approval queue between you and Android data. - Your app - No approval queue ### Costs you can see Running it costs your own cloud bill, paid to your provider. Deployment and Integration are one-off services, and health scores and the other licensed modules come with Pro. - Your cloud bill - One-off services ### No dependency on us MIT licence, full source, public roadmap and public issues, plus community support on Discord. - MIT license - Full source - Discord How it works ## From nothing to your first Health Connect query [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) 01 ### Bring it up Clone the repository and run it with Docker Compose. First API call in five minutes, before any provider is connected. Terminal ``` $ git clone https://github.com/the-momentum/open-wearables.git $ cd open-wearables && docker compose up -d ``` 02 ### Add the SDK to your Android app Health Connect data lives on the device, so this is where the integration happens rather than in a developer portal. Add the [Android SDK](https://github.com/the-momentum/open_wearables_android_sdk) as a Gradle dependency, point it at your deployment and declare the [Health Connect](https://developer.android.com/health-and-fitness/health-connect) record types you need. [Android SDK integration guide](https://openwearables.io/docs/sdk/android/integration) 03 ### Ask the user for permission Android shows its own Health Connect permission screen, per data type, and the user decides what to share. Your app keeps its existing login, so there is no second account to manage. 04 ### Query the user, not the provider Health Connect data arrives in the same schema as every other source, in your own database, so your application code carries no Android-specific branches. [Mobile SDKs](https://openwearables.io/platform/mobile-sdks) The honest comparison ## Hosted SaaS API, in-house build, or self-hosted Where each one actually wins. If a hosted API fits your situation, use one. | | Hosted SaaS API | Build in-house | Open Wearables, self-hosted | | --- | --- | --- | --- | | [01] The mobile SDK | Theirs, in your app | Yours to write and maintain | Open source, in your app, forkable | | [02] Where Android data goes first | Their cloud | Yours | Your cloud account, your region | | [03] Permission screen | Theirs or yours, depending | Yours | Android's own, inside your app | | [04] The data model | Theirs, you build against their schema | Yours | Yours, in your database | | [05] Per-app attribution | Whatever they pass through | Yours to preserve | Kept on every record | | [06] Health Connect changes | They absorb them | Your team tracks and adapts | Fixed in a release you pull | | [07] Cost shape | Scales with monthly active users | Salaries and infrastructure | Fixed, flattens as you grow | What stays yours ## The deployment, the data and what you build on it stay in your account, whoever runs it ### Sovereignty Android health data goes from the device to your cloud, with no aggregator in between. ### Residency It stays in the region you chose, provable by pointing at an account. ### Control What you build on top of Open Wearables is yours, and the schema and the data are in your account. ### Your own reasons No regulator forcing it. You want the data in your own account anyway. ## Health Connect is one integration in the same API You query a user rather than a provider, so somebody whose phone writes to Health Connect and somebody wearing a ring you connect through the cloud both come back in one shape. Adding either later does not change your code. [Browse all integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## Deploy Open Wearables in your own cloud The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account with the SDK live in your app and validated on real devices. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) FAQ ## Do you have more questions? ### What is Health Connect? Android's shared health store. Apps write what they measured into one place on the device, and other apps read it with the user's permission, so it works as a hub rather than as one more device API. It ships with Android 14 and later, and installs from the Play Store on Android 10 to 13. ### Is this the same as the Google Health API? No, and the difference decides how much work the integration is. Health Connect is on-device, so reading it means shipping a mobile SDK inside your own app. The Google Health API is a cloud integration with OAuth and no mobile work at all. Both land in the same schema, but they are separate integrations with separate setup. See the [Google Health API integration](https://openwearables.io/integrations/google-health). ### Do we need a developer account or an approval? No. Health Connect access is a platform permission the user grants on their own device, so there is no application form, no review queue and no partner agreement. That is the main reason this integration can ship in the time a cloud provider spends waiting for approval. ### Do we have to build a mobile app for this? Not necessarily. Health Connect data never leaves the phone on its own, so an app has to read it. If you already have an Android app, this is an SDK addition. If you do not, the [Connect App](https://openwearables.io/platform/connect-app) reads it for you, and the Google Health API reaches some of the same data through the cloud without any mobile work. ### Which SDKs are available? Native Android in Kotlin, plus Flutter and React Native wrappers over the same native core. The iOS SDK covers Apple Health on the other platform, so a cross-platform app uses one integration for both. ### How does the data actually get to us? The SDK reads Health Connect and pushes to your deployment. Background sync is scheduled through WorkManager, with a foreground service carrying an active sync, and each run moves only what is new. Your users do not have to open the app for data to arrive. ### Can we limit how much history we pull on the first sync? Yes. Set the depth in days, for example the last ninety, and the SDK syncs from the start of that day forward. The setting persists for later syncs. The default reads everything the store holds. ### How is heart rate variability reported? As RMSSD. That matters if you are comparing against a source that reports SDNN, such as Apple Health, because the two are different measures and should not be treated as interchangeable inside one score. ### Does per-app attribution survive? Yes. Every record keeps the name of the app that wrote it, so a reading from a chest strap app and a manual entry are distinguishable after they land in your database. ### What happens when a user signs out or revokes permission? Signing out clears the credentials on the device, and calling the disconnect endpoint before that reports it to your backend, so the connection is marked revoked rather than sitting idle. Permissions revoked in Android settings cannot be reported, because the SDK never runs again, so treat a connection that stops uploading as its own signal. ### Can we combine Health Connect with other sources? Yes, and that is the normal case. You query a user rather than a provider, so somebody with an Android phone and a connected ring returns in one shape. --- Source: https://openwearables.io/integrations/oura # Oura Ring API sleep and readiness, in your own cloud Oura integration One API for Oura and for the rest of the wearables your users own, connected through the official Oura developer API and returned in a single schema. Self-hosted in a cloud account you control, under an MIT licence. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo Data coverage ## Oura data we support Everything below arrives in one schema, including Oura's own sleep, readiness and activity scores. ### Sleep Stages in 30-second epochs, efficiency, time in bed and naps. ### Readiness Oura's daily readiness score, its read on recovery. ### Activity Activity score, steps, active calories and walking distance. ### Heart rate Samples across the day and night, plus resting heart rate. ### Heart rate variability RMSSD at five-minute intervals through the night. ### Blood oxygen SpO2, breathing disturbance and respiratory rate. ### Heart health VO2 max and cardiovascular age. ### Skin temperature Deviation and trend against the user's own baseline. ### Workouts Activity type, intensity, calories, distance and duration. ## What working with Open Wearables gives you Two views of the same deployment. One for the people wiring it in, one for the people signing it off. ### One schema, not one per provider Oura arrives in the same shape as every other source, so your code carries no Oura-specific branches and adding a source later does not change the call. - Sleep - Readiness - Activity - Heart rate ### Webhooks and tokens, renewed for you Switch live sync to webhook mode and the subscriptions are created for you, one per data type. They expire after ninety days, so a monthly job renews them, and token refresh keeps a user connected in January syncing in December. - Webhooks - Monthly renewal - OAuth 2.0 ### Continuous data, not just daily totals Heart rate arrives across the day and night, HRV at five-minute intervals through sleep and sleep stages in thirty-second epochs, so you can look at a night rather than one number for it. - 24/7 heart rate - 30-second sleep stages ### Health scores computed in your deployment Oura's own sleep, readiness and activity scores arrive as data, as Oura calculates them. Health scores from our science team run alongside them inside your deployment, validated before release, and are part of Pro. - Oura scores - Health scores ### Access you control It runs in your cloud account, under your credentials. When we work on your system, we do it under a DPA you sign. - Your credentials - Your region ### The Oura relationship stays yours Credentials issued in your name, data going straight from Oura into your account. - Your Oura app - Self-serve ### Costs you can see Running it costs your own cloud bill, paid to your provider. Deployment and Integration are one-off services, and health scores and the other licensed modules come with Pro. - Your cloud bill - One-off services ### No dependency on us MIT licence, full source, public roadmap and public issues, plus community support on Discord. - MIT license - Full source - Discord How it works ## From nothing to your first Oura query [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) 01 ### Bring it up Clone the repository and run it with Docker Compose. First API call in five minutes, before any provider is connected. Terminal ``` $ git clone https://github.com/the-momentum/open-wearables.git $ cd open-wearables && docker compose up -d ``` 02 ### Register your Oura app Create an application at cloud.ouraring.com and bring the client ID and secret. Oura is self-serve, so this is minutes rather than weeks, and the credentials stay in your name. [Oura developer portal](https://cloud.ouraring.com/) 03 ### Connect a user Your user authorises through Oura's own consent screen. Open Wearables requests the scopes it needs and handles the token lifecycle, including the refresh that keeps the connection alive months later. 04 ### Query the user, not the provider Oura data arrives in the same schema as every other source, in your own database, so your application code carries no Oura-specific branches. [Oura API setup guide](https://openwearables.io/docs/providers/oura-api-integration) The honest comparison ## Hosted SaaS API, in-house build, or self-hosted Where each one actually wins. If a hosted API fits your situation, use one. | | Hosted SaaS API | Build in-house | Open Wearables, self-hosted | | --- | --- | --- | --- | | [01] Oura credentials | Theirs, already approved | Yours to obtain | Yours, in your own name | | [02] Time to credentials | None for you | Short, Oura is self-serve | Short, and the setup guide is written | | [03] Webhook endpoint | They host it | You build, host and renew it | Your deployment hosts it, renewal automated | | [04] Where Oura data sits | Their cloud, their regions | Yours | Your cloud account, your region | | [05] The data model | Theirs, you build against their schema | Yours | Yours, in your database | | [06] Oura API changes | They absorb them | Your team tracks and adapts | Fixed in a release you pull | | [07] Cost shape | Scales with monthly active users | Salaries and infrastructure | Fixed, flattens as you grow | What stays yours ## The deployment, the data and what you build on it stay in your account, whoever runs it ### Sovereignty Oura data goes straight to your cloud, with no aggregator in between. ### Residency It stays in the region you chose, provable by pointing at an account. ### Control What you build on top of Open Wearables is yours, and the schema and the data are in your account. ### Your own reasons No regulator forcing it. You want the data in your own account anyway. ## Oura is one integration in the same API You query a user rather than a provider, so somebody with a ring and a watch comes back in one shape. Adding the watch later does not change your code. [Browse all integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## Deploy Open Wearables in your own cloud The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account with Oura connected and validated on real accounts. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) FAQ ## Do you have more questions? ### Does Oura have an API? Yes. The Oura API is an official developer API with OAuth, and you register an application at cloud.ouraring.com to get a client ID and secret. It is self-serve, so you are not waiting on an approval queue. ### Which version of the Oura API does this use? Version two, against api.ouraring.com/v2. That is the current one and the one Oura documents. ### Do we need our own Oura credentials? Yes, and that is the point. The application is registered in your name, so the data relationship is between you and Oura. Open Wearables handles the connection flow, the scopes and the token lifecycle. ### Which scopes does this need? personal, daily, heartrate, workout, session, spo2, ring_configuration and heart_health by default. That covers the daily scores, continuous heart rate, blood oxygen, VO2 max and cardiovascular age. The [setup guide in the docs](https://openwearables.io/docs/providers/oura-api-integration) has the exact string. ### Does it support webhooks or only polling? Both, and the webhooks register themselves. Switch live sync to webhook mode and Open Wearables creates the subscriptions for sleep, readiness, activity, SpO2, heart health and workouts. Hourly polling runs underneath as a safety net. ### Oura subscriptions expire. Is that handled? Yes. Oura webhook subscriptions lapse after ninety days, which is unusual among the sources we connect. A scheduled job renews every active subscription monthly, well ahead of the deadline, and retries if a renewal fails. This is the kind of thing that breaks quietly in a build-it-yourself integration, months after whoever wrote it moved on. ### Do we get continuous heart rate from Oura? Yes. Heart rate arrives as samples across the day and night, not only during exercise, and HRV at five-minute intervals through sleep. That is one of the main reasons teams pick the ring. ### How detailed is the sleep data? A stage-by-stage timeline rather than nightly totals. Oura returns the hypnogram in thirty-second epochs, with a five-minute version as the fallback, so you can chart the night rather than read one number for it. Efficiency, time in bed and nap detection come with it. ### Can we get heart rate during a workout? Not on the workout record. Oura's workouts carry type, intensity, calories, distance and duration, and heart rate is not among them. The continuous stream still covers that period, so the data exists, just not attached to the workout. ### What does the temperature reading mean? It is a deviation from that user's own baseline rather than an absolute body temperature. Useful for spotting a change, not for reporting a number in degrees. ### How far back does the first sync go? Ninety days by default when a user connects. You can switch that off and request a specific range yourself, up to a year back. --- Source: https://openwearables.io/integrations/polar # Polar training data, running in your own cloud Polar integration One API for Polar and for the rest of the wearables your users own, connected through the official AccessLink API and returned in a single schema. Self-hosted in a cloud account you control, under an MIT licence. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo Data coverage ## Polar data we support Everything below arrives in one schema, including Polar's own sleep score, Nightly Recharge and Cardio Load. ### Training sessions Sport, distance, calories, average and maximum heart rate. ### Sleep Stage timeline, duration, time in bed and sleep score. ### Nightly Recharge Recovery status with overnight HRV and breathing rate. ### Cardio Load Daily training strain, as Polar calculates it. ### SleepWise Daytime alertness and circadian bedtime. ### Heart rate Continuous samples across the day and night. ### Daily activity Steps, active time, active calories and distance. ### Temperature Body and skin temperature, with baseline deviation. Elixir devices. ### Spot measurements SpO2 and wrist ECG with HRV. Elixir devices. ## What working with Open Wearables gives you Two views of the same deployment. One for the people wiring it in, one for the people signing it off. ### One schema, not one per provider Polar arrives in the same shape as every other source, so your code carries no Polar-specific branches and adding a source later does not change the call. - Training - Sleep - Recovery - Heart rate ### The two-step connection handled Polar needs each user registered against your application after they authorise, which is a step people miss and then debug. Open Wearables does it as part of the connection flow. - OAuth 2.0 - User registration ### Signed webhooks, verified for you Polar issues a signing secret once, at subscription time, and never shows it again. Open Wearables stores it and checks every incoming event against it, with hourly polling underneath as the safety net. - Webhooks - Signed events - Hourly polling ### Health scores computed in your deployment Polar's own sleep score, Nightly Recharge and Cardio Load arrive as data, as Polar calculates them. Health scores from our science team run alongside them inside your deployment, validated before release, and are part of Pro. - Polar scores - Health scores ### Access you control It runs in your cloud account, under your credentials. When we work on your system, we do it under a DPA you sign. - Your credentials - Your region ### The Polar relationship stays yours Credentials issued in your name, data going straight from Polar into your account. - Your Polar client - Self-serve ### Costs you can see Running it costs your own cloud bill, paid to your provider. Deployment and Integration are one-off services, and health scores and the other licensed modules come with Pro. - Your cloud bill - One-off services ### No dependency on us MIT licence, full source, public roadmap and public issues, plus community support on Discord. - MIT license - Full source - Discord How it works ## From nothing to your first Polar query [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) 01 ### Bring it up Clone the repository and run it with Docker Compose. First API call in five minutes, before any provider is connected. Terminal ``` $ git clone https://github.com/the-momentum/open-wearables.git $ cd open-wearables && docker compose up -d ``` 02 ### Register your Polar app Sign in to AccessLink admin with your Polar Flow account, create a client and bring the client ID and secret. The credentials stay in your name, so the data relationship is between you and Polar. [Polar AccessLink admin](https://admin.polaraccesslink.com/) 03 ### Connect a user Your user authorises through Polar's own consent screen, and Open Wearables registers them against your application in the same flow. That second step is specific to Polar and easy to miss when you build this yourself. 04 ### Query the user, not the provider Polar data arrives in the same schema as every other source, in your own database, so your application code carries no Polar-specific branches. [Polar API setup guide](https://openwearables.io/docs/providers/polar-api-integration) The honest comparison ## Hosted SaaS API, in-house build, or self-hosted Where each one actually wins. If a hosted API fits your situation, use one. | | Hosted SaaS API | Build in-house | Open Wearables, self-hosted | | --- | --- | --- | --- | | [01] Polar credentials | Theirs, already approved | Yours to obtain | Yours, in your own name | | [02] User registration step | They handle it | Yours to discover and build | Handled in the connection flow | | [03] Webhook secret | Theirs to keep | Shown once, lose it and you rebuild | Stored and verified for you | | [04] Where Polar data sits | Their cloud, their regions | Yours | Your cloud account, your region | | [05] The data model | Theirs, you build against their schema | Yours | Yours, in your database | | [06] Polar API changes | They absorb them | Your team tracks and adapts | Fixed in a release you pull | | [07] Cost shape | Scales with monthly active users | Salaries and infrastructure | Fixed, flattens as you grow | What stays yours ## The deployment, the data and what you build on it stay in your account, whoever runs it ### Sovereignty Polar data goes straight to your cloud, with no aggregator in between. ### Residency It stays in the region you chose, provable by pointing at an account. ### Control What you build on top of Open Wearables is yours, and the schema and the data are in your account. ### Your own reasons No regulator forcing it. You want the data in your own account anyway. ## Polar is one integration in the same API You query a user rather than a provider, so somebody with a Polar watch and a ring comes back in one shape. Adding the ring later does not change your code. [Browse all integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## Deploy Open Wearables in your own cloud The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account with Polar connected and validated on real accounts. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) FAQ ## Do you have more questions? ### Does Polar have an API? Yes. It is called AccessLink, it uses OAuth, and you register a client to get an ID and secret. The credentials are issued in your name, so the data relationship is between you and Polar. ### What is the difference between Polar Flow and AccessLink? Polar Flow is the app your users already use. AccessLink is the developer API that reads what Flow holds. Connecting through AccessLink means your users keep using Flow exactly as before. ### Do we need to do anything after a user authorises? Polar needs each user registered against your application, which is a separate call after the OAuth handshake. Open Wearables does it inside the connection flow, so it is not something you find out about from a support thread. ### Does it support webhooks or only polling? Both. Polar pushes events for training sessions, sleep, daily activity, continuous heart rate and SleepWise, and hourly polling runs underneath as a safety net. Polar sends a lightweight notification rather than the data itself, so the event is acknowledged immediately and the matching records are fetched right after. ### How does webhook verification work? Polar sends a PING to your endpoint when the subscription is created and expects a clean response before it starts delivering. It then issues a signing secret, once, which is used to verify every event that follows. Open Wearables stores that secret and does the verification. ### What happens if we lose the webhook secret? Polar shows it only at creation, so there is no way to read it back. The fix is to delete the subscription and create a new one. Open Wearables saves it at creation, which is why this rarely comes up. ### Do we get continuous heart rate from Polar? Yes, sampled across the day and night rather than only during training, on the devices that record it. Open Wearables reads it in blocks and stitches them together, so a long backfill arrives as one continuous series. ### How detailed is the sleep data? Stage timestamps from the hypnogram, so deep, light, REM and awake as a timeline rather than nightly totals, plus duration, time in bed and the night's heart rate samples. Sleep efficiency is not something the Polar API returns, and nap detection is not available for Polar. ### Which Polar scores do we get? The sleep score, Nightly Recharge as the recovery read and Cardio Load as training strain. Where the user has SleepWise, its daytime alertness and circadian bedtime come too. You can also add our health scores, part of Pro and designed and validated by our science team, inside your own deployment. ### Is heart rate variability available? Yes, in two forms. Nightly Recharge carries an overnight HRV average, alongside breathing rate, from any device that runs it. Spot readings come from SpO2 tests and wrist ECG on a Polar Elixir device, which is also what body temperature, skin temperature and SpO2 need. If those are central to your product, check them against the devices your users actually own. ### How far back does a first sync go? Training sessions come from Polar Flow for the connected user without a date filter, so the first sync pulls what is there. Daily data goes back ninety days, fetched in four-week blocks, so a longer history arrives as a sequence of requests rather than one large one. --- Source: https://openwearables.io/integrations/samsung-health # Samsung Health data, in your own cloud Samsung Health integration Samsung Health is where a Galaxy watch, a Samsung scale and the apps around them keep their data. Open Wearables reads it through the same Android SDK that handles Health Connect and lands it in the same schema as the rest of your sources, self-hosted under an MIT licence. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo Data coverage ## Samsung Health data we support One permission grant reads what the user's Galaxy devices and Samsung Health have recorded, in the same schema as the rest of your sources. ### Sleep Stages, efficiency, time in bed, naps and Samsung's sleep score. ### Heart Heart rate and blood pressure. ### Body Weight, height, BMI, fat, lean and skeletal muscle mass. ### Vitals SpO2, body temperature and blood glucose. ### Activity Steps, active and basal energy, floors climbed and hydration. ### Workouts Heart rate range, energy, distance, speed and elevation. ### Performance VO2 max and cadence from workouts. ## What working with Open Wearables gives you Two views of the same deployment. One for the people wiring it in, one for the people signing it off. ### One schema, not one per provider Samsung Health arrives in the same shape as every cloud source, so your code carries no Samsung-specific branches and adding a watch integration later does not change the call. - Sleep - Body - Vitals - Workouts ### One SDK for both Android health stores The same Android SDK reads Samsung Health and Health Connect, and reports which of them a device actually has, so your app picks the right one at runtime rather than guessing from the model name. - Samsung Health - Health Connect ### Background sync that survives the OS WorkManager schedules it and a foreground service carries it while it runs. Each sync moves only what is new, from a first-sync depth you choose, and your backend mints the short-lived token the app uses. - WorkManager - Incremental ### No health permissions to declare Samsung Health grants access through its own dialog rather than the Android health permissions Health Connect relies on, so choosing Samsung adds no health declarations to your manifest. - Samsung's own dialog ### Access you control It runs in your cloud account, under your credentials. When we work on your system, we do it under a DPA you sign. - Your credentials - Your region ### Ship Android first, add Samsung when it clears Samsung reviews production access separately, and Health Connect does not. The same integration covers both, so you can launch on Health Connect and switch Samsung on once your approval lands, without a second build. - Health Connect first - Same build ### Costs you can see Running it costs your own cloud bill, paid to your provider. Deployment and Integration are one-off services, and health scores and the other licensed modules come with Pro. - Your cloud bill - One-off services ### No dependency on us MIT licence, full source, public roadmap and public issues, plus community support on Discord. - MIT license - Full source - Discord How it works ## From nothing to your first Samsung Health query [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) 01 ### Bring it up Clone the repository and run it with Docker Compose. First API call in five minutes, before any provider is connected. Terminal ``` $ git clone https://github.com/the-momentum/open-wearables.git $ cd open-wearables && docker compose up -d ``` 02 ### Add the SDK to your Android app Samsung Health data lives on the device, so this is where the integration happens. Add our SDK along with Samsung's own [Health Data SDK](https://developer.samsung.com/health/data), and select Samsung as the provider. [Android SDK integration guide](https://openwearables.io/docs/sdk/android/integration) 03 ### Ask the user for permission Samsung Health shows its own permission dialog and the user decides what to share. Your app keeps its existing login, so there is no second account to manage. 04 ### Clear production access with Samsung Reading data on a development build needs only a Samsung account. Shipping to production also needs Samsung to approve your app and register its release signing key, so start that early and run the rest in parallel. [Samsung app registration](https://developer.samsung.com/health/data/process.html) 05 ### Query the user, not the provider Samsung Health data arrives in the same schema as every other source, in your own database, so your application code carries no Samsung-specific branches. [Mobile SDKs](https://openwearables.io/platform/mobile-sdks) The honest comparison ## Hosted SaaS API, in-house build, or self-hosted Where each one actually wins. If a hosted API fits your situation, use one. | | Hosted SaaS API | Build in-house | Open Wearables, self-hosted | | --- | --- | --- | --- | | [01] The mobile SDK | Theirs, in your app | Yours to write and maintain | Open source, in your app, forkable | | [02] Samsung production approval | Theirs, already cleared | Yours to obtain | Yours, and the same build ships without it | | [03] Where Samsung data goes first | Their cloud | Yours | Your cloud account, your region | | [04] Permission dialog | Theirs or yours, depending | Yours | Samsung's own, inside your app | | [05] The data model | Theirs, you build against their schema | Yours | Yours, in your database | | [06] Samsung SDK changes | They absorb them | Your team tracks and adapts | Fixed in a release you pull | | [07] Cost shape | Scales with monthly active users | Salaries and infrastructure | Fixed, flattens as you grow | What stays yours ## The deployment, the data and what you build on it stay in your account, whoever runs it ### Sovereignty Samsung Health data goes from the device to your cloud, with no aggregator in between. ### Residency It stays in the region you chose, provable by pointing at an account. ### Control What you build on top of Open Wearables is yours, and the schema and the data are in your account. ### Your own reasons No regulator forcing it. You want the data in your own account anyway. ## Samsung Health is one integration in the same API You query a user rather than a provider, so somebody on a Galaxy watch and somebody wearing a ring you connect through the cloud both come back in one shape. Adding either later does not change your code. [Browse all integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) ## Deploy Open Wearables in your own cloud The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account with the SDK live in your app and validated on real devices. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) FAQ ## Do you have more questions? ### What is Samsung Health? Samsung's health app and data store on Galaxy phones and watches. It holds what Samsung devices measured, and apps read it with the user's permission. Unlike Health Connect, it is specific to Samsung hardware rather than available across Android. ### Do we need approval from Samsung? For development, no: read access needs only a Samsung account. For a production release, yes. Samsung approves your app and registers its release signing key, and the permission flow stops working on release builds until both are done. It is worth starting on day one, because the rest of the integration does not wait for it. ### Can we launch before that approval lands? Yes, and it is the usual route. The same integration also reads Health Connect, which has no approval requirement and covers Android devices broadly. Teams typically ship on Health Connect and switch Samsung on afterwards, without a second build. See the [Health Connect integration](https://openwearables.io/integrations/google-health-connect). ### Should we use Samsung Health or Health Connect on a Galaxy device? Health Connect covers more data types and works across Android, so it is the better default. Samsung Health is the right choice when you specifically want what Samsung's own app holds, such as its sleep score, or when a user keeps their data there rather than sharing it with Health Connect. ### Is the data the same as through Health Connect? Narrower. Samsung's SDK exposes fewer types: heart rate variability, resting heart rate and respiratory rate come through Health Connect but not here. What Samsung Health adds is its own sleep score alongside the sleep record. ### Do we have to build a mobile app for this? Yes. Samsung Health has no cloud API, so the data never leaves the device on its own and the SDK has to live in an Android app. ### Which SDKs are available? Our native Android SDK in Kotlin, plus Flutter and React Native wrappers over the same core. Samsung's own Health Data SDK also has to be added to your app, and Samsung distributes it directly rather than through a package repository. ### How does the data actually get to us? The SDK reads Samsung Health and pushes to your deployment. Background sync is scheduled through WorkManager, with a foreground service carrying an active sync, and each run moves only what is new. ### Can we test this without a Galaxy device? Not in an emulator. Samsung Health needs a physical Samsung device with the app installed, and Developer Mode enabled in it while you are still on a development build. ### Can we combine Samsung Health with other sources? Yes, and that is the normal case. You query a user rather than a provider, so somebody with a Galaxy watch and a connected ring returns in one shape. --- Source: https://openwearables.io/integrations/sensorbio # SensorBio data, in your own cloud SensorBio integration One API for SensorBio and for the rest of the wearables your users own, connected through SensorBio's own API and returned in a single schema. Self-hosted in a cloud account you control, under an MIT licence. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo Data coverage ## SensorBio data we support Readings arrive as a continuous stream of timestamped samples, and everything below lands in the same schema as every other source. ### Sleep Deep, light, REM and awake time, with a stage timeline per session. ### Heart rate Continuous samples, plus resting heart rate. ### Heart rate variability RMSSD, sampled continuously and as a resting value. ### Blood oxygen SpO2 samples through the day and night. ### Respiratory rate Breaths per minute, sampled continuously. ### Workouts Type, duration, heart rate, energy and distance. ### Steps and distance Daily totals for every day synced. ### Calories Active and resting energy, split out per day. ### SensorBio scores SensorBio's own daily sleep, recovery and activity scores. ## What working with Open Wearables gives you Two views of the same deployment. One for the people wiring it in, one for the people signing it off. ### One schema, not one per provider SensorBio arrives in the same shape as every other source, so your code carries no SensorBio-specific branches and adding a source later does not change the call. - Sleep - Heart rate - HRV - SpO2 ### A continuous stream, paged for you SensorBio returns heart rate, HRV, blood oxygen and respiratory rate as a stream of timestamped samples. Open Wearables pages through it with a cursor and writes each sample to the same series your other sources fill. - Cursor paging - Timestamped samples ### Polling, already scheduled The SensorBio API is read over REST with no webhooks, so Open Wearables polls it hourly by default and refreshes tokens along the way. Requests go over HTTP/2, which the API requires, so there is nothing for you to schedule or configure. - Hourly polling - OAuth 2.0 ### Health scores computed in your deployment SensorBio's own sleep, recovery and activity scores arrive as data, as SensorBio calculates them. Health scores from our science team run alongside them inside your deployment, validated before release, and are part of Pro. - SensorBio scores - Health scores ### Access you control It runs in your cloud account, under your credentials. When we work on your system, we do it under a DPA you sign. - Your credentials - Your region ### The SensorBio relationship stays yours Credentials issued in your name, data going straight from SensorBio into your account. - Your developer account - Your credentials ### Costs you can see Running it costs your own cloud bill, paid to your provider. Deployment and Integration are one-off services, and health scores and the other licensed modules come with Pro. - Your cloud bill - One-off services ### No dependency on us MIT licence, full source, public roadmap and public issues, plus community support on Discord. - MIT license - Full source - Discord How it works ## From nothing to your first SensorBio query [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) 01 ### Bring it up Clone the repository and run it with Docker Compose. First API call in five minutes, before any provider is connected. Terminal ``` $ git clone https://github.com/the-momentum/open-wearables.git $ cd open-wearables && docker compose up -d ``` 02 ### Get SensorBio API access Ask SensorBio for a developer account with API access, then register your redirect URI in their developer portal. The client ID and secret are issued in your name, so the data relationship is between you and SensorBio. [SensorBio API setup guide](https://openwearables.io/docs/providers/sensorbio-api-integration) 03 ### Connect a user Your user authorises through SensorBio's own consent screen. Open Wearables handles the token lifecycle from there, including the refresh that keeps the connection alive months later. 04 ### Query the user, not the provider SensorBio data arrives in the same schema as every other source, in your own database, so your application code carries no SensorBio-specific branches. The honest comparison ## Hosted SaaS API, in-house build, or self-hosted Where each one actually wins. If a hosted API fits your situation, use one. | | Hosted SaaS API | Build in-house | Open Wearables, self-hosted | | --- | --- | --- | --- | | [01] SensorBio credentials | Theirs, if they support it | Yours to obtain | Yours, in your own name | | [02] Sync model | Handled for you | Polling you build and schedule | Hourly polling, already scheduled | | [03] The continuous stream | Mapped to their schema | Cursor paging you write and maintain | Paged and split into the series every source fills | | [04] Where SensorBio data sits | Their cloud, their regions | Yours | Your cloud account, your region | | [05] The data model | Theirs, you build against their schema | Yours | Yours, in your database | | [06] SensorBio API changes | They absorb them | Your team tracks and adapts | Fixed in a release you pull | | [07] Cost shape | Scales with monthly active users | Salaries and infrastructure | Fixed, flattens as you grow | What stays yours ## The deployment, the data and what you build on it stay in your account, whoever runs it ### Sovereignty SensorBio data goes straight to your cloud, with no aggregator in between. ### Residency It stays in the region you chose, provable by pointing at an account. ### Control What you build on top of Open Wearables is yours, and the schema and the data are in your account. ### Your own reasons No regulator forcing it. You want the data in your own account anyway. ## SensorBio is one integration in the same API You query a user rather than a provider, so somebody who wears SensorBio and also trains with a watch or logs runs on Strava comes back in one shape, under one user. [Browse all integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## Deploy Open Wearables in your own cloud The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account with SensorBio connected and validated on real accounts. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) FAQ ## Do you have more questions? ### Does SensorBio have an API? Yes. It uses OAuth 2.0, and you need a SensorBio developer account with API access to get a client ID and secret. The credentials are issued in your name, so the data relationship is between you and SensorBio. ### What does SensorBio actually give us? Sleep with a stage timeline, workouts, and a continuous stream of heart rate, HRV, blood oxygen and respiratory rate, plus resting heart rate, daily steps, distance and calories, and SensorBio's own daily scores. Everything arrives in the same schema as your other sources. ### Do we get SensorBio's own scores? Yes. Its daily sleep, recovery and activity scores arrive as SensorBio calculates them, alongside the data underneath. ### Is the HRV comparable with our other sources? Yes. SensorBio's HRV arrives as RMSSD, the same measure Oura, Polar, Ultrahuman and Whoop report, so it lands in the same series and can be read side by side. ### Does it support webhooks? No. The SensorBio API is read over REST, so Open Wearables polls it hourly by default. New data lands within the hour rather than the second, which is the trade-off the API imposes. ### Does SensorBio tell naps apart from night sleep? Not through the API. A day can return more than one sleep session, and each arrives as its own record, so Open Wearables stores every session as sleep rather than guessing a nap from its length. ### How far back does a first sync go? Ninety days by default when a user connects. You can switch that off and request a specific range yourself, up to a year back. ### What do we need to configure? Your client credentials from SensorBio and a redirect URI registered in their developer portal. The [setup guide in the docs](https://openwearables.io/docs/providers/sensorbio-api-integration) has the exact variables. ### Can we combine SensorBio with other sources? Yes. SensorBio sits alongside whatever else a user connects, and you query the user rather than each provider, so a second source never means a second code path. --- Source: https://openwearables.io/integrations/strava # Strava activity data, in your own cloud Strava integration One API for Strava and for the rest of the wearables your users own, connected through the official Strava developer API and returned in a single schema. Self-hosted in a cloud account you control, under an MIT licence. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo Data coverage ## Strava data we support Strava goes deep on what happened during a session, and everything below arrives in the same schema as every other source. ### Activities Distance, moving time, calories and heart rate. ### Speed and power Average and maximum for both, per session. ### Elevation Total climbing, plus the highest and lowest points. ### Per-sample streams Heart rate, speed, cadence and power, when enabled. ### Sport and source Sport type, the recording device and manual entries. ## What working with Open Wearables gives you Two views of the same deployment. One for the people wiring it in, one for the people signing it off. ### One schema, not one per provider A Strava ride and a Garmin ride arrive in the same fields, so your code compares them without a translation layer and adding a source later does not change the call. - Activities - Streams - Sport types ### Webhooks that answer in time Strava sends only an activity id and expects a response within two seconds. Open Wearables checks the signature, acknowledges at once and queues the fetch, so the call that pulls the full activity happens after the window rather than inside it. - Webhooks - Signed events - Two-second window ### Streams when you want them Per-sample heart rate, speed, cadence and power are ingested only if you enable them, so a large backfill does not fill your database with data you are not using. - Optional - Off by default ### Energy that is never empty Strava's activity list often returns no calorie value. Open Wearables falls back to the kilojoules from the power data rather than leaving the field empty. - Calories - Kilojoule fallback ### Access you control It runs in your cloud account, under your credentials. When we work on your system, we do it under a DPA you sign. - Your credentials - Your region ### The Strava relationship stays yours Credentials issued in your name, data going straight from Strava into your account. - Your Strava app - Your credentials ### Costs you can see Running it costs your own cloud bill, paid to your provider. Deployment and Integration are one-off services, and health scores and the other licensed modules come with Pro. - Your cloud bill - One-off services ### No dependency on us MIT licence, full source, public roadmap and public issues, plus community support on Discord. - MIT license - Full source - Discord How it works ## From nothing to your first Strava query [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) 01 ### Bring it up Clone the repository and run it with Docker Compose. First API call in five minutes, before any provider is connected. Terminal ``` $ git clone https://github.com/the-momentum/open-wearables.git $ cd open-wearables && docker compose up -d ``` 02 ### Register your Strava app Create an application in Strava's API settings and bring the client ID and secret. That takes minutes and covers up to ten connected athletes. For more, you submit the app for Extended Access through the same dashboard and Strava reviews it. [Strava API settings](https://www.strava.com/settings/api) 03 ### Connect a user Your user authorises through Strava's own consent screen. Open Wearables requests the scopes it needs and handles the token lifecycle from there, including the refresh that keeps the connection alive months later. 04 ### Query the user, not the provider Strava data arrives in the same schema as every other source, in your own database, so your application code carries no Strava-specific branches. [Strava API setup guide](https://openwearables.io/docs/providers/strava-api-integration) The honest comparison ## Hosted SaaS API, in-house build, or self-hosted Where each one actually wins. If a hosted API fits your situation, use one. | | Hosted SaaS API | Build in-house | Open Wearables, self-hosted | | --- | --- | --- | --- | | [01] Strava credentials | Theirs, already approved | Yours to obtain | Yours, in your own name | | [02] The two-second webhook window | They absorb it | Yours to hit, every time | Acknowledged first, fetched after | | [03] Per-sample streams | Rarely exposed | Yours to fetch and store | Optional, off by default | | [04] Where Strava data sits | Their cloud, their regions | Yours | Your cloud account, your region | | [05] The data model | Theirs, you build against their schema | Yours | Yours, in your database | | [06] Strava API changes | They absorb them | Your team tracks and adapts | Fixed in a release you pull | | [07] Cost shape | Scales with monthly active users | Salaries and infrastructure | Fixed, flattens as you grow | What stays yours ## The deployment, the data and what you build on it stay in your account, whoever runs it ### Sovereignty Strava data goes straight to your cloud, with no aggregator in between. ### Residency It stays in the region you chose, provable by pointing at an account. ### Control What you build on top of Open Wearables is yours, and the schema and the data are in your account. ### Your own reasons No regulator forcing it. You want the data in your own account anyway. ## Strava is one integration in the same API You query a user rather than a provider, so somebody who rides with a Strava account and sleeps with a ring comes back in one shape. That pairing is the normal case here, because Strava covers the session and something else covers the night. [Browse all integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## Deploy Open Wearables in your own cloud The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account with Strava connected and validated on real accounts. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) FAQ ## Do you have more questions? ### Does Strava have an API? Yes. You register an application in Strava's API settings to get a client ID and secret, and users connect through OAuth. Getting started is self-serve, with no approval queue. ### How many users can we connect? Up to ten athletes on the Standard tier, which you enable yourself, at 200 requests per 15 minutes and 2,000 a day. Beyond that you submit the app for Extended Access through the same dashboard, Strava reviews it, and the limits rise to 400 and 4,000. The [setup guide in the docs](https://openwearables.io/docs/providers/strava-api-integration) covers both. ### What does Strava actually give us? Activities, in depth. Distance, moving time, calories, heart rate average and maximum, speed average and maximum, power average and maximum, elevation gain and the high and low points. Optionally, per-sample streams for heart rate, speed, cadence and power through the session. ### Does Strava give us sleep or recovery data? Strava covers sessions rather than the day around them, so that side comes from a wearable. Teams usually connect one alongside it, and both land in the same schema under the same user, which is how a ride and the night that followed end up in one query. ### What are per-sample streams and should we use them? They are the second-by-second readings inside a workout: heart rate, speed, cadence and power. They are useful if you are drawing graphs of a session or analysing intervals, and expensive if you are not, because one long ride produces thousands of rows. Ingestion is off by default and you turn it on when you need it. ### Does it support webhooks? Yes, for activities created, updated and deleted, plus a notice when someone disconnects your app. The event carries only the activity id and what changed, and Strava expects a response within two seconds. Open Wearables answers straight away and queues the fetch, so the two-second limit is never the thing that breaks delivery. ### How are webhook events verified? Every event carries a signature built from your client secret, and Open Wearables checks it before doing anything with the payload. Subscription setup uses a challenge that Strava sends to your callback and expects echoed back, which is handled for you. ### How many webhook subscriptions can we have? One per application, which is Strava's limit rather than ours. It covers every user who has authorised your app. ### Whose terms apply to the data? Strava's. Your application is registered with Strava in your name, so its [API Agreement](https://www.strava.com/legal/api) governs how you use the data, whoever runs the integration. It is worth reading before you design a feature on top of it. ### Which scopes does this need? activity:read_all and profile:read_all. The first covers activities including private ones, the second the athlete profile. ### Why do some activities have no calories? Strava's activity list often returns no calorie value, and it is only present on the detailed record. Open Wearables falls back to kilojoules from the power data so the energy field is populated either way. ### Can we tell which device recorded an activity? Yes. The device name comes through on the activity, and a manual entry is flagged as such. That matters when the same user syncs a watch through Strava and through its own integration, because you can see which record came from where. ### Which sports does it recognise? Strava's activity types are mapped to the same taxonomy every other source uses, so a Strava ride and a Garmin ride group together. Legacy activity types are still read, so older sessions do not fall through. --- Source: https://openwearables.io/integrations/suunto # Suunto training data, running in your own cloud Suunto integration One API for Suunto and for the rest of the wearables your users own, connected through the official Suunto Cloud API and returned in a single schema. Self-hosted in a cloud account you control, under an MIT licence. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo Data coverage ## Suunto data we support Everything below arrives in one schema, including Suunto's own Balance as a recovery score. ### Training sessions Heart rate range, speed, power, distance, calories and elevation. ### Sleep Stages, efficiency, time in bed and naps. ### Sleep biometrics Lowest heart rate, average HRV and peak SpO2 per night. ### Recovery Suunto's Balance, scaled to a 0 to 100 score. ### Heart rate Continuous samples across the day and night. ### Heart rate variability RMSSD from daytime samples and from sleep. ### Blood oxygen SpO2 from daytime samples and the nightly peak. ### Daily activity Steps and energy, as samples and daily totals. ### Sport types Suunto activities mapped to one sport taxonomy. ## What working with Open Wearables gives you Two views of the same deployment. One for the people wiring it in, one for the people signing it off. ### One schema, not one per provider Suunto arrives in the same shape as every other source, so your code carries no Suunto-specific branches and adding a source later does not change the call. - Workouts - Sleep - Recovery - Heart rate ### Two credentials, one flow Suunto needs an OAuth client and a separate subscription key for its API gateway. Both are configured once, every request carries them, and token refresh keeps a connection alive months later. - OAuth 2.0 - Subscription key ### Signed webhooks, history over REST Suunto pushes new data inline over signed webhooks, acknowledged inside its two-second timeout. Historical sync runs over the REST API, so a first connection backfills while live data keeps flowing. - Webhooks - Signed events - REST backfill ### The full workout record, normalised Power, speed, elevation range and minimum, average and maximum heart rate land in the same fields your other sources fill, so a Suunto session and a Garmin session compare without a translation layer. - Power - Speed - Elevation ### Access you control It runs in your cloud account, under your credentials. When we work on your system, we do it under a DPA you sign. - Your credentials - Your region ### The Suunto relationship stays yours Credentials issued in your name, data going straight from Suunto into your account. - Your Suunto partnership - Your keys ### Costs you can see Running it costs your own cloud bill, paid to your provider. Deployment and Integration are one-off services, and health scores and the other licensed modules come with Pro. - Your cloud bill - One-off services ### No dependency on us MIT licence, full source, public roadmap and public issues, plus community support on Discord. - MIT license - Full source - Discord How it works ## From nothing to your first Suunto query [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) 01 ### Bring it up Clone the repository and run it with Docker Compose. First API call in five minutes, before any provider is connected. Terminal ``` $ git clone https://github.com/the-momentum/open-wearables.git $ cd open-wearables && docker compose up -d ``` 02 ### Apply for Suunto API access Suunto grants Cloud API access to companies through its partner programme rather than self-serve signup. Apply, sign the API agreement and expect an answer within about two weeks. Once approved you get an OAuth client and a subscription key, both in your name. [Suunto partner application](https://www.suunto.com/welcomepartners) 03 ### Connect a user Your user authorises through Suunto's own consent screen. Open Wearables handles the token lifecycle from there, including the refresh that keeps the connection alive months later. 04 ### Query the user, not the provider Suunto data arrives in the same schema as every other source, in your own database, so your application code carries no Suunto-specific branches. [Suunto API setup guide](https://openwearables.io/docs/providers/suunto-api-integration) The honest comparison ## Hosted SaaS API, in-house build, or self-hosted Where each one actually wins. If a hosted API fits your situation, use one. | | Hosted SaaS API | Build in-house | Open Wearables, self-hosted | | --- | --- | --- | --- | | [01] Suunto credentials | Theirs, already approved | Yours to apply for and wait on | Yours, with the application started on day one | | [02] The subscription key | Handled for you | A second credential to discover | Configured once, then invisible | | [03] Workout depth | Whatever their schema keeps | Yours to map, field by field | Fourteen fields, normalised to your model | | [04] Where Suunto data sits | Their cloud, their regions | Yours | Your cloud account, your region | | [05] The data model | Theirs, you build against their schema | Yours | Yours, in your database | | [06] Suunto API changes | They absorb them | Your team tracks and adapts | Fixed in a release you pull | | [07] Cost shape | Scales with monthly active users | Salaries and infrastructure | Fixed, flattens as you grow | What stays yours ## The deployment, the data and what you build on it stay in your account, whoever runs it ### Sovereignty Suunto data goes straight to your cloud, with no aggregator in between. ### Residency It stays in the region you chose, provable by pointing at an account. ### Control What you build on top of Open Wearables is yours, and the schema and the data are in your account. ### Your own reasons No regulator forcing it. You want the data in your own account anyway. ## Suunto is one integration in the same API You query a user rather than a provider, so somebody with a Suunto watch and a ring comes back in one shape. Adding the ring later does not change your code. [Browse all integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## Deploy Open Wearables in your own cloud The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account with Suunto connected and validated on real accounts. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) FAQ ## Do you have more questions? ### Does Suunto have an API? Yes, the Suunto Cloud API, through their partner programme. It is open to companies and organisations rather than personal use: you apply, sign the API agreement and, once approved, get an OAuth client and a subscription key, both in your name. ### How long does approval take? Expect an answer within about two weeks. It is the slowest step in the integration, which is why it is worth starting before anything else. A deployment starts it on day one and runs the rest in parallel. ### Why are there two credentials? The OAuth client authorises each user, and the subscription key authenticates your application against Suunto's API gateway. Every request carries both. It is configured once rather than per user. ### What are the rate limits? The Developer API tier allows 10 calls a minute, up to 200 a week, so plan sync volume against it: webhooks carry new data inline, while a large backfill spends calls quickly. Suunto can raise the tier if you need more, and the [setup guide in the docs](https://openwearables.io/docs/providers/suunto-api-integration) covers it. ### What comes back from a workout? Distance, calories, heart rate as minimum, average and maximum, steps, average and maximum speed, average and maximum power, moving time, elevation gain and the highest and lowest points. If your product compares training sessions across brands, it is among the richest inputs in the set. ### How detailed is the sleep data? Stages for deep, light, REM and awake, plus duration, time in bed, efficiency and whether it was a nap. Alongside that, the night's lowest heart rate, average HRV and highest blood oxygen are saved as their own readings. ### Do we get continuous heart rate from Suunto? Yes, across the day and night rather than only during training, together with HRV, blood oxygen, steps and energy from the same sample stream. ### Which recovery score does Suunto provide? Balance, which Suunto describes as a body energy level. It arrives on a 0 to 100 scale, so it sits in the same range as recovery scores from other sources and can be compared without rescaling. ### Does it support webhooks or only polling? Both. Suunto pushes workouts, sleep, recovery and daily activity as they arrive, with the data inline and signed, and historical sync runs over the REST API, so a first connection can backfill while live data keeps flowing. ### Can we combine Suunto with other sources? Yes, and that is the normal case. You query a user rather than a provider, so somebody with a Suunto watch and a second device returns in one shape. ### Which sports does it recognise? Suunto's activities are mapped to the same taxonomy every other source uses. A trail run recorded on a Suunto and one recorded on a Garmin arrive as the same type, which matters as soon as you group sessions across a mixed user base. --- Source: https://openwearables.io/integrations/ultrahuman # Ultrahuman Ring data, in your own cloud Ultrahuman integration One API for Ultrahuman and for the rest of the wearables your users own, connected through the official Partnership API and returned in a single schema. Self-hosted in a cloud account you control, under an MIT licence. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo Data coverage ## Ultrahuman data we support One endpoint returns a whole day at once, and everything below arrives in the same schema as every other source. ### Sleep Stages, efficiency, time in bed and naps. ### Heart rate Continuous samples, plus resting heart rate from sleep. ### Heart rate variability RMSSD, sampled across the day and night. ### Skin temperature Continuous readings through the day and night. ### Steps Continuous samples rather than one daily figure. ### VO2 max A daily estimate of aerobic capacity. ### Active time Minutes spent moving, as a daily value. ## What working with Open Wearables gives you Two views of the same deployment. One for the people wiring it in, one for the people signing it off. ### One schema, not one per provider Ultrahuman arrives in the same shape as every other source, so your code carries no Ultrahuman-specific branches and adding a source later does not change the call. - Sleep - Heart rate - HRV - Temperature ### A whole day in one call Ultrahuman returns every metric for a date from a single endpoint, so a backfill is one request per day rather than one per data type. Open Wearables splits the response into the same series your other sources fill. - One endpoint - Per-day backfill ### Polling, already scheduled The Partnership API is read-only over REST with no webhooks, so Open Wearables polls it hourly by default and refreshes tokens along the way. Nothing for you to schedule or babysit. - Hourly polling - OAuth 2.0 ### Health scores computed in your deployment Health scores from our science team run inside your deployment on the data the ring provides, validated before release. They are part of Pro, on top of the free core. - Health scores - Science team ### Access you control It runs in your cloud account, under your credentials. When we work on your system, we do it under a DPA you sign. - Your credentials - Your region ### The Ultrahuman relationship stays yours Credentials issued in your name, data going straight from Ultrahuman into your account. - Your Ultrahuman app - Your credentials ### Costs you can see Running it costs your own cloud bill, paid to your provider. Deployment and Integration are one-off services, and health scores and the other licensed modules come with Pro. - Your cloud bill - One-off services ### No dependency on us MIT licence, full source, public roadmap and public issues, plus community support on Discord. - MIT license - Full source - Discord How it works ## From nothing to your first Ultrahuman query [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) 01 ### Bring it up Clone the repository and run it with Docker Compose. First API call in five minutes, before any provider is connected. Terminal ``` $ git clone https://github.com/the-momentum/open-wearables.git $ cd open-wearables && docker compose up -d ``` 02 ### Get Partnership API access Sign in to the Ultrahuman developer dashboard with your Ultrahuman account and create an OAuth application for the Partnership API. The client ID and secret are issued in your name, so the data relationship is between you and Ultrahuman. [Partnership API docs](https://vision.ultrahuman.com/developer-docs) 03 ### Connect a user Your user authorises through Ultrahuman's own consent screen. Open Wearables requests the scopes it needs and handles the token lifecycle from there, including the refresh that keeps the connection alive months later. 04 ### Query the user, not the provider Ultrahuman data arrives in the same schema as every other source, in your own database, so your application code carries no Ultrahuman-specific branches. [Ultrahuman API setup guide](https://openwearables.io/docs/providers/ultrahuman-api-integration) The honest comparison ## Hosted SaaS API, in-house build, or self-hosted Where each one actually wins. If a hosted API fits your situation, use one. | | Hosted SaaS API | Build in-house | Open Wearables, self-hosted | | --- | --- | --- | --- | | [01] Ultrahuman credentials | Theirs, already approved | Yours to obtain | Yours, in your own name | | [02] Sync model | Handled for you | Polling you build and schedule | Hourly polling, already scheduled | | [03] The whole-day response | Mapped to their schema | Yours to split, metric by metric | Split into the series every source fills | | [04] Where Ultrahuman data sits | Their cloud, their regions | Yours | Your cloud account, your region | | [05] The data model | Theirs, you build against their schema | Yours | Yours, in your database | | [06] Ultrahuman API changes | They absorb them | Your team tracks and adapts | Fixed in a release you pull | | [07] Cost shape | Scales with monthly active users | Salaries and infrastructure | Fixed, flattens as you grow | What stays yours ## The deployment, the data and what you build on it stay in your account, whoever runs it ### Sovereignty Ultrahuman data goes straight to your cloud, with no aggregator in between. ### Residency It stays in the region you chose, provable by pointing at an account. ### Control What you build on top of Open Wearables is yours, and the schema and the data are in your account. ### Your own reasons No regulator forcing it. You want the data in your own account anyway. ## Ultrahuman is one integration in the same API You query a user rather than a provider, so somebody who wears the ring at night and a watch for training comes back in one shape. That pairing is common here, because the ring covers recovery and something else covers the session. [Browse all integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## Deploy Open Wearables in your own cloud The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account with Ultrahuman connected and validated on real accounts. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) FAQ ## Do you have more questions? ### Does Ultrahuman have an API? Yes, the Partnership API. It uses OAuth, and you create an application in the Ultrahuman developer dashboard to get a client ID and secret. The credentials are issued in your name, so the data relationship is between you and Ultrahuman. ### What does the ring actually give us? Sleep with full stage timestamps, continuous heart rate, HRV, skin temperature and steps through the day, plus resting heart rate, VO2 max and active minutes as daily values. Everything the ring reports arrives in the same schema as your other sources. ### Does Ultrahuman give us workouts? Not through the Partnership API. The ring is built around recovery and continuous monitoring rather than session tracking, so training data comes from a watch or from Strava alongside it, and both land in the same schema under the same user. ### Is the HRV comparable with our other sources? Yes. Ultrahuman's HRV arrives as RMSSD, the same measure Oura, Polar, Suunto and Whoop report, so it lands in the same series and can be read side by side. ### Does it support webhooks? No. The Partnership API is read-only over REST, so Open Wearables polls it hourly by default. New data lands within the hour rather than the second, which is the trade-off the API imposes. ### Why is the skin temperature lower than I expect? It is skin temperature, not core body temperature, so readings typically sit in the high twenties to mid thirties in Celsius. That is normal for a ring, and it is the number to trend rather than to read as a fever check. ### How far back does a first sync go? Ninety days by default when a user connects. You can switch that off and request a specific range yourself, up to a year back. ### Which scopes does this need? Ring data and the basic profile are what this integration reads. The [setup guide in the docs](https://openwearables.io/docs/providers/ultrahuman-api-integration) has the exact string to configure. ### Can we combine Ultrahuman with other sources? Yes, and here it is usually the point. The ring covers the night and the day, a watch or Strava covers the training, and you query the user rather than each provider. --- Source: https://openwearables.io/integrations/whoop # Whoop API recovery and strain, in your own cloud Whoop integration One API for Whoop and for the rest of the wearables your users own, connected through the official Whoop developer API and returned in a single schema. Self-hosted in a cloud account you control, under an MIT licence. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo Data coverage ## Whoop data we support Everything below arrives in one schema, including Whoop's own recovery, strain and sleep performance scores. ### Recovery Score, resting heart rate, HRV, SpO2 and skin temperature. ### Strain Daily strain score with average and maximum heart rate. ### Sleep Stage durations, efficiency, naps and sleep performance. ### Workouts Sport, heart rate zones, calories and moving time. ### Daily totals Energy and steps per cycle, plus height and weight. ## What working with Open Wearables gives you Two views of the same deployment. One for the people wiring it in, one for the people signing it off. ### One schema, not one per provider Whoop arrives in the same shape as every other source, so your code carries no Whoop-specific branches and adding a source later does not change the call. - Recovery - Strain - Sleep - Workouts ### Webhooks and polling, both handled Recovery, sleep and workout events arrive as Whoop scores them, with hourly polling underneath as the safety net. Your deployment hosts the endpoint, and its code ships with the repository. - Webhooks - Hourly polling - 90-day backfill ### Tokens and limits on rails The offline scope and refresh tokens keep a connection alive for months, and sync is scheduled inside Whoop's 100 requests a minute and 10,000 a day. - OAuth 2.0 - Rate limits handled ### Health scores computed in your deployment Whoop's own recovery, strain and sleep performance arrive as data, as Whoop calculates them. Health scores from our science team run alongside them inside your deployment, validated before release, and are part of Pro. - Whoop scores - Health scores ### Access you control It runs in your cloud account, under your credentials. When we work on your system, we do it under a DPA you sign. - Your credentials - Your region ### The Whoop relationship stays yours Credentials issued in your name, data going straight from Whoop into your account. - Your Whoop app - Self-serve ### Costs you can see Running it costs your own cloud bill, paid to your provider. Deployment and Integration are one-off services, and health scores and the other licensed modules come with Pro. - Your cloud bill - One-off services ### No dependency on us MIT licence, full source, public roadmap and public issues, plus community support on Discord. - MIT license - Full source - Discord How it works ## From nothing to your first Whoop query [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) 01 ### Bring it up Clone the repository and run it with Docker Compose. First API call in five minutes, before any provider is connected. Terminal ``` $ git clone https://github.com/the-momentum/open-wearables.git $ cd open-wearables && docker compose up -d ``` 02 ### Register your Whoop app Create an application in the Whoop developer dashboard and bring the client ID and secret. Whoop is self-serve, so this is minutes rather than weeks, and the credentials stay in your name. [Whoop developer dashboard](https://developer-dashboard.whoop.com/) 03 ### Connect a user Your user authorises through Whoop's own consent screen. Open Wearables requests the scopes it needs and handles the token lifecycle from there, including the refresh that keeps the connection alive months later. 04 ### Query the user, not the provider Whoop data arrives in the same schema as every other source, in your own database, so your application code carries no Whoop-specific branches. [Whoop setup guide](https://openwearables.io/docs/providers/whoop-api-integration) The honest comparison ## Hosted SaaS API, in-house build, or self-hosted Where each one actually wins. If a hosted API fits your situation, use one. | | Hosted SaaS API | Build in-house | Open Wearables, self-hosted | | --- | --- | --- | --- | | [01] Whoop credentials | Theirs, already approved | Yours to obtain | Yours, in your own name | | [02] Time to credentials | None for you | Short, Whoop is self-serve | Short, and the setup guide is written | | [03] Webhook endpoint | They host it | You build and host it | Your deployment hosts it, code included | | [04] Where Whoop data sits | Their cloud, their regions | Yours | Your cloud account, your region | | [05] The data model | Theirs, you build against their schema | Yours | Yours, in your database | | [06] Whoop API changes | They absorb them | Your team tracks and adapts | Fixed in a release you pull | | [07] Cost shape | Scales with monthly active users | Salaries and infrastructure | Fixed, flattens as you grow | What stays yours ## The deployment, the data and what you build on it stay in your account, whoever runs it ### Sovereignty Whoop data goes straight to your cloud, with no aggregator in between. ### Residency It stays in the region you chose, provable by pointing at an account. ### Control What you build on top of Open Wearables is yours, and the schema and the data are in your account. ### Your own reasons No regulator forcing it. You want the data in your own account anyway. ## Whoop is one integration in the same API You query a user rather than a provider, so somebody with a Whoop band and a watch comes back in one shape. Adding the watch later does not change your code. [Browse all integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## Deploy Open Wearables in your own cloud The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account with Whoop connected and validated on real accounts. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) FAQ ## Do you have more questions? ### Does Whoop have an API? Yes. The Whoop API is an official developer API with OAuth, and you register an application in the Whoop developer dashboard to get a client ID and secret. It is self-serve, so you are not waiting on an approval queue. ### Do we need our own Whoop credentials? Yes, and that is the point. The application is registered in your name, so the data relationship is between you and Whoop. Open Wearables handles the connection flow, the scopes and the token lifecycle. ### Which scopes does this need? offline, read:cycles, read:sleep, read:recovery and read:workout out of the box. Add read:body_measurement and read:profile if you want height and weight. The offline scope is the one that matters most, because without it you get no refresh token and the connection dies a month later. ### Does it support webhooks or only polling? Both. Whoop pushes updated and deleted events for workouts, sleep and recovery to an endpoint your deployment hosts, and hourly polling runs underneath as a safety net. One thing to know: Whoop has no API for registering webhook subscriptions, so that step is done by hand once in their dashboard. ### What are the rate limits? Whoop allows 100 requests a minute and 10,000 a day. A sync cycle costs roughly four to seven requests per user, which is the number to size against. The [setup guide in the docs](https://openwearables.io/docs/providers/whoop-api-integration) does that arithmetic. ### Can we get continuous heart rate from Whoop? Not from the Whoop API. It returns heart rate during workouts rather than all-day samples. If your product needs continuous heart rate, it comes from a second source, which is one reason teams connect more than one. ### How detailed is the sleep data? Durations for light, deep, REM and awake, plus efficiency, time in bed and whether it was a nap, alongside Whoop's sleep performance score with its consistency and respiratory rate. Whoop returns stages as totals rather than per-stage timestamps, so there is no stage-by-stage timeline to chart. ### Do we get Whoop's own scores? Yes, all three. Recovery arrives as Whoop scored it, with resting heart rate, heart rate variability, oxygen saturation and skin temperature alongside it. Strain comes on scored cycles with its heart rate and energy, and sleep performance with consistency, efficiency and respiratory rate. You can also run our health scores, a separate licensed module designed and validated by our science team, inside your own deployment. ### Can we combine Whoop with other sources? Yes, and that is the normal case. You query a user rather than a provider, so somebody with a Whoop band and a watch returns in one shape, and the second source covers what Whoop does not send. ### How far back does the first sync go? Ninety days by default when a user connects. You can switch that off and request a specific range yourself, up to a year back. Workouts and the daily set can be pulled together or separately, so a first connection does not have to fetch everything at once. ### Is there a Whoop subscription requirement? Your users need an active Whoop membership for their device to produce data, which is true of any Whoop integration. On the developer side you register an app and use the API. Whoop sets those terms, so their developer documentation is the authority. --- Source: https://openwearables.io/integrations/withings # Withings API body composition and blood pressure, in your own cloud Withings integration Scales, blood pressure monitors and watches from Withings, connected through the official Public API and returned in the same schema as every other source. Self-hosted in your own cloud, under an MIT licence. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo Data coverage ## Withings data we support Withings covers the measurements a watch cannot take, and everything below arrives in the same schema as the rest of your sources. ### Body composition Weight, fat, lean and muscle mass, water and bone. ### Blood pressure Systolic and diastolic, with heart rate alongside. ### Vascular and metabolic Pulse wave velocity, cardiovascular and metabolic age, VO2 max. ### Vitals SpO2, body and skin temperature, blood glucose. ### Sleep Stage timeline, efficiency, time in bed and naps. ### Daily activity Steps, distance, active and basal energy. ### Workouts Duration, heart rate range, steps, energy and distance. ### Time series Timestamped samples in the user's own time zone. ### Measured, not imported Activity other apps pushed into Withings is left out. ## What working with Open Wearables gives you Two views of the same deployment. One for the people wiring it in, one for the people signing it off. ### One schema, including what a wrist cannot take Scale and blood pressure readings arrive in the same shape as every other source, joined to the same user as their watch data, so your code carries no Withings-specific branches. - Body composition - Blood pressure - One schema ### Webhooks per user, nothing to register up front Withings creates subscriptions with each user's own token rather than once for your application. Open Wearables subscribes every active connection, and every new one at connect time. - Webhooks - Per-user subscriptions ### Local days that are actually local Withings sends the user's time zone by name, not just an offset, so a daily total lands on the day they lived, daylight saving included, before the data reaches your schema. - IANA time zones - DST handled ### Pull or push, switched from the dashboard Polling works with nothing but OAuth, and tokens refresh before they expire. Webhooks are a setting rather than a rewrite, and switching back revokes the subscriptions cleanly. - Polling - Webhooks - OAuth 2.0 ### Access you control It runs in your cloud account, under your credentials. When we work on your system, we do it under a DPA you sign. - Your credentials - Your region ### The Withings relationship stays yours Credentials issued to your organisation, data going straight from Withings into your account. - Your Withings app - Your credentials ### Costs you can see Running it costs your own cloud bill, paid to your provider. Deployment and Integration are one-off services, and health scores and the other licensed modules come with Pro. - Your cloud bill - One-off services ### No dependency on us MIT licence, full source, public roadmap and public issues, plus community support on Discord. - MIT license - Full source - Discord How it works ## From nothing to your first Withings query [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) 01 ### Bring it up Clone the repository and run it with Docker Compose. First API call in five minutes, before any provider is connected. Terminal ``` $ git clone https://github.com/the-momentum/open-wearables.git $ cd open-wearables && docker compose up -d ``` 02 ### Create your Withings application Register a Public API integration in the Withings Partner Hub and bring the client ID and secret. A free Withings account is enough to start, and the credentials stay in your name. [Withings Partner Hub](https://developer.withings.com/) 03 ### Connect a user Your user authorises through Withings' own consent screen. Open Wearables handles the flow and the token lifecycle, and subscribes their connection for notifications when webhooks are on. 04 ### Query the user, not the provider Withings data arrives in the same schema as every other source, in your own database, so your application code carries no Withings-specific branches. [Withings API setup guide](https://openwearables.io/docs/providers/withings-api-integration) The honest comparison ## Hosted SaaS API, in-house build, or self-hosted Where each one actually wins. If a hosted API fits your situation, use one. | | Hosted SaaS API | Build in-house | Open Wearables, self-hosted | | --- | --- | --- | --- | | [01] Withings credentials | Theirs, already approved | Yours to obtain | Yours, in your own name | | [02] Webhook subscriptions | They host them | Per-user work you build | Subscribed per user, handled for you | | [03] Where Withings data sits | Their cloud, their regions | Yours | Your cloud account, your region | | [04] The data model | Theirs, you build against their schema | Yours | Yours, in your database | | [05] Time zone handling | Whatever they normalise to | Yours to get right | Local days resolved from the user's zone | | [06] Withings API changes | They absorb them | Your team tracks and adapts | Fixed in a release you pull | | [07] Cost shape | Scales with monthly active users | Salaries and infrastructure | Fixed, flattens as you grow | What stays yours ## The deployment, the data and what you build on it stay in your account, whoever runs it ### Sovereignty Withings data goes straight to your cloud, with no aggregator in between. ### Residency It stays in the region you chose, provable by pointing at an account. ### Control What you build on top of Open Wearables is yours, and the schema and the data are in your account. ### Your own reasons No regulator forcing it. You want the data in your own account anyway. ## Withings is one integration in the same API You query a user rather than a provider, so somebody who steps on a Withings scale in the morning and wears a different watch all day comes back in one shape. Adding either later does not change your code. [Browse all integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## Deploy Open Wearables in your own cloud The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account with Withings connected and validated on real accounts. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) FAQ ## Do you have more questions? ### Do we need our own Withings credentials? Yes. You register a Public API integration in the Withings Partner Hub and bring the client ID and secret. A free Withings account is enough to create one, and the data relationship stays between you and Withings. ### What does Withings give us that a watch does not? Body composition and blood pressure. A scale measures fat mass, lean mass, water and bone, and a blood pressure monitor measures what no wrist device reports. Joined to the same user record as their watch data, that is a fuller picture than either source alone. ### Does it support webhooks? Yes, and Withings does them differently from everyone else. Subscriptions are created per user with that user's own token rather than once for your whole application, so there is no registration step blocking your first connection. Open Wearables subscribes each active connection, and anyone who connects later is subscribed automatically. ### Can we start without webhooks? Yes, polling is the default and needs nothing beyond OAuth, so you can have data flowing before you have a public callback. Withings limits an application with no webhook callback to ten linked users, though, so production runs with webhooks on. They are a switch in the dashboard, and switching back revokes the subscriptions cleanly. ### What do we need before turning webhooks on? A publicly reachable HTTPS callback on the standard port. Withings checks the endpoint before it creates any subscription, so it has to be live first. The [setup guide in the docs](https://openwearables.io/docs/providers/withings-api-integration) covers the local development path. ### How is sleep reported? As the night's stage timeline, with minutes in deep, light, REM and awake, plus total duration, time in bed, efficiency and whether it was a nap. The night's lowest heart rate is kept as resting heart rate. ### Which activity types does it recognise? Withings' own categories, mapped to the same taxonomy your other providers use, so a swim from a Withings watch and a swim from another source group together in your queries. ### Does it handle time zones properly? Yes, and Withings makes that easier than most. It sends the time zone by name rather than as a bare offset, so a daily total can be placed on the day the user actually lived, including across daylight saving changes. That happens before the data reaches your schema. ### Why is some of the user's activity missing? A Withings account can hold daily activity that other apps pushed in. Those rows are left out, so the activity that lands in your schema came off a Withings device rather than being copied from elsewhere. ### Can we combine Withings with other sources? Yes, and it is one of the more useful combinations. Withings covers body composition and blood pressure, a watch or a ring covers activity and recovery, and you query the user rather than each provider. ### We already have Withings credentials. What changes? Very little. Bring the client ID and secret, point the deployment at your callback, and the connection flow works from there.