Google Health API
Integration
Connect Google Health via OAuth 2.0 to sync 24/7 metrics, workouts, and sleep, aggregated from every source connected to a user's Google Health account. Open Wearables handles the OAuth flow, sync, and normalization into one unified API.
What you get from the Google Health API.
Daily 24/7 totals, aggregated across sources
Logged water intake
Continuous 24/7 measurements
Both HRV measures
Fitness and breathing metrics
Blood oxygen from connected devices
From paired scales
From connected sources
From CGM or paired devices
Exercise sessions, all types
Full sleep sessions
This is an aggregation layer: it surfaces data from every source connected to a user's Google Health account, not just one device or app.
How Google Health API integration works.
User connects their Google account
Open Wearables handles the Google Health OAuth 2.0 flow. Your users authorize access through Google's standard consent screen, and Open Wearables resolves their stable Google Health user ID for the connection.
Data is fetched and reconciled across sources
Open Wearables pulls data via polling or webhook-triggered fetches, then reconciles overlapping sources (like a phone's step count and a Fitbit's step count for the same day) into one app-accurate total, by default.
Your application calls one unified API
Google Health data lands in the same schema as every other provider. No Google-specific parsing logic, no manual deduplication across sources.
One data point, multiple sources.
Open Wearables picks the accurate one. A user's steps are often reported by more than one source at once, for example their phone and a connected Fitbit. Open Wearables defaults to reconciled data: a single merged, deduplicated total that matches exactly what the user sees in the Google Health app. Per-device attribution is available on request, for cases where you need to know which device recorded a reading.
Reconcile (default)
Merged, deduplicated, app-accurate totals. No per-device attribution.
List
Raw per-source data points, tagged by device. Use when you need to know which device recorded a reading.
Google Health is just the start.
One API, every provider. Plus health scores and AI reasoning.
All providers, one schema
Garmin, Whoop, Oura, Strava, Apple Health, Polar, Suunto, Samsung Health. Same endpoints, same data format.
See all providers →Open health scores
Sleep, recovery, strain, stress, HRV, VO2 max. Open algorithms you can audit and tune for your population.
Explore scores →AI reasoning engine
MCP server for any LLM. Detect trends, flag anomalies, build coaching profiles for wellness, performance, or clinical use cases.
Learn more →Open Wearables vs SaaS vs native Google Health API.
| Aspect | Native Google Health API | SaaS APIs | Open Wearables |
|---|---|---|---|
| OAuth implementation | You build and maintain it | Handled by provider | Handled by Open Wearables |
| Cross-source deduplication | You implement reconcile logic yourself | Depends on vendor | Reconciled by default, app-accurate |
| Webhook handling | You build the subscriber registration and verification | Handled by provider | Handled by Open Wearables |
| Data normalization | Google-specific response format | Provider-defined schema | Unified schema across all providers |
| Multi-provider support | Separate integration per provider | Depends on vendor tier | One unified API for all providers |
| Per-user pricing | No platform fee | Charged per connected user | Self-hosted |
| Data ownership | You own all data | Vendor stores your users' data | You own all data |
← scroll to see all →
Why use Open Wearables for the Google Health API.
One integration, many sources
The Google Health API surfaces Fitbit, Health Connect, Google Fit, and other connected apps through a single OAuth connection. Open Wearables handles that aggregation without extra setup.
App-accurate totals by default
Reconciled data matches what users see in the Google Health app, so your numbers do not disagree with the app they already trust.
Webhooks without the subscriber plumbing
Open Wearables manages the project-level subscriber registration and notification verification, so new data flows in without your team polling constantly.
A real migration path from Fitbit
Fitbit's Web API is being shut down in September 2026. The Google Health API is the direct successor, and Open Wearables uses the same schema and endpoints, so switching does not mean rebuilding your data layer.
Up and running in minutes.
GET /v1/timeseries/steps
{
"date": "2026-01-15",
"source": { "provider": "google" },
"steps": 9841,
"distance_m": 7300,
"heart_rate_avg_bpm": 78,
"calories_kcal": 2140
}
Open Wearables is open-source and self-hosted. To use the Google Health API integration, enable the Health API on a Google Cloud project, create OAuth client credentials, and configure them in your deployment.
Google Health data in your app,
aggregated from every connected source.
Open Wearables handles OAuth, cross-source reconciliation, webhooks, and normalization. MIT licensed. Self-hosted.
Common questions.
What is the Google Health API?
The Google Health API is Google's cloud OAuth layer for health and fitness data. It lets you connect a user's Google account and pull their data over REST, aggregated from every source connected to that account.
Is this the same as Google Health Connect?
No, they are related but different. Google Health Connect is an on-device Android data store, integrated through a mobile SDK. The Google Health API is a separate, server-side OAuth flow that aggregates data at the account level, including Health Connect, Fitbit, and Google Fit data. Open Wearables supports both under the same "google" provider identity.
Does the Google Health API include Fitbit data?
Yes. Since Fitbit accounts can connect to Google Health, the Google Health API surfaces that data alongside Health Connect and other sources. This makes it the recommended path forward as Fitbit's own Web API is being shut down in September 2026.
Is the Google Health API replacing the Google Fit API?
Google has deprecated the Google Fit API and directs developers to the Google Health API and Health Connect going forward. Open Wearables integrates with the current Google Health API, so you are building against Google's supported path rather than a deprecated one.
Does Open Wearables support Google Health webhooks?
Yes. Google Health webhooks are notify-only: a notification names the changed data type and time range, and Open Wearables fetches the updated data over REST. Open Wearables handles the subscriber registration and verification.
What does "reconciled" data mean?
When multiple sources report the same metric (for example, a phone and a Fitbit both counting steps), Open Wearables can return one merged, deduplicated total that matches the Google Health app, or the raw per-source values if you need device-level attribution.
Which other providers can I connect alongside the Google Health API?
Open Wearables currently integrates with Garmin, Polar, Whoop, Strava, Apple Health, Samsung Health, Google Health Connect, Suunto, Oura, and Fitbit. All providers share the same unified API schema.
Is Open Wearables production-ready?
Yes. Open Wearables is actively maintained and used in production. Check the GitHub releases for the current status of each provider integration.
Open Wearables is built and maintained by Momentum, a digital health agency reshaping healthcare through technology. Since 2016, they have been turning medical discoveries into compliant, scalable digital solutions. Momentum offers commercial services on top of Open Wearables for teams that need custom integrations, enterprise deployment, or SLA-backed support.
themomentum.ai →Other integrations
Comparing options? See how Open Wearables compares to Terra, ROOK, Sahha and others →
One API. Every provider. Self-hosted.
Deploy Open Wearables on your infrastructure. MIT licensed. Self-hosted.