On November 2, 2026, the legacy Fitbit Web API stopped answering: requests to it and the Fitbit OAuth endpoints now return HTTP 410 Gone. The bigger deadline lands within weeks. Google's migration guide states that the Google Fit APIs, REST included, "will only be supported until the end of 2026," and it commits to no harder date than that. Apps still calling Fit are not facing a deprecation; they are facing a shutdown notice with no published switch-off time.
The constraint
Google Fit was one API doing two different jobs. In the cloud, it was a fitness store: write workouts and steps from any device, read them back later from a server, all behind OAuth. On the device, it was a sensor convenience layer: the Recording API counted steps in the background, the Sensor API smoothed raw accelerometer data, the BLE API bridged fitness hardware. The replacements do not reunify those jobs. Google split them across three products and left two features with no successor at all.
The options
An app still calling Fit has three honest paths, and "do nothing" is not one of them. The first is Health Connect: the on-device store, the right default for anything that reads or writes health data on the phone itself. The second is the Google Health API: the cloud path for teams whose servers, dashboards, or partner integrations genuinely need account-centric reads of Fitbit and Pixel Watch data. The third is narrower than people expect: if your only Fit usage is background step counting, the Recording API on mobile is an accountless, battery-optimized subscription that needs one permission and keeps a rolling ten-day buffer. An app using more than one of those jobs needs a combination, which is exactly the point of the migration: you are not swapping libraries, you are re-allocating which product owns which job.
The mechanism
The migration guide's own mapping, compressed:
Health Connect (aggregated) or the
Recording API on mobile (accountless,
10-day rolling buffer)
Google Health API (oauth, fitbit/pixel
watch lineage, not the old fit store)
or Fused Location Provider directly
inside your own application logic
APIs to talk to hardware
for background, ExerciseClient for
workouts, MeasureClient for bursts
The architectural flip: Fit stored data in your Google account on Google's servers; Health Connect stores data on-device, encrypted, tied to no account at all. That changes the auth model end to end: no OAuth scopes, no tokens, just manifest permissions granted per data type and per direction. android.permission.health.READ_STEPS reads steps and nothing else. By default an app can read only the 30 days preceding its first granted permission; older data needs a separate READ_HEALTH_DATA_HISTORY permission, and background reads need another. The convenience is real (over 50 data types in one store shared across apps), but any server-side pipeline that used to pull from Fit's cloud now has no endpoint to pull from: Health Connect has none.
Where it bites
Three bites stand out. First, the Goals API: the migration guide says flatly "No replacement API available," and Heart Points and Move Minutes map to nothing in Health Connect either. If your UX leaned on Google-computed goals or Google's own activity currency, that logic and motivation model is now yours to rebuild. Second, the Google Health API is not the old REST API reborn: it serves Fitbit and Pixel Watch device data through new googlehealth.* scopes, requires OAuth app verification and an annual third-party CASA security assessment for restricted scopes (unverified apps cap at 100 users), and every existing user must re-consent because Fitbit tokens do not transfer. Third, Play Console: every published app must file a "Health apps" declaration even if it touches zero health features, and a Health Connect app must declare each data type it uses or the system denies access to that type.
The numbers
A few figures orient the work. Fit froze sign-ups on May 1, 2024, originally promised support "until June 30, 2025," and was quietly extended to "end of 2026" with no announcement Google ever dated. The Google Health API consolidated over 100 legacy Fitbit endpoints into one service that opened May 18, 2026, then absorbed the Fitbit user base when the consumer app rebranded to Google Health a day later. Health Connect sits on over 500 integrated apps as of Google's May 2024 count and is a system component from Android 14 up, a Play-distributed app below. The Fit consumer app still lives, and Google still promises a data migration path into Google Health for it.
Our position
Treat "end of 2026" as December 1, not December 31. Google's own pages disagree with each other (one stale landing page still says June 30, 2025), and a support-commitment deadline is not a promise the service survives that long. For anything new, Health Connect is the right default on Android: on-device storage is where platform privacy is heading, it costs you a manifest and a declaration rather than OAuth plumbing, and it removes the "where did the user's steps go" question entirely. The trap is assuming migration means a library swap. It is an architecture migration: cloud store to device store, OAuth to manifest permissions, and goal logic from Google-owned to yours. Scope it as one.
The takeaway
no harder date; fitbit web api already 410
gone since nov 2
first grant; history and background reads
each need a second permission
verification plus an annual casa audit;
fitbit tokens do not transfer, users
re-consent
declaration; each used data type must be
declared and justified
before writes; new builds start on health
connect
Health-data plumbing sits in the same class of platform constraints we plan around in our product engineering work, like the background-execution limits in iOS will not run your sync in the background. If your app still calls Fit, send us the package name and we will tell you which migration row you are in.
// sources
// next step
We work this way on client projects too.
Tell us what you are making. We reply with a plan, a timeline, and a price.
