Google Health API and Google Health Connect: What's the Difference

Open Wearables Team · August 12, 2026 · 6 min read

Key Takeaways

Google Health Connect and the Google Health API are two separate products that share overlapping data but work through fundamentally different architectures.
Health Connect is an on-device Android data store. It requires a mobile SDK, uses native Android permission screens instead of OAuth, and never touches Google's cloud scopes, so it sidesteps OAuth verification and CASA entirely.
The Google Health API is a server-side OAuth 2.0 flow that pulls data over REST from the cloud, no mobile app required, but its scopes are largely restricted, which brings OAuth verification and CASA into play at scale.
Open Wearables represents both under a single "google" provider identity, since they are two delivery mechanisms for overlapping data, but choosing between them is an architectural decision, not a config flag.
Many products end up using both: Health Connect for users with the mobile app installed, the Google Health API as a fallback or primary path for everyone else.

Google currently runs two separate products with overlapping names and overlapping data, and the naming collision causes more confusion than almost anything else in this space. If you've been told your app needs "Google Health" and you're trying to figure out which one, this is the actual distinction.

The One-Sentence Version

Google Health Connect lives on the user's Android device and requires a mobile SDK. Google Health API is a cloud REST API and requires no SDK. They expose overlapping data but through fundamentally different architectures, and picking the wrong one shapes your entire integration.

Google Health Connect: On-Device, SDK Required

Health Connect is Google's on-device data store for Android. Wear OS, Samsung Health, Fitbit's Android app, and dozens of third-party apps all write into it, making it a genuine aggregation hub sitting on the phone itself.

To read from it, you need a native Android SDK component in your app. There is no cloud API for Health Connect; the data lives on-device, and your integration has to run where the data is. That means:

Your app needs to be installed on the user's phone
Data availability depends on what is actually populated in Health Connect on that specific device
Permissions are handled through Android's native consent screens, not an OAuth flow
There is no server-side polling; sync happens through the SDK, on-device

The upside is that this path does not touch Google's restricted OAuth scopes at all, so it sidesteps the verification and CASA process entirely. The trade-off is that it only works if you already have, or are willing to build, a mobile app under your brand.

Google Health API: Cloud REST, No SDK, Broader Aggregation

Google Health API is a newer, separate product: a server-side OAuth 2.0 flow that lets you connect a user's Google account and pull their data over REST from your backend, no mobile app or SDK required.

It is also an aggregation layer, but at the account level rather than the device level. It surfaces data from every source connected to a user's Google Health account, including their phone's Health Connect store, their Fitbit account, Google Fit, and other connected apps, not just one device.

Because it's a cloud API, it supports:

Polling on a schedule via standard REST calls
Notify-only webhooks, so you get pinged when data changes and fetch it in response
Reconcile and list fetch modes, letting you choose between one deduplicated total per metric or raw per-source data tagged by device

The cost of this convenience is that most of its scopes are Google-restricted, which means OAuth app verification and, at meaningful scale, an annual CASA security assessment. Health Connect does not carry that requirement because it never touches those cloud scopes.

Same "Google" Identity, Two Different Mechanisms

If you're using a platform like Open Wearables, both paths are typically represented under a single "google" provider identity, since from a data-modeling perspective they're two delivery mechanisms for overlapping health data. That doesn't mean they're interchangeable at the integration level. Choosing between them is an architectural decision, not a config flag:

Where it runs: Health Connect runs on-device via the Android SDK. Google Health API runs in the cloud via server-side OAuth.
Requires a mobile app: Health Connect, yes. Google Health API, no.
OAuth verification / CASA: Not applicable for Health Connect. Required at scale for the Google Health API.
Sync model: Health Connect syncs through the on-device SDK. Google Health API uses polling plus webhooks.
Aggregation scope: Health Connect covers whatever is on that specific device. Google Health API covers whatever is connected to that Google account.

Which One Should You Build Against

If you already have a mobile app and want to avoid Google's cloud verification process, Health Connect is the lighter-weight and lower-compliance-overhead path, at the cost of needing your app installed and populated on the user's device before you get anything.

If you're building a backend-first product, don't have (and don't want to build) a mobile app, or need webhook-driven updates rather than SDK-based sync, the Google Health API is the only path that fits, and the OAuth verification and CASA requirements are the cost of that convenience, not a sign you're doing something wrong.

Many products end up wanting both: Health Connect for users who have the mobile app installed, Google Health API as a fallback or primary path for users who don't. That is exactly the kind of decision a unified provider layer is meant to absorb, so you're not maintaining two entirely separate Google integrations by hand.

The Google Health API integration covers the OAuth flow, reconcile/list modes, and webhook setup in detail. The Google Health Connect integration covers the on-device SDK path. If you're weighing the CASA and verification cost of the API path specifically, this breakdown of what that process actually involves is worth reading before you commit to either route.

See related articles

Google Health API: A Practical Guide to Getting Started

Google CASA and OAuth Verification for Health Apps

Fitbit Web API Shutdown 2026: Migration Guide

Fitbit Alternatives for Developers

FAQ

Is Google Health Connect the same as the Google Health API?

No. They are related but distinct products that share overlapping data. Health Connect is an on-device Android data store requiring 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.

Do I need a mobile app to use the Google Health API?

No. The Google Health API is a cloud REST API with a server-side OAuth 2.0 flow, so you can pull data directly to your backend without shipping a mobile app. Google Health Connect requires a mobile app, since it only reads data on-device.

Does Google Health Connect require OAuth verification or CASA?

No. Health Connect uses native Android permission screens instead of an OAuth flow, so it never touches Google's restricted cloud scopes and sidesteps the verification and CASA process entirely. The Google Health API does require both at meaningful scale.

Can I use both Google Health Connect and the Google Health API together?

Yes, and many products do. Health Connect can serve users who have your mobile app installed, while the Google Health API covers everyone else or acts as the primary path for a backend-first product. A unified provider layer can absorb this so you're not building two separate Google integrations.

Why do both show up as the same provider in some platforms?

Because from a data-modeling perspective they are two delivery mechanisms for the same underlying health data. Platforms like Open Wearables represent both under a single "google" provider identity, even though the integration mechanics, sync model, and compliance requirements differ significantly between them.

Back to all posts