Open Wearables 0.10.0: A Rebuilt Dashboard and Nutrition Data

Open Wearables 0.10.0 was released on 16 October 2026. The two headline changes are a dashboard rebuilt from scratch and support for nutrition data, with 42 new data types. Outgoing webhooks now say which sync each event came from. Calorie data is more accurate across providers. The release merges 123 pull requests in total.

It also contains breaking changes. Most of them touch a single provider or an edge case. Teams running Open Wearables in production should read the list before pulling the new images.

Breaking Changes to Check Before Upgrading

Eight changes can affect an existing integration. The release notes describe each one in full, with the pull request behind it.

• Days without active energy return null for active calories instead of 0, for every provider. Total calories in the activity summary are null when a day has neither total nor basal energy.
• Whoop cycle energy moves to a new total energy series, because the figure includes basal metabolic rate. A startup migration relabels stored rows and deletes stored 0 kJ values, which Whoop reports when the strap was not worn.
• Ultrahuman active minutes move to exercise time. For Ultrahuman users, active minutes in the activity summary fall back to the step-based estimate. A startup migration relabels stored rows.
• Ultrahuman HRV is stored as RMSSD instead of SDNN, which Ultrahuman confirmed. A startup migration relabels stored rows.
• Workouts without calories store null instead of 0 when they come from the mobile SDK or an Apple Health XML import. A startup migration clears the stored zeros.
• SDK refresh tokens of deleted applications are removed. Users of those applications get a 401 on their next refresh. Apps that fetch new tokens from their own backend recover by themselves, as long as that backend uses the credentials of an application that still exists.
• Outgoing webhook payloads are kept for 7 days instead of 90. Retention is configurable from 5 to 90 days. Payloads already stored keep their 90-day expiry.
• 24/7 sync results have a new, typed shape. The new shape appears in the sync endpoint response and in sync webhooks. Sync status events use it too. A sync where every 24/7 task fails now reports failure.

Two of these rename webhook events. Consumers that filter on event names need the new ones:

Whoop cycles:       series.active_energy.created  ->  series.total_energy.created
Ultrahuman minutes: series.active_time.created    ->  series.exercise_time.created

The first startup after upgrading can take longer than usual, because data migrations merge duplicated data sources and relabel the rows listed above. Expensive migrations are now recorded in a dedicated table and run once per instance.

A Dashboard Rebuilt From Scratch

The dashboard is rewritten in SvelteKit. The layout is cleaner and comes with light and dark themes, plus an option to follow the system setting. On a phone it switches to a bottom navigation bar.

Heavy pages load faster. Data Summary opens on the last 30 days by default. Tabs on the user profile have period presets from one week to one year, along with a provider filter. The Sleep tab can filter down to night sleep only or naps only. It can also show just the highest-priority source. Each record now shows which provider and device it came from.

The user profile also gained a Meals tab for the new nutrition data. The Women's Health tab is now always visible, even when a user has no data. Data sources are listed in priority order.

Upgrading the dashboard needs no configuration change. The image name and port stay the same, as does the API URL variable. Developers sign in once more after the upgrade. The API URL is now read at runtime, which means one frontend image works against any backend without a rebuild. Sign-in sessions now live in an HttpOnly cookie that scripts on the page cannot read. Expired access tokens are refreshed automatically. Details are in the frontend configuration docs.

Nutrition Data and Meal Events

Open Wearables now stores nutrition data. The 42 new series types cover calories and macronutrients, with fat broken down into its subtypes, along with a full set of vitamins and minerals.

Apps that log food as meals also produce a new meal event, which carries the meal's title and type along with its nutrients. Nutrition samples logged outside a meal are stored as regular time series, so the data is kept either way.

Apple Health matters most for nutrition. Food trackers such as MyFitnessPal and Cronometer write what users eat into it, as do dozens of other apps. A product connected to Apple Health gets that data without integrating each food app separately, once the mobile SDK sends it.

Health Connect covers all 42 types and Apple Health covers 38 of them. Samsung Health covers 17. The Google Health API nutrition log is supported as well.

Two endpoints expose meals:

GET    /api/v1/users/{user_id}/events/meals?start_date=2026-10-05&end_date=2026-10-05
DELETE /api/v1/users/{user_id}/events/meals/{meal_id}

Outgoing webhooks send a meal once, when it is first saved. A re-sync of the same meal does not send it again.

Current Limitations

On the mobile SDK side, nutrition is supported by the backend only for now. SDK versions that send meals from the phone's health store have not been released yet. Apple Health has no cloud API, so in a live integration its data reaches Open Wearables through an app on the phone. Meals logged on iOS start arriving once that SDK update ships, which the team expects soon. Progress is visible in the iOS SDK and Android SDK repositories. Google Health API nutrition works with this release.

The seed generator can create meals too, with a nutrition-focused preset, which helps when building against the new endpoints before real users have logged anything.

Webhooks That Say Which Sync They Came From

Every data webhook now carries a sync block:

"sync": { "run_id": "backfill_9f3c8ea4", "source": "backfill", "scope": "historical" }

A consumer can use it to tell a historical backfill from a live sync. A newly connected user can backfill months of history through the same endpoint that handles today's data. With the scope in the payload, a product can, for example, store backfilled rows without sending a notification for each one.

The source field records how the data arrived, for example a provider pull or a mobile SDK upload. The run ID joins to the sync history endpoint introduced in Open Wearables 0.8.0.

Two new events report results per data type, one when a data type completes and one when it fails. Each carries item counts plus the time ranges that were written and covered. Existing payloads only gain the new key, so consumers that ignore unknown fields keep working.

Total Energy Next to Active and Basal

Some providers report a total energy figure with no split between active and basal energy. Those now write to a new total energy series with its own webhook event. Today that applies to Whoop.

Basal energy is now stored for Garmin, Polar, Oura and SensorBio. Total calories in the activity summary come from the total energy series first, with active plus basal as the fallback.

Whoop cycle metrics are also anchored on the correct local day. Users in negative UTC offsets no longer get two cycles summed into one day.

This continues the energy work from Open Wearables 0.9.0, which renamed the active energy series and corrected Google Health API calorie data.

One Device, One Data Source

Before this release, one device or app could end up as several data sources. A user renaming their iPhone was enough to cause it. Upgrading the phone that relays third-party Apple Health data had the same effect.

Sources are now matched by device ID first, then by app bundle ID and model. An existing source is upgraded when better data arrives for it. A startup migration merges the duplicates already stored. New device types were added as well, among them chest straps and glucose meters.

More Data From Existing Providers

Several existing integrations store more data in this release:

• Exercise time, meaning moderate plus vigorous minutes, for Garmin, Oura, Withings, Ultrahuman, Polar and Google Health.
• Skin temperature deviation for Garmin and Ultrahuman. Google Health reports it too.
• Per-minute step samples for Polar and Withings, with distance and active energy from Withings as well.
• Resting heart rate for Ultrahuman and Withings.
• Sleep stage timelines for Withings and SensorBio. Withings sleep stages were not supported when the integration arrived in 0.8.0.
• Polar Nightly Recharge HRV and breathing rate, now stored as time series.
• HRV RMSSD from HealthKit on iOS 27 and later.

The full matrix of what each provider supports is in the data coverage docs.

API Additions

A new personal record endpoint reads and sets a user's birth date and sex. Nothing could write these values before, so the activity summary always assumed a maximum heart rate of 190 bpm.

Sleep events accept a nap filter. Sleep summaries now page by night and recovery summaries by day, instead of by stored row. Pagination stays correct when several sources recorded the same nights.

Privacy and Self-Hosting Changes

Sentry no longer receives health data or personal data by default. Request bodies and log breadcrumbs stay out of error reports. Email addresses and query values are filtered. Development and staging environments can turn sensitive data back on when debugging needs it.

Deleting a user now also deletes their outgoing webhook payloads from Svix. Signing in to the portal with the public default password now forces a password change, which cannot be skipped in production.

A few changes help with self-hosting:

• Invitation emails can go through any SMTP provider. When no email delivery is configured, the portal shows the invite link instead of reporting that an email was sent.
• Logs can be written as JSON or text with a configurable level. An optional OpenTelemetry export is available.
• Containers stop gracefully. Throttled provider requests back off instead of failing the sync.
• The backend runs on Python 3.14. Locally built images need a rebuild.

The backend also gains an extension point. Separately packaged Python modules can register background tasks and API routes under their own path, behind the core's API auth. An extension that fails to load is logged and skipped, so it does not stop the backend from starting.

Anonymous Usage Telemetry

Self-hosted instances now send one small anonymous usage ping a day, plus one on startup. The team uses it to decide what to build next and what is safe to deprecate.

Counts go out as order-of-magnitude buckets and endpoints as route templates. The ping carries no health data or user data. It also leaves out credentials, hostnames, IP addresses and URLs. The collected data serves roadmap and triage decisions. It is never sold or shared.

Either setting turns the ping off:

TELEMETRY_ENABLED=false
DO_NOT_TRACK=1

The telemetry docs document the ping in full.

Upgrading

Upgrading is a standard Docker Compose update:

docker compose pull
docker compose up -d

Read the breaking changes first. Migrations run automatically on startup. The first start can take longer while they merge data sources and relabel rows. Developers sign in again once after the upgrade.

If you run SDK apps, the release notes include a SQL query that finds active SDK users of deleted applications, so you can check exposure before upgrading. Official Docker images remain the recommended deployment path. Pin a version for production.

The full changelog is at github.com/the-momentum/open-wearables/releases/tag/0.10.0.

Community

Open Wearables has 2,717 stars on GitHub and 532 forks, with 63 contributors to date. Two people made their first contribution in this release.

The project is at github.com/the-momentum/open-wearables. The Discord community is the fastest place to get an answer.

What's Next

0.11 follows soon and continues work on the data model as the project heads toward Open Wearables 1.0. The team wants input on what 1.0 should include, especially from teams that have run Open Wearables in production for a while. Discord and GitHub Discussions are the places to send it.

Teams still choosing how to bring wearable data into their product can start with the Open Wearables FAQ on avoiding vendor lock-in or the one-click deployment guide. Momentum also helps teams build wearable integrations on top of the platform and run it on HIPAA-ready infrastructure.