Open Wearables 0.5.2: Polar Refactor, Expanded Sport Types, and Stricter HRV Data Integrity

Introduction

Version 0.5.2 of Open Wearables is out. The codename is "Polar refactor," and that tells you most of what you need to know about the headline change. But the release covers more ground than that: expanded sport type coverage, a new API endpoint, tighter data integrity for HRV scoring, and a set of reliability fixes that address real edge cases in production deployments.

This post walks through what changed, why it matters, and where the tradeoffs are. The Polar webhook addition is a developer ergonomics improvement worth understanding in context. The RMSSD enforcement decision is a data integrity call with a real cost, and it deserves an honest explanation rather than just a changelog entry.

If you are new to Open Wearables, the quickstart guide is the fastest path to a working integration. The full documentation covers the platform architecture, including the 4-layer model: Wearable Data, Health Scores, Health AI Engine, and Coaching Profiles.

Polar Refactor and Webhook Support

The previous Polar integration had gaps. Sleep data and timeseries data were not synchronising correctly, which meant any application relying on Polar as a primary source was getting incomplete data or no data at all for those categories. The 0.5.2 refactor addresses this directly.

Periodic Pull remains the default sync method. When a user connects a Polar account, the platform will continue to fetch data on a scheduled basis without any additional configuration. That behavior has not changed.

What is new is the option to enable webhooks. You can activate them under Settings > Providers. When webhooks are active, Polar pushes data to Open Wearables as events occur rather than waiting for the next polling cycle. For applications where data freshness matters, this is a meaningful improvement. Coaching applications that surface real-time readiness scores, clinical workflows that need sleep data the same morning it is recorded, and any integration where a 15-minute polling window creates friction will benefit from this.

The architectural point is worth stating plainly: webhook-based ingestion does not change what data you receive, it changes when you receive it. If your use case is comfortable with periodic pulls and the latency is acceptable, you do not need to touch anything. If it is not, the option is now there.

This is also a good moment to note what the Polar refactor represents at the platform level. Open Wearables is built around the principle of health intelligence, not just health data. Clean, timely ingestion from each provider is the foundation that makes downstream scoring and AI-driven insights reliable. A partial Polar integration was a gap in that foundation. 0.5.2 closes it.

Expanded Sport Type Coverage

The WorkoutType enum in Open Wearables has always included a catch-all WorkoutType.OTHER for activities that did not have an explicit mapping. That was a pragmatic decision early in the project development, but it has costs at scale.

When you aggregate workout data across Apple Health, Garmin, Suunto, and WHOOP, the OTHER bucket becomes a noise source. You cannot reliably filter by activity, build sport-specific training load models, or surface meaningful coaching insights for activities that are all labelled identically.

0.5.2 moves more than 70 provider-specific mappings out of OTHER and into named types. The newly explicit sports include cricket, lacrosse, racquetball, bowling, archery, fencing, fishing, wakeboarding, parkour, and curling, among others. Each of these now has a discrete identifier that travels cleanly through the platform data model.

For most existing deployments this is a non-breaking addition. If your application references WorkoutType.OTHER, you may find that some activities which previously landed there now resolve to a named type. Review the updated enum definitions in the documentation if that affects downstream logic in your codebase.

The broader point is about data quality at the source. Open algorithms and zero black boxes is a design commitment, and that commitment depends on having accurate, granular input data. A workout recorded as OTHER is an algorithm that cannot do its job properly.

New Garmin Fields

Garmin device ecosystem captures a wide range of physiological signals, and the Open Wearables integration has been extended to collect two additional fields: allDayRespiration and moveIQActivities.

allDayRespiration provides continuous breathing rate data across the full day, not just during workouts or sleep. This is relevant for applications that model stress, recovery, and baseline autonomic function. moveIQActivities captures Garmin automatic activity detection: periods of walking, running, or cycling that the device identifies without manual workout logging.

Both fields are added to Garmin-specific attributes in the data model.

Strict RMSSD Enforcement for HRV Scoring

This is the change that requires the most direct explanation.

The HRV-CV Resilience Score in Open Wearables uses overnight RMSSD as its primary input. RMSSD is a time-domain measure of heart rate variability that reflects parasympathetic nervous system activity during sleep. It is the appropriate metric for this score.

Prior to 0.5.2, if overnight RMSSD data was absent, the platform would automatically fall back to SDNN. SDNN is a related but distinct measure: it captures total HRV variability rather than the parasympathetic component specifically. The fallback produced a score, but it was not guaranteed to be methodologically consistent with RMSSD-based scores from other sessions or other users.

In 0.5.2, that fallback is disabled. Users without overnight RMSSD data now receive null for their HRV-CV Resilience Score.

The cost is visible: some users will see no score where they previously saw one. That is an intentional tradeoff. A null result is honest. A score derived from a different metric without disclosure is not.

The SDNN fallback is not gone permanently. It is disabled pending validation work to determine whether a cross-metric normalization approach can produce scores that are sufficiently consistent for clinical and coaching use. If that validation succeeds, a properly calibrated fallback may return in a future release. Until it does, strictness is the right default.

For developers: if you are surfacing the HRV-CV Resilience Score in an application, handle null gracefully. The documentation covers the score methodology and the data requirements.

New Recovery Summary Endpoint

0.5.2 adds a recovery summary endpoint to the API. This aggregates recovery-relevant signals into a single response, reducing the number of calls needed to build a complete recovery view for a given user. Details are in the API documentation.

Reliability Fixes

Several fixes in this release address edge cases that surface in production deployments at any meaningful scale.

Session handling for Oura and WHOOP has been improved: each data type is now committed individually, and the session is rolled back on exception. This prevents partial writes from corrupting a sync run when one data type fails. The behavior is more predictable and easier to reason about in error scenarios.

Duplicate EventRecordDetail inserts are now handled gracefully with savepoints, rather than failing the entire operation. Date parameter validation in OpenAPI specs has been tightened. Invalid user rows are skipped during email validation rather than halting the process. Suunto live workout push now correctly emits outgoing webhooks.

These are not headline features, but they represent the kind of work that makes a platform reliable rather than just functional. At the $0 per user pricing model, the infrastructure cost is yours to manage. That makes stability and predictability in the data layer more important, not less.

Getting Started

If you are evaluating Open Wearables for a healthtech project, the fastest path is the quickstart guide. It covers environment setup, provider connection, and your first API call.

The GitHub repository contains the full source, including the updated WorkoutType enum, the Polar webhook configuration, and the new recovery summary endpoint. The project is MIT licensed.

For teams building more complex integrations, the Momentum healthtech services page describes how we work with product teams on architecture, implementation, and ongoing development.