Google Fit API Is Deprecated — What to Use Instead

You hit a deprecation notice on the Google Fit API — and it is real: all Google Fit APIs, including the REST API, are supported only until the end of 2026, and no new developers can even sign up (that door closed May 1, 2024). There is no drop-in replacement, so the fix is not a config change — it is a migration, and which target you move to depends entirely on how you were using Fit. The short version: on-device reads go to Health Connect, cloud/account and OAuth reads go to the new Google Health API, and Wear OS goes to Health Services.

The deprecation, stated plainly

Three facts you need to plan around:

• No new signups since May 1, 2024. If you have an existing Fit project it keeps working for now, but you cannot onboard a new project to Fit at all. New apps must start on a successor.
• End of support is the end of 2026. Every Fit API surface — the Android SDK, the REST API, and the BLE APIs — sunsets by the end of 2026. Treat that as a hard deadline, not a soft one.
• There is no 1:1 REST replacement. Google's own guidance is blunt: there is no alternative that maps one-to-one onto the Fit REST API. You will re-architect, not swap a base URL.

Because the deadline is fixed and there is no shortcut, the urgent move is to identify your usage pattern and start the correct migration now.

Most likely "which path is mine?" — ranked by how apps actually use Fit

Figure out your bucket first; the rest of the guide follows from it.

1. On-device reads on Android — you read steps, calories, or aggregated activity from the phone using the Fit Recording API or the on-device Android SDK. This is the most common case for mobile apps. Move to Health Connect (plus the Recording API for steps).
2. Cloud / account reads over OAuth — you call the Fit REST API server-to-server, or use the History API / Sessions API to pull a user's cross-device history through their Google account. Move to the Google Health API.
3. Fitbit Web API integrations — separate product, same destination: the Fitbit cloud surface is folding into the Google Health API.
4. Wear OS — you read sensors or activity on the watch itself. Move to Health Services on Wear OS, not Health Connect.

If you were using Google Fit for X, move to Y

A hedge worth stating clearly: the Google Health API is still rolling out as of 2026 — its availability, scopes, and the exact Fitbit consolidation timeline are not final. Confirm the current status in Google's Health API and Fit migration docs before you commit an architecture to it.

How to migrate

Step 1 — Classify your usage as on-device or cloud/account

Before touching code, sort every Fit call you make into one of two buckets: on-device (steps and aggregates read from the phone, no server, no Google account round-trip) or cloud/account (server-to-server REST, OAuth, or cross-device history via the History/Sessions APIs). Wear OS code is a third, separate bucket. This single distinction determines your entire migration target, so do it first and do it per-feature — a single app can have features in more than one bucket.

Step 2 — Move on-device reads to Health Connect

If your usage is on-device, migrate to Health Connect: the device-centric successor that stores health data on-device under user control and gives you a single integration across the Android health ecosystem. Replace Fit's OAuth-and-scopes model with Health Connect's per-record-type on-device permissions, and complete the Play Console health-data declaration for the data types you read — it is a publishing gate. For plain step counts, the more battery-efficient Recording API on mobile returns steps without a Google account or API scopes. Walk the full setup in the Health Connect integration guide, and if reads come back empty after you switch, see Health Connect returns no data.

Step 3 — Move cloud/account and Fitbit Web API reads to the Google Health API

If your usage is server-side, OAuth-based, or pulls cross-device history, the destination is the Google Health API — the account-centric successor to Fit's cloud APIs, and also the stated home for Fitbit Web API integrations. Do not expect the Fit REST endpoints to map across; there is no 1:1 replacement, so budget for a genuine re-architecture of your server integration. Because this API is still rolling out, treat scopes, endpoints, and availability as subject to change — verify against the current Google Health API docs before you build.

Step 4 — Move Wear OS code to Health Services

If you read sensors or activity on the watch, migrate that code to Health Services on Wear OS — not Health Connect. Health Services is the on-watch successor for the sensor and activity APIs Fit provided on Wear OS; keep it separate from your phone-side Health Connect work.

Step 5 — Finish before the end of 2026

The end-of-2026 sunset is firm and new projects cannot onboard to Fit at all, so schedule the cutover with margin rather than aiming for the deadline. Do the Health Connect Play Console declaration early (review takes time), keep any Fit and successor paths running in parallel during the transition so users are not cut off, and only remove Fit code once the replacement is verified in production.

Still stuck? Quick migration checklist

Run these in order:

1. List every Fit API you call and label each on-device, cloud/account, or Wear OS.
2. On-device ⇒ Health Connect (plus Recording API for steps).
3. Cloud/account or Fitbit Web API ⇒ Google Health API (verify current availability and scopes).
4. Wear OS ⇒ Health Services.
5. Submit the Play Console health-data declaration for your Health Connect data types.
6. Confirm the successor works end-to-end in production, then decommission Fit before the end of 2026.

Deciding between the Android and iOS sides of this while you re-architect? See Apple HealthKit vs Google Health Connect. And because the Google Health API is still rolling out, re-check Google's Fit migration guide before locking in any cloud design — the details are the volatile part of this plan.