Google Health API integrationGoogle Health API data from every app, in your own cloud
One API for Google Health and for the rest of the wearables your users own, connected through the official Google Health API and returned in a single schema. Self-hosted in a cloud account you control, under an MIT licence.
Built on Open Wearables
Data coverage
Google Health data we support
Google aggregates data at the account level, so one connection reads whatever the user's apps and devices contribute, in the same schema as every other source.
Many sources, one link
Fitbit, Health Connect, Google Fit and other apps, reconciled by Google.
Sleep
Stages, duration, time in bed, efficiency and naps.
Heart
Heart rate, resting heart rate and HRV as both RMSSD and SDNN.
Vitals
SpO2, respiratory rate and VO2 max.
Activity
Steps, active and basal energy, distance and hydration.
Body
Weight, body fat, body temperature and blood glucose.
Workouts
Energy, distance, steps, average heart rate, speed, elevation and cadence.
What working with Open Wearables gives you
Two views of the same deployment. One for the people wiring it in, one for the people signing it off.
One schema, not one per provider
Google Health arrives in the same shape as every other source, so your code carries no Google-specific branches and adding a source later does not change the call.
- Sleep
- Heart
- Activity
- Workouts
Deduplicated across apps, by Google
When a watch and two apps all write steps, Google reconciles them into the figure the user sees in their own app. Or switch, once, to the raw per-source points when you need to know which device recorded a reading.
- Reconciled
- Raw per source
Webhooks and polling, both handled
Google sends a notification carrying only the changed window, and Open Wearables pulls that window over REST. Subscriptions live at the project level, registered by the deployment or by your own team with gcloud.
- Webhooks
- Polling
Tokens on rails
Access tokens refresh before they expire, with concurrent syncs coordinated so one user's refresh cannot race itself. A connection keeps working until the user revokes it.
- OAuth 2.0
- Refresh handled
Access you control
It runs in your cloud account, under your credentials. When we work on your system, we do it under a DPA you sign.
- Your credentials
- Your region
The Google relationship stays yours
Credentials and the Google Cloud project are in your name, data going straight from Google into your account.
- Your GCP project
- Your credentials
Costs you can see
Running it costs your own cloud bill, paid to your provider. Deployment and Integration are one-off services, and health scores and the other licensed modules come with Pro.
- Your cloud bill
- One-off services
No dependency on us
MIT licence, full source, public roadmap and public issues, plus community support on Discord.
- MIT license
- Full source
- Discord
How it works
From nothing to your first Google Health query
- 01
Bring it up
Clone the repository and run it with Docker Compose. First API call in five minutes, before any provider is connected.
Terminal
git clone https://github.com/the-momentum/open-wearables.git cd open-wearables && docker compose up -d - 02
Set up your Google Cloud project
Enable the Google Health API in your own Google Cloud project and create an OAuth client. Everything stays under your project, so the data relationship is between you and Google.
Google Cloud Console - 03
Connect a user
Your user authorises through Google's own consent screen, granting access per data category rather than all at once. Open Wearables handles the token lifecycle from there, including the refresh that keeps the connection alive months later.
- 04
Query the user, not the provider
Google Health data arrives in the same schema as every other source, in your own database, so your application code carries no Google-specific branches.
Google Health API setup guide
The honest comparison
Hosted SaaS API, in-house build, or self-hosted
Where each one actually wins. If a hosted API fits your situation, use one.
| Hosted SaaS API | Build in-house | Open Wearables, self-hosted | |
|---|---|---|---|
| [01] Google credentials and project | Theirs | Yours to set up | Yours, in your own project |
| [02] Overlapping sources | Whatever they pass through | Yours to resolve | Merged by Google, or raw if you prefer |
| [03] Webhook subscriptions | They host them | Service account work you build | Registered through your project |
| [04] Where Google Health data sits | Their cloud, their regions | Yours | Your cloud account, your region |
| [05] The data model | Theirs, you build against their schema | Yours | Yours, in your database |
| [06] Google API changes | They absorb them | Your team tracks and adapts | Fixed in a release you pull |
| [07] Cost shape | Scales with monthly active users | Salaries and infrastructure | Fixed, flattens as you grow |
What stays yours
The deployment, the data and what you build on it stay in your account, whoever runs it
Sovereignty
Google Health data goes straight to your cloud, with no aggregator in between.
Residency
It stays in the region you chose, provable by pointing at an account.
Control
What you build on top of Open Wearables is yours, and the schema and the data are in your account.
Your own reasons
No regulator forcing it. You want the data in your own account anyway.
Google Health is one integration in the same API
You query a user rather than a provider, so somebody whose data arrives through Google and somebody wearing a ring you connect directly both come back in one shape. Adding either later does not change your code.
Deploy Open Wearables in your own cloud
The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account with Google Health connected and validated on real accounts.
FAQ
Do you have more questions?
What is the Google Health API?
Google's cloud interface to the health data on a user's Google account. Rather than connecting to each app separately, you connect once to Google and read whatever that account holds, already merged across contributing sources.
Is this the same as Health Connect?
No, and the difference decides how much work the integration is. Health Connect is an on-device layer on Android, so reading it means shipping a mobile SDK inside your own app. The Google Health API is a cloud integration with OAuth and no mobile work at all. Both land in the same schema, but they are separate integrations with separate setup. The Health Connect integration covers the on-device path.
Does this give us Fitbit data?
Yes, and once the legacy Fitbit Web API turns off on 30 October 2026, this is how Fitbit data continues to arrive. Google aggregates Fitbit at the account level, so it comes through this connection alongside everything else the user contributes. One thing to plan for: Fitbit tokens cannot be carried over, so every user re-consents through Google. The Fitbit page has the detail, and Google publishes its own migration guide.
What does deduplication actually mean here?
If a user has a watch and two fitness apps all recording steps, you would normally receive three overlapping figures and have to decide which is right. Google resolves that before the data reaches you, matching what the user sees in their own Google Health app. You can also ask for the raw per-source datapoints instead, if you would rather do that reconciliation yourself.
Do we get one merged figure or every source separately?
Both are available, and merged is the default. Reconciled data matches what the user sees in their own Google Health app, which is usually what a product wants to display. Switching to the raw per-source points keeps device attribution, at the cost of resolving the overlap yourself. Daily totals for basal energy are derived on Google's side and arrive anchored to calendar days.
Does it support webhooks?
Yes. Google notifies your endpoint when data changes, carrying only the window that changed, and Open Wearables pulls that window over REST. Subscriptions are registered per project rather than per user, by the deployment or by your own team with gcloud.
What do we need on the Google side?
Your own Google Cloud project with the Health API enabled and an OAuth client. For the deployment to register webhook subscriptions itself, it also needs credentials for that project, such as a service account key. All of it stays in your name.
Which scopes does this need?
Google splits access by data category, so activity and fitness, health metrics, sleep, nutrition and settings each have their own read scope. You request the ones your product needs rather than one blanket permission, which is easier to justify on a consent screen. The setup guide in the docs has the exact strings.
How many workout types does it recognise?
The widest set of any source we connect, all mapped to the same taxonomy your other providers use. The coverage matrix in the docs carries the current figure.
Can we combine Google Health with other sources?
Yes. Google covers whatever the user routes through their Google account, and a ring or a watch you connect directly covers the rest. You query the user, not each provider.