Open Wearables 0.5.1: Oura & Strava Webhooks and Live Sync Status

Introduction

Open Wearables 0.5.1 is out. The headline addition is webhook support for Oura and Strava, two providers that previously relied entirely on periodic polling. Alongside that, the release introduces live sync status via Server-Sent Events, a redesigned Admin Panel, and RMSSD HRV in the Body Summary endpoint.

This post covers what changed, how each feature works, and what the architectural decisions mean for teams integrating wearable data into production systems. For teams already running 0.5.0, the upgrade path is straightforward. No breaking changes were introduced.

If you’re evaluating wearable data integration for a new project, this release adds meaningful operational tooling: webhook delivery, sync observability, and richer health data in a single endpoint.

Oura and Strava Webhook Support

Until 0.5.1, both Oura and Strava synced exclusively via periodic pull. That model works, but it introduces latency between when a user records an activity or sleep session and when that data appears in your application.

Webhook support changes the flow. When a user completes an Oura sleep session or logs a Strava activity, the provider sends an event to Open Wearables, which then processes and stores the data. For use cases where freshness matters, such as recovery coaching or training load analysis, this significantly reduces the gap between measurement and availability.

The default behavior remains periodic pull only. Webhooks are opt-in per provider and can be activated in Settings > Providers. This preserves backward compatibility for deployments that depend on predictable sync intervals.

One detail worth noting: webhook support for Oura was refactored to align with the new unified webhook pattern introduced in this release. Strava webhooks were built on the same pattern. If you’re extending Open Wearables with a custom provider, the new webhook architecture is the reference implementation.

The technical integration guide is available at docs.openwearables.io. The platform’s approach to wearables integration has always prioritized reliability over speed; webhooks extend that without replacing the pull mechanism.

Live Sync Status

Sync status gives you real-time visibility into what the platform is doing. Previous versions had no structured way to observe sync state from the outside. You could infer it from data arrival, but there was no stream to subscribe to.

0.5.1 introduces sync status via FastAPI SSE. Three surfaces expose it: the Admin Panel, outgoing webhook events, and the pull API.

In the Admin Panel, there’s now a global Syncs tab alongside per-user sync history in individual profiles. Both show current and recent sync states. This is useful for support workflows and for diagnosing data gaps.

For backend integrations, the sync status stream is available at /docs/api-reference/guides/sync-status-stream. SSE keeps a persistent connection open and pushes status updates as they occur. This is the right approach for applications that need to react to sync completion in near real time, for example triggering a score recalculation when new sleep data arrives.

Sync statuses are also available as outgoing webhook events. This matters for persistence: the platform stores sync status in Redis for 24 hours, then discards it. If you need a longer audit trail, consuming outgoing webhook events and storing them in your own database is the supported path. The cost of wearables integration is often underestimated because operational tooling like this is invisible until something breaks. Having a structured sync event stream addresses that gap directly.

RMSSD HRV in Body Summary

RMSSD (Root Mean Square of Successive Differences) is a standard HRV metric used to assess autonomic nervous system activity. It’s commonly used as a recovery signal, particularly in training and clinical contexts.

Prior to 0.5.1, RMSSD was not included in the Body Summary endpoint. This release adds it alongside the existing metrics. For applications that surface recovery scores or readiness indices, this closes a data gap that required manual workarounds.

The addition is part of a broader effort to migrate recovery scores to the health_score model. 0.5.1 moves all recovery scores from data_point_series to health_score, which provides a more consistent data model across the platform. If you’re querying recovery data directly, check the updated endpoint documentation before upgrading.

RMSSD joins other Open Wearables health scores as an open algorithm. There are no black boxes in how the metric is computed or stored. This matters for teams building in regulated environments where auditability of health computations is a requirement. For more context on how Open Wearables handles health data, see the FAQ on vendor lock-in.

Admin Panel Dashboard Redesign

The Admin Panel dashboard has been rebuilt. The previous version surfaced basic metrics. The redesigned dashboard is organized around operational use: sync state across users, per-user health data, and integration status.

For teams using Open Wearables in a production SaaS context, the Admin Panel is often the first place to investigate when a user reports stale data or a sync gap. The new design makes that workflow faster.

It’s a frontend refactor that improves the operational surface without affecting integration code.

Additional Improvements

• Sleep score recalculation after session merge. When multiple short sleep sessions are merged into a single record, the sleep score is now recalculated on the merged session. Previously, the score reflected only one segment.
• Apple Health scope correction. A unit conversion bug (x100 ratio-to-percent) that was incorrectly applied globally has been scoped to the Apple provider only. If you’re using Apple Health data, verify that percent-based metrics are returning correct values after upgrading.
• TypeScript upgrade. The frontend now runs on TypeScript 6.0.2.

Community and Stats

Open Wearables has 1,631 stars and 258 forks on GitHub. If you’re evaluating whether Open Wearables fits your use case, the GitHub repository has the full issue list and roadmap discussions.

Getting Started

For existing deployments, update to 0.5.1:

docker compose pull
docker compose up -d


Webhooks for Oura and Strava are disabled by default. Enable them in Settings > Providers after confirming your deployment has a publicly reachable webhook endpoint.

For sync status integration, see the SSE stream guide. If you’re storing sync events for audit purposes, configure outgoing webhook delivery before relying on the Redis-backed status.

For new deployments, the quickstart is at docs.openwearables.io/quickstart. Docker Compose setup takes under 15 minutes.