--- title: "Google Health API Integration | Self-Hosted" description: "Connect the Google Health API and keep the data in your own cloud account. Fitbit, Health Connect and Google Fit through one account-level layer, MIT licensed." canonical_url: "https://openwearables.io/integrations/google-health" --- # Google Health API data from every app, in your own cloud Google Health API integration 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. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - ROXFIT logo - Smarter Diagnostics logo - Suna logo - Yoboo logo 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 [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) 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](https://developers.google.com/health) 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](https://console.cloud.google.com/) 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](https://openwearables.io/docs/providers/google-api-integration) 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. [Browse all integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## 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. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) 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](https://openwearables.io/integrations/google-health-connect) 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](https://openwearables.io/integrations/fitbit) has the detail, and Google publishes its own [migration guide](https://developers.google.com/health/migration). ### 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](https://openwearables.io/docs/providers/google-api-integration) 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](https://openwearables.io/docs/providers/coverage) 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.