Open Wearables 0.4: Oura Ring, React Native SDK

Overview

Open Wearables 0.4 officially shipped on March 20, 2026. This release adds a new wearable provider (Oura Ring), a new mobile SDK (React Native), and several features that make the platform more production-ready like raw payload storage, provider disconnect, configurable data retention, and a production docker-compose setup.

Since we launched Open Wearables as an open-source API for health data integration, the community has grown significantly - the release marks a community milestone since it crossed 1,000 GitHub stars, driven by a viral post on X.

More significant than the number is the first provider integration built entirely by a community member has been shipped in this release.

What Is Open Wearables

Open Wearables is an open-source, self-hosted platform for health intelligence. It normalizes wearable data from multiple providers into a consistent API, so your application can focus on intelligence rather than integration plumbing.

You deploy it on your own infrastructure and connect users wearable accounts through OAuth or a mobile SDK. The application gets structured, data is deduplicated in a consistent format, regardless of device or platform.

The platform has four layers:

• Wearable Data (live, 10 providers),
• Health Scores (in development),
• Health AI Engine (in development),
• and Coaching Profiles (planned).

Layer 1 is production-ready. Layers 2 through 4 are where the platform is heading: open algorithms for sleep, recovery, and strain scores; AI reasoning tools; and domain-specific coaching intelligence.

Oura Ring Integration

Oura Ring support was contributed by @vikohone through PR #454. This is the first wearable provider integration contributed entirely by someone outside the Momentum engineering team.

The integration follows the same pattern as existing providers. 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 will work without changes to your application code. For readers evaluating Oura's sleep and HRV data quality, this breakdown of HRV accuracy across wrist-worn devices is a useful reference.

With Oura, the platform now supports 10 providers: Garmin, Polar, Suunto, Whoop, Strava, Apple Health (via SDK), Samsung Health (via SDK), Google Health Connect (via SDK), and Oura Ring.

What this means for the community model? The fact that a community member could build a complete provider integration, from OAuth flow to data normalization, and ship it through the standard PR process says something about the architecture's extensibility. The provider abstraction layer is working as designed: add a new provider without modifying the core platform.

React Native SDK

The React Native SDK is now available. This completes the mobile SDK lineup:

• iOS SDK (Swift): Apple HealthKit sync
• Android SDK (Kotlin): Samsung Health and Google Health Connect
• Flutter SDK (Dart): Cross-platform wrapper around iOS and Android SDKs
• React Native SDK: Cross-platform option for React Native developers

All SDKs share the same push-based architecture: health data stays on-device, and the SDK handles background sync to your Open Wearables instance using incremental queries.

React Native was one of the most requested SDK option in Discord and GitHub issues so if you're building a React Native health app, you no longer need to write native bridges to access wearable data through Open Wearables.

Raw Payload Storage and Replay

You can now optionally store raw incoming payloads from all providers to S3. Every data payload that arrives from Garmin, Whoop, Oura, or any other provider gets archived in its original form before normalization.

This is useful for:

• Debugging: When normalized data looks wrong, check the raw payload to determine whether the issue is in the provider's data or in the normalization logic.
• Auditing: Maintain a complete record of all incoming data for compliance or internal review.
• Reprocessing: If you fix a bug in data normalization, replay stored payloads through the updated pipeline without asking users to re-sync their devices.

The release includes a replay script that re-ingests stored payloads on demand.

Documentation is at docs.openwearables.io/dev-guides/raw-payload-storage.

Provider Disconnect API

You can now disconnect users from wearable providers through the API via a new endpoint (API reference). Previously, disconnecting a provider required direct database manipulation.

Garmin is the first provider to support full deregistration through their API, meaning the disconnect is communicated back to Garmin's servers. Other providers will be added progressively, with no changes needed on your end when they are.

This completes the provider lifecycle: connect, sync, and disconnect, all through the API.

Apple Health Improvements

Apple Health XML import received several upgrades in this release:

• Sleep record handling (#583): Better parsing and normalization of sleep data from XML exports.
• Sleep stage timestamps (#567): Accurate stage-level timestamps for sleep analysis.
• Data source extraction (#582): Improved detection of which device produced each data point.
• Timezone-aware storage (#608): Datetimes now include timezone offsets, fixing issues with cross-timezone data analysis.

The iOS SDK also received fixes. If you're integrating sleep data via Apple Health, this release addresses several edge cases that could produce inaccurate results. If you're working with Apple Health data specifically, our Apple Health MCP Server extends this further for AI-powered workflows.

Production Infrastructure

Archive and Retention Policy

New configurable archive and retention policy with storage growth projections (#535). As your user base grows, historical data accumulates. This feature lets you define how long to keep detailed data versus archived summaries, with projected storage requirements so you can plan infrastructure costs.

Production Docker Compose

A dedicated production docker-compose configuration is now available (#617). The previous setup was development-oriented. The production config includes appropriate resource limits, logging configuration, and service dependencies for running Open Wearables in production.

Redesigned Mobile App Connection Flow

The invitation code dialog has been redesigned into a smoother mobile app connection flow (#561). End users connecting their wearable devices through your app will see a cleaner onboarding experience. Documentation is at docs.openwearables.io/sdk/flutter/example-app.

Additional Improvements

• Password change endpoint with complexity validation (#550, #631)
• Configurable Sentry server_name via environment variable (#626)
• Unified uvicorn log format (#628)
• Event loop optimization for sync endpoints (#623)
• Updated documentation: Polar provider setup guide, mobile SDK docs, Apple Health coverage matrix, roadmap

Community Growth

Open Wearables crossed 1,000 GitHub stars in mid-March after a viral post on X. As of this writing: 1,094 GitHub stars, 150 forks, 23 contributors.

The star count is a vanity metric on its own, but the growth pattern is meaningful. The viral post brought visibility, and many of those visitors stayed to open issues, join Discord, and contribute code. The Oura Ring integration that shipped in this release is a direct result of that community growth.

More Frequent Releases

Starting with v0.4, Open Wearables is moving to more frequent, smaller releases. The previous biweekly cadence sometimes bundled too many changes, making upgrades harder for teams with specific implementation dependencies. Smaller releases mean less upgrade friction and faster access to fixes.

{{lead-magnet}}

Getting Started

If you're already running Open Wearables, update to 0.4:

git pull origin main
docker-compose down && docker-compose up -d

‍New to Open Wearables? The quickstart is at docs.openwearables.io/quickstart. You can deploy with Docker Compose or one-click on Railway and make your first API call in about 5 minutes. The platform connects 10 wearable providers through a unified API, self-hosted on your infrastructure with zero per-user fees. MIT licensed.

What's Next

The roadmap is community-driven through GitHub issues. High-priority items include:

• Fitbit integration (most requested provider)
• Expanded health endpoints (heart rate zones, body metrics, stress, recovery)
• Health insight automations with webhooks
• Connection widgets for easier end-user onboarding

Contributions are welcome.
The Oura Ring integration proves the pattern: if you need a provider or feature, the codebase is structured to support external contributions.

Need Help?

• Documentation: docs.openwearables.io
• GitHub: github.com/the-momentum/open-wearables
• Discord: Join the community
• Release notes: v0.4 on GitHub