Insights

Open Wearables 0.3.0-beta: Strava Integration, Apple Health SDK Maturation, and Data Source Priority

Author
Bartosz Michalak
Published
February 16, 2026
Last update
February 16, 2026

Table of Contents

EXCLUSIVE LAUNCH
AI Implementation in Healthcare Masterclass
Start the course

Key Takeaways

  1. The Apple Health SDK now uses invitation code onboarding instead of SDK tokens, simplifying the developer and user experience. Refresh token support and structured logging make the SDK more production-ready.
  2. Data source prioritization is configurable at two layers: provider level and device type level. When multiple devices report the same metric, you control which value wins.
  3. Strava is now a full provider, bringing the total to seven supported platforms (Garmin, Polar, Suunto, Whoop, Apple Health, Samsung Health Connect, Strava).
  4. The MCP Server now supports workout data retrieval, activity listing, and health data presentation prompts, expanding what you can query through Claude or ChatGPT.
  5. Community growth continues: 508 GitHub stars, 38 forks, 15 contributors. Eight contributors worked on this release, three of them new to the project.

Is Your HealthTech Product Built for Success in Digital Health?

Download the Playbook

Open Wearables 0.3.0-beta is available on GitHub. This release focuses on hardening the features introduced in the 0.3.0-alpha: the Apple Health SDK is more production-ready, data source prioritization gives you control over overlapping metrics, and Strava joins as a full provider.

The alpha introduced new capabilities. The beta makes them reliable.

Apple Health SDK Maturation

The biggest changes in this release are to the Apple Health SDK integration. The 0.3.0-alpha shipped the Flutter SDK (health_bg_sync) with background sync and historical backfill. The beta addresses the rough edges that showed up during real-world testing.

Invitation Code Onboarding

The SDK previously required developers to manage SDK tokens manually. In 0.3.0-beta, onboarding uses invitation codes instead. A developer generates an invitation code through the API, the user enters it in the mobile app, and the SDK handles authentication from there.

This removes the token management overhead. You don't need to build a custom flow to pass SDK tokens to your mobile app. The invitation code is a one-time entry that establishes the connection.

Refresh Token Support

The SDK and developer authentication now support refresh tokens. Sessions persist across app restarts without requiring re-authentication. For background sync scenarios where the app runs unattended, this is essential.

Structured Logging and Validation

Data synchronization now includes structured logging with batch tracking. Each sync operation gets a batch ID, making it possible to trace specific data points through the pipeline when debugging production issues.

Request body validation has been added to the sync endpoints. Invalid payloads are rejected early with clear error messages, rather than causing failures deeper in the processing pipeline.

The API endpoints have also been reorganized for a cleaner structure, aligning with the patterns used by the cloud-based provider integrations.

Current Limitations

The Apple Health SDK is functional but still in beta. Known limitations:

  • Source prioritization within Apple Health (when Apple Health itself stores data from multiple sources, like an Apple Watch and a third-party app) is handled at the platform level through the new data source priority system, but edge cases remain.
  • SDK connections don't yet appear in provider lists in the developer portal, despite syncing data correctly.
  • Sync monitoring (volume, completion status, error details) is limited compared to the cloud-based providers.

These are tracked in GitHub issues and actively being addressed.

Data Source Prioritization

When a user wears an Apple Watch and carries an iPhone, both devices report step counts to Apple Health. When that user also has a Garmin watch, you potentially have three sources for the same metric. Which value should your application use?

Version 0.3.0-beta introduces configurable data source prioritization at two layers:

Provider priority determines which wearable platform takes precedence when multiple providers report the same metric. If a user has both Garmin and Apple Health connected, you can configure which provider's data wins.

Device type priority handles conflicts within a single provider. Apple Health receives data from Apple Watch, iPhone, and third-party apps. You can configure the priority order for these device types so the platform consistently selects the most accurate source.

Both priority lists are configurable per deployment. The defaults are sensible (dedicated wearables over phones, for example), but you can adjust them based on your application's requirements.

This is a problem that every multi-device health platform eventually hits. Having it solved at the infrastructure level means you don't need to build deduplication logic in your application code.

Strava Integration

Strava is now a full provider in Open Wearables. The integration supports workout and activity data through Strava's OAuth flow.

This brings the total number of supported providers to seven:

  • Cloud-based: Garmin, Polar, Suunto, Whoop, Strava
  • SDK-based: Apple Health (Flutter SDK), Samsung Health Connect

Strava was one of the most requested integrations from the community. For fitness-focused applications, it opens access to a large user base that tracks running, cycling, and other activities primarily through Strava.

MCP Server Expansion

The MCP Server, introduced in the 0.3.0-alpha, has been expanded with new tools:

  • Workout data retrieval: Query workout events from any connected provider through your AI assistant.
  • Activity listing: Browse user activities with filtering and pagination.
  • Health data presentation prompts: Pre-built prompts that help AI assistants format health data in readable summaries.

If you've set up the MCP Server with Claude Desktop or Cursor, you can now ask questions like "What workouts did this user complete last week?" and get structured answers from actual device data.

The MCP setup guide is available at docs.openwearables.io.

Additional Improvements

  • Samsung SDK sync endpoint (beta): Initial sync support for Samsung Health Connect through the SDK path.
  • WHOOP 5.0 device seed data: Updated device database with WHOOP 5.0 support.
  • Garmin webhook optimization: Webhook logging now includes trace IDs and batch processing, making it easier to debug sync issues in production.
  • Bulk data insertion performance: Optimized batch inserts for faster data synchronization, particularly during historical backfills.
  • Simplified user connection architecture: The user connection and device data model has been streamlined, reducing complexity in how the platform tracks which devices belong to which users.
  • Database reset tooling: A Makefile script for database reset, useful during development and testing.

Documentation

Several new documentation pages ship with this release:

  • MCP Server setup guide: Step-by-step configuration for Claude Desktop and Cursor integration.
  • Provider coverage matrix: Which data types are available from which providers, in a single reference table.
  • Data source priority architecture: How the two-layer priority system works and how to configure it.
  • API testing and debugging guide: Tools and techniques for testing provider integrations and debugging sync issues.

All documentation is available at docs.openwearables.io.

Community

The project has grown to 508 GitHub stars (up from 347 at the 0.3.0-alpha release), 38 forks, and 15 contributors. Eight contributors worked on this release, three of them contributing for the first time.

The community continues to drive feature priorities. Strava integration, for example, was consistently requested in GitHub issues before being implemented. Provider coverage and data source handling remain the top areas of community interest.

If you want to contribute, the GitHub repository has labeled issues for different skill levels, and the Discord community is active for questions and discussions.

Getting Started

New to Open Wearables?

git clone <https://github.com/the-momentum/open-wearables.git>
cd open-wearables
cp ./backend/config/.env.example ./backend/config/.env
cp ./frontend/.env.example ./frontend/.env
docker compose up -d
make init

The developer portal runs at http://localhost:3000 and the API docs at http://localhost:8000/docs. The full quickstart guide is at docs.openwearables.io/quickstart.

Upgrading from 0.3.0-alpha? Pull the latest release and restart your Docker services. Check the release notes for any configuration changes.

What's Next

The roadmap continues to be driven by community issues on GitHub. Current priorities include:

  • React Native SDK development (in progress)
  • Additional provider integrations based on community demand
  • Sync monitoring and observability improvements
  • Health insights automations

The platform is at version 0.3.0-beta, which means it's deployed and running in real applications, but APIs may change before v1.0. Pin your version and test updates before deploying to production.

Full release notes and changelog: GitHub Release 0.3.0-beta

Need Help Implementing Open Wearables?

If you're building a health or fitness application and want help with wearable data integration, reach out to the Momentum team. We built Open Wearables and can help you deploy and customize it for your specific use case.

Frequently Asked Questions

Is Open Wearables 0.3 Beta a breaking update?
While 0.3 Beta is designed for stability, it introduces a "maturation" of the Apple Health SDK. This includes refined data mappings and updated background sync logic. If you are migrating from the Alpha version, we recommend checking the updated SDK documentation, as some data object structures for workouts and biometrics have been standardized to ensure consistent cross-platform compatibility.
How does "Data Source Priority" handle overlapping data?
Open Wearables now allows you to set a hierarchy for incoming data. If a user tracks a run on both their Apple Watch and Strava simultaneously, the platform uses your predefined "Data Source Priority" settings to determine which source "wins." This prevents double-counting and ensures your app’s analytics remain accurate even when users sync multiple devices.
Do I need a Strava API Client ID to use the new integration?

Yes. Because Open Wearables is a self-hosted platform, you maintain full control over your integrations. To use the new Strava source, you will need to register your application in the Strava Developer Portal to obtain your own Client ID and Client Secret. These are then added to your Open Wearables environment configuration.

Written by Bartosz Michalak

Director of Engineering
He drives healthcare open-source development at the company, translating strategic vision into practical solutions. With hands-on experience in EHR integrations, FHIR standards, and wearable data ecosystems, he builds bridges between healthcare systems and emerging technologies.

See related articles

Let's Create the Future of Health Together

Looking for a partner who not only understands your challenges but anticipates your future needs? Get in touch, and let’s build something extraordinary in the world of digital health.

Newsletter

Bartosz Michalak

<script type="application/ld+json">
{
 "@context": "https://schema.org",
 "@type": "FAQPage",
 "mainEntity": [
   {
     "@type": "Question",
     "name": "Is Open Wearables 0.3 Beta a breaking update?",
     "acceptedAnswer": {
       "@type": "Answer",
       "text": "While 0.3 Beta is designed for stability, it introduces a maturation of the Apple Health SDK. This includes refined data mappings and updated background sync logic. Developers migrating from Alpha should check the updated SDK documentation for minor data object standardization."
     }
   },
   {
     "@type": "Question",
     "name": "How does Data Source Priority handle overlapping data?",
     "acceptedAnswer": {
       "@type": "Answer",
       "text": "Open Wearables now allows you to set a hierarchy for incoming data. If a user tracks a workout on two devices at once (e.g., Apple Watch and Strava), the platform uses your Data Source Priority settings to select the primary source, preventing double-counting and ensuring data accuracy."
     }
   },
   {
     "@type": "Question",
     "name": "Do I need a Strava API Client ID to use the new integration?",
     "acceptedAnswer": {
       "@type": "Answer",
       "text": "Yes. Since Open Wearables is self-hosted, you must register your application in the Strava Developer Portal to obtain your own Client ID and Client Secret, which are then added to your platform’s environment configuration."
     }
   }
 ]
}
</script>