Google Fit is deprecated: migrating to Health Connect

Published 20 August 2026 · For teams with a live Google Fit integration.

If your Android health product reads step counts or workouts from the Google Fit APIs, you are on a deprecation clock. Google has moved Android health data to Health Connect, and Fit is being retired. The migration is not difficult, but it is not a find-and-replace either, because the two are architecturally different in a way that changes your backend, not just your app.

The change that actually matters

Google Fit had a REST API. Your server could hold an OAuth token for a user and pull their step count without the phone being involved at all. That is the part that is going away, and no equivalent replaces it.

Health Connect is an on-device data store. Data can only be read by an app running on the user’s phone, with permissions granted on that phone. There is no endpoint you can call from a server. Your architecture moves from server pulls when it wants to device pushes when it can.

The four things that bite people

Historical data does not come with you. Health Connect holds a limited on-device window. If you need years of history you must export it from Fit before the API is gone. This is the only genuinely time-boxed item on the list — everything else you can do later, but data you did not export is simply lost.

Denied permissions look like empty data. Health Connect does not distinguish between “the user said no to heart rate” and “there is no heart rate data”. Both return nothing. If you show the user an empty chart without checking grant state, your support queue fills with people who think the app is broken.

Health Connect is not always present. Availability depends on Android version and whether the user has it set up. Your app needs a real path for devices where it is missing, not a crash.

Duplicates arrive from every direction. Health Connect aggregates other apps, so a single run can reach you from Health Connect and again from Strava or Fitbit directly. Without a deduplication rule your users’ weekly totals are wrong in a way they will notice.

A migration order that works

1. 1

   Export historical Fit data first

   This is the only irreversible step. Do it before anything else, even if the rest of the migration is months away.

2. 2

   Add Health Connect reads alongside Fit

   Run both, write to the same backend records, and compare. You want to see where the two disagree while you still have both.

3. 3

   Build the permission-state UI

   Check grant state explicitly and tell the user which types are denied. Do not infer it from empty results.

4. 4

   Add a deduplication rule

   Decide which source wins when the same workout arrives twice, and apply it consistently rather than per-feature.

5. 5

   Cut over and remove the Fit path

   Once the comparison in step 2 is quiet, drop Fit.

Where an aggregator helps, and where it does not

An aggregator cannot give you a cloud API for Health Connect, because none exists. Anyone who implies otherwise is describing something impossible. What it can do is take the on-device records your app reads and normalise them into the same schema as your cloud providers, so a step count from Health Connect and one from Fitbit are the same object in your backend.

WearLink’s Kotlin SDK does that read-and-push, and the resulting records land beside Fitbit, Oura and Strava data with provider-priority deduplication applied. If you do not have an Android app at all, skip Health Connect entirely and use the cloud providers, which are readable server-side over OAuth.

Frequently asked

Is the Google Fit API being shut down?

The Google Fit APIs are deprecated in favour of Health Connect. Google has directed developers to migrate, and new integrations should target Health Connect rather than Fit. Check Google's current developer guidance for the exact dates that apply to the specific Fit APIs you use.

What replaces Google Fit for Android health data?

Health Connect, an on-device data store that other apps read from and write to with the user's permission. Unlike Google Fit's REST API, Health Connect has no cloud endpoint — the data can only be read by an app running on the device.

Can I read Health Connect data from my server?

Not directly. There is no server-side API. Your Android app reads the records on-device and sends them to your backend. This is the single biggest architectural difference from Google Fit, which offered a REST API you could call from a server.

What if I do not have an Android app?

Then Health Connect is not available to you, and neither is Apple Health. Your options are cloud-API providers — Fitbit, Oura, WHOOP, Garmin, Strava, Withings — which authenticate per user over OAuth and can be read entirely server-side.

How long does migrating off Google Fit take?

The Android-side read is usually a few days. The cost is in the architecture change: moving from a server-pull model to a device-push model means handling intermittent connectivity, deduplication, backfill on first connect, and a permission model where a denied data type looks identical to one with no data.