Key Takeaways
- 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.
- 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.
- Strava is now a full provider, bringing the total to seven supported platforms (Garmin, Polar, Suunto, Whoop, Apple Health, Samsung Health Connect, Strava).
- The MCP Server now supports workout data retrieval, activity listing, and health data presentation prompts, expanding what you can query through Claude or ChatGPT.
- 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?
.avif)
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 initThe 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
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.






