Google Fit's APIs Shut Down at the End of 2026: What Actually Replaces Them

Google Fit’s APIs stop working at the end of 2026, and as of late August Google still has not published a date.

That is the first thing worth knowing, because it sets the planning posture: you have roughly four months, you cannot get a firm deadline to plan against, and new developer signups closed on 1 May 2024, so if you do not already have access you are not getting it.

The second thing worth knowing is that the common advice, just move to Health Connect, is wrong for a large share of the people who need to move. Google Fit was five APIs wearing one brand, and they are being replaced by four different things in three different places. If your integration is server-side, Health Connect cannot do what you are doing at all.

This is the map, per API, plus the two that have no successor.

What is actually known about the timeline

Compare that with the Fitbit Web API sunset, where Google gave a specific date of 30 September 2026 and ran both APIs side by side from May. Fit gets a quarter, not a day.

One API becomes four

Google Fit exposed five distinct APIs. Here is where each one goes.

Two consequences fall out of that table immediately.

A product that spans phone, watch and server now touches three separate platforms with three different authorization models: on-device runtime permissions for Health Connect, OAuth for the Google Health API, and the Wear OS app model for Health Services. Google Fit unified those. Nothing in the replacement set does.

Real-time sensor access drops a level of abstraction. The Sensor API gave you a health-shaped interface over the phone’s sensors. Its replacement is the raw Android sensor framework plus Fused Location Provider, which is a capability replacement rather than an ergonomic one. Anything you were getting for free in terms of smoothing, batching or activity inference is now yours to write.

The two that have no successor

The Goals API is the one to check for first, because it fails quietly. If your product sets a step or activity goal and reads progress against it from Fit, there is no endpoint to migrate that call to. You are reimplementing goal state, storing it yourself, and computing progress against whichever data source you land on.

Why there is no drop-in REST replacement

This is the part most migration guides gloss over, and Google is admirably direct about it. Their own migration FAQ states that no direct alternative exists for the Fit REST API.

What you get instead are two options that differ architecturally, not cosmetically:

The Fit REST API let a server read a user’s aggregated fitness data. Health Connect cannot do that, because the data is on the handset and the permission is granted to an installed app. If your architecture is a backend that reads fitness data for users who may not have your Android app open, Health Connect is not a migration target, it is a different product.

The Google Health API is the server-side path. Which raises the question of what it actually contains.

What the Google Health API covers, and what it does not

We covered this API in depth in the Fitbit Web API migration guide, because it is the Fitbit replacement too. The short version: 31 data types, four read methods (list, reconcile, rollUp, dailyRollUp), Google OAuth 2.0, and scopes classified as Restricted, meaning a privacy and security review stands between you and production.

The part that matters for a Fit migration specifically is coverage. Google’s documentation names its sources as all Fitbit devices, Google Pixel watches, and manual user entries, with available data types depending on device capability. Third-party hardware reaching that store through Health Connect is described as a pathway rather than a shipped capability.

Third-party analysis of the API surface, from Terra’s teardown, flags several rough edges worth confirming against your own usage: there are no common field paths with the old Fitbit Web API, so responses need rewriting rather than remapping; there is no endpoint to list a user’s available data types, so you query each one individually; six types lack the list method entirely; and write access for third-party clients is absent.

Health Connect’s real constraints

If you are mobile-only, Health Connect is the right target and it is a genuinely better platform than Fit. Three constraints decide whether your migration is a week or a quarter.

The 30-day default, and the permission that lifts it. By default, an app granted read access sees the preceding 30 days of other apps’ data, measured from the moment permission was granted. Reading older records errors. Most migration guides stop there and leave you believing 30 days is a hard ceiling. It is not: PERMISSION_READ_HEALTH_DATA_HISTORY unlocks records older than the window. Plan for the case where you request it and the user declines, because your cold-start experience is then genuinely capped at a month.

Background reads need their own permission. PERMISSION_READ_HEALTH_DATA_IN_BACKGROUND allows reads while your app is backgrounded. Without it, you only get data when the user has your app open, which quietly turns a passive-monitoring product into a manual one.

Your app has to be there. Health Connect data is read by an installed app holding a runtime permission the user can revoke at any time from system settings, with no notification to you. Revocation looks exactly like a user who stopped moving, which is the silent failure mode every health integration eventually meets: nothing throws, data just stops.

The migration checklist, in dependency order

1. Audit which Fit APIs you actually call. Recording, History, Sensor, Sessions, BLE, Goals. This determines how many destinations you are migrating to, and whether you have a Goals problem.
2. Check for Goals API usage first. It has no successor, so it is a build rather than a port and it has the longest tail.
3. Decide device-centric or account-centric. Mobile-only Android goes to Health Connect. Anything reading server-side goes to the Google Health API. Products doing both do both.
4. If you need the Google Health API, start the Restricted-scope review now. It gates production access and sits in a shared queue, and it is the longest lead time on this list.
5. Confirm data-source coverage against your actual user base before writing ingestion. Specifically, whether your users’ hardware is represented.
6. Declare the permissions you need on Health Connect, including history and background reads, and design the degraded path for each one being declined.
7. Rebuild your consent flow. There is no token migration here. Health Connect has no OAuth at all, and the Google Health API needs fresh Google OAuth 2.0 consent under reviewed scopes.
8. Dual-run before cutover. Discrepancies are cheap to investigate in September and impossible to investigate in January, when there is nothing left to compare against.
9. Monitor per-user data freshness through the cutover, not just error rates. The failures here do not throw.

If you are cross-platform, this only solves half of it

Everything above is Android. Health Connect has no iOS equivalent, and the Google Health API’s documented sources are Fitbit and Pixel hardware rather than Apple’s ecosystem. An iOS user’s data still arrives through HealthKit, with its own permission model, its own data types and its own quirks.

So a cross-platform product finishing this migration has two ingestion paths, two permission models and two type systems, and has just spent a quarter rewriting one of them because a platform vendor changed its mind.

That is the recurring shape of this category rather than a one-off. Google Fit is being deprecated. The Fitbit Web API sunsets in September 2026 with tokens that do not transfer. Apple removed iPhone-based sleep tracking in iOS 18 overnight. Underneath the headline deprecations runs a steady drip of new data types, schema revisions and scope changes every platform cycle.

There are two structural answers, and both are defensible. Keep each source integration a thin replaceable module behind your own schema, so the next sunset is a contained project rather than a rewrite. Or put the whole class of problem below an abstraction layer such as Sahha, where platform migrations happen beneath a normalized stream your product keeps reading unchanged. What does not work is treating each integration as a finished piece of work, because none of them are.

Either way, the order of operations is the actual takeaway. The scope review is the critical path, the Goals API is a build and not a port, no tokens carry over, and the deadline is a season rather than a date. Start with the audit this week, and the end of 2026 arrives as a non-event.