Open Wearables 0.7.0: Google Health API, Sensor Bio, and a faster Admin UI
Key takeaways
- New: Google Health API integration. OAuth 2.0, aggregates data from every source connected to a user's Google Health account (Fitbit, Google Fit, and more), delivered via polling or notify-only webhooks.
- Fitbit integration is now feature-frozen. Google is turning down the legacy Fitbit Web API in September 2026; the Google Health API is the path forward and already surfaces Fitbit as a source.
- New: Sensor Bio integration. Workouts, sleep with stages, recovery scores, and continuous 24/7 biometrics via OAuth 2.0 (polling only — Sensor Bio's own API doesn't offer webhooks yet).
- Oura sleep stages now sync at 30-second granularity, up from 5-minute.
- Admin UI dashboard loads noticeably faster and shows more detail on stored data volume and type.
- More data provenance detail: original provider and source device now shown per data point, where available.
- New: delete all data for a specific provider from the user profile (auto-disconnects that provider).
- New: SDK application management directly in Admin UI Settings.
- Logging: a bad row in an SDK sync batch no longer drops the whole batch; more diagnostic fields added to HTTP and Celery worker logs.
Introduction
Open Wearables 0.7.0 is out. This release adds two new provider integrations, Google Health API and Sensor Bio, along with a round of improvements to the Admin UI, data source visibility, and backend logging.
Google Health API
Open Wearables now integrates with the Google Health API, a server-side OAuth 2.0 flow that lets you connect a user's Google account and pull their health data over REST, plus receive notify-only webhooks.
Google Health data reaches Open Wearables through two independent paths that share a single google provider identity:
- Health Connect (mobile SDK) – data pushed from an Android device via the Sync SDK.
- Google Health API (cloud OAuth) – a server-side OAuth 2.0 flow against the Google Health API.
These two paths don't feed into each other. The Google Health API doesn't pull data from the Health Connect SDK path; rather, both draw from the same underlying Google Health account, just through different mechanisms. On the cloud OAuth side, the Google Health API acts as an aggregation layer: it surfaces data from every source connected to a user's Google Health account, including Fitbit, Google Fit, and other connected apps, not just one device.
Supported data types include steps, distance, calories, hydration, heart rate, resting heart rate, HRV (RMSSD and SDNN), VO₂ max, respiratory rate, SpO₂, weight, body fat, core body temperature, blood glucose, workouts, and sleep with stages.
Data delivery works two ways: polling via Celery Beat, and notify-only webhooks where Google sends a lightweight ping naming the changed data type and time interval, and Open Wearables then fetches the changed data over REST.
A notable detail is how Open Wearables handles overlapping data from multiple sources. The Health API exposes the same data through three operations, controlled by a DEFAULT_DATA_GRANULARITY setting and, at the finest granularity, a GOOGLE_USE_RECONCILE flag:
- Reconcile (default) returns one merged, deduplicated stream across all sources, matching what the native Google Health or Fitbit app displays. Reconciled points carry no device attribution.
- List returns raw per-source points tagged with their originating device, preserving device attribution. Open Wearables deduplicates on read by source priority rather than summing values.
Reconcile is the default because it produces app-accurate totals: in a documented example where a user's phone and Fitbit MobileTrack both tracked the same day, list-mode dedup would pick a single source (1,919 steps), while reconcile merges the overlap and returns 2,560 steps, matching the native health app exactly.
Since Google is deprecating the legacy Fitbit Web API in September 2026, the Google Health API is positioned as its replacement going forward, as it already surfaces Fitbit as one of its aggregated sources.
Sensor Bio
Open Wearables also adds a new integration with Sensor Bio, connected via OAuth 2.0 with pull-based syncing. Sensor Bio's own API does not currently offer webhooks, so this integration is polling-only.
Supported data types:
- Workouts / activities
- Sleep, including stage breakdown (deep, light, REM, awake)
- Recovery (score, resting heart rate, HRV, SpO2)
- Continuous 24/7 biometric timeseries (heart rate, HRV, SpO2, respiratory rate)
- Daily step details (steps, distance, calories)
Body measurements are not available via the Sensor Bio API.
A few integration-specific quirks documented for this provider:
- The continuous biometrics endpoint (/v1/biometrics) uses cursor-based pagination and can return hundreds of timestamped samples per poll window, unlike day-aggregated providers.
- Biometric timeseries timestamps are in milliseconds since epoch, while sleep endpoint timestamps are in seconds since epoch.
- Sleep and recovery data are fetched one day at a time, since the Sensor Bio API requires a single date parameter rather than supporting a multi-day range.
- Sensor Bio does not label naps; sessions are stored with is_nap=false.
Oura: finer sleep stage granularity
Open Wearables now uses Oura's 30-second sleep stage granularity instead of the previous 5-minute granularity, giving more precise sleep stage data for Oura users.
Admin UI dashboard improvements
The Admin UI dashboard has been optimized for faster loading. On less efficient infrastructure, the dashboard could previously take several seconds to load data. Improvements to React and the removal of unnecessary information mean the dashboard should now load instantly, even with large volumes of data and limited RAM.
The dashboard also now shows more detail about the volume and type of stored data, and displays large numbers correctly (previously, values in the millions were shown in thousands).
More detail on data sources
On the frontend, each piece of data (workouts, sleep sessions, menstrual cycles, activity) now displays more information. Previously, only the provider from which the data was saved was shown. Now, the original provider is also displayed where applicable (for example, Apple allows data to be synced from devices belonging to other providers), along with the device the data was retrieved from.
Open Wearables notes that gaps in this information are expected for now, since fully populating it requires further changes to how data is fetched from sources; this is planned for a future release.
Delete data by provider
The user profile now includes an option to delete data associated with a selected provider. This also automatically disconnects that provider's connection.
SDK application management in Settings
SDK applications can now be managed directly from the Admin UI's Settings section.
Logging improvements
Two changes improve reliability and debuggability of the SDK sync process.
Partial batch failures. Previously, a single incorrect row in an SDK sync batch caused the entire batch to be lost. Now, Open Wearables reports the sync status for the problematic rows individually and logs their exact errors to Sentry, so the rest of the batch is no longer discarded.
Richer log data. HTTP logs now include additional fields: response_body, request_bytes, error_cause_type, error_cause_msg, content_type, and content_encoding. Celery worker logs for SDK syncs now include fields such as first_error_loc, data_type, success, record_count, task_type, low_power, thermal_state, and types, useful for diagnosing sync issues in production.
Also in this release
- Support for deregistering providers that use a Cloud API.
- A fix so that webhook-fetched Oura payloads are correctly stored to raw storage.
- Documentation updates: a note on the Fitbit Web API sunset, provider setup guides for Oura and Suunto, clarification of invitation code vs. backend token onboarding flows, and a description of supported providers without a fixed count (the provider list keeps growing).
Upgrading
Official Docker images are available for both backend and frontend:
- Backend: themomentum/open-wearables-backend
- Frontend: themomentum/open-wearables-frontend
See the 0.7.0 release notes for the full changelog, and the documentation for setup guides for Google Health API and Sensor Bio.
Frequently asked questions
Does this replace the existing Fitbit integration?
Not automatically. The Fitbit integration stays available and supported as-is, but it's feature-frozen: no new data types or features will be added. The Google Health API is the recommended path forward, and it already surfaces Fitbit as one of its aggregated sources.
Do existing Fitbit connections carry over to the Google Health API automatically?
No. Existing Fitbit access and refresh tokens cannot be reused. Each user needs to go through the Google OAuth flow again to reconnect.
What's the difference between reconcile and list fetch modes for Google Health?
reconcile (the default) returns one merged, deduplicated stream across all of a user's connected sources, matching what the native Google Health or Fitbit app shows, but without per-device attribution. list returns raw per-source data points tagged with their originating device, preserving device attribution, and Open Wearables deduplicates on read by source priority.
Does the Sensor Bio integration support webhooks?
No. Sensor Bio's own API doesn't currently offer webhooks, so this integration is polling-only.
What data can't Sensor Bio provide?
Body measurements are not available through the Sensor Bio API.
How do I upgrade?
Pull the official Docker images: themomentum/open-wearables-backend and themomentum/open-wearables-frontend.
See related articles
Google Health API: A Practical Guide to Getting Started
Google Health API and Google Health Connect: What's the Difference