Fitbit Web API Shutdown: How to Migrate by 30 October, and What to Do If Google Won't Onboard You

Update, 13 October 2026: Google’s Google Health API release notes now say it is “not onboarding new projects at this time” while it works to open access to more developers [8]. If your team has not already been onboarded, you may not be able to start a migration before 30 October. Contact Google through the migration guide now, and use the phone routes in if you can’t get into the Google Health API below to keep Fitbit data flowing. For teams already in, Google added a v4beta preview channel on 1 October, ahead of a stable v4, with a new skin temperature data type, and added women’s health data types and write-only scopes in August [8].

Update, 1 October 2026: Google moved the shutdown from 30 September to 30 October 2026, telling developers by email that the extra month is for teams still waiting on the Cloud Application Security Assessment. Developer support for the legacy API ended on 30 September as planned [6][7]. Everything below still applies; the wall moved a month.

On 30 October, one of the most-integrated consumer health APIs of the past decade goes dark. And it will go dark quietly: no exceptions, no failed deploys, just data that stops arriving.

The Fitbit Web API has been the workhorse of wearable integrations since the early 2010s. In October 2026 Google turns it down [1][6], completing the consolidation it started when it rebuilt its health stack: cloud access to Fitbit data moves to the new Google Health API, on-device Android access to Health Connect. The migration is real work with a hard deadline, and one property makes it a product problem as much as an engineering one: existing OAuth tokens don’t transfer, so every user who ever connected Fitbit to your product has to consent again before the cutoff.

This is the migration reference we wanted to exist: what the new API actually is, what you gain and what it costs, and the plan, in order.

What’s changing: Fitbit Web API out, Google Health API and Health Connect in

Two clarifications up front. Nothing changes for Fitbit owners: devices sync, the app works, and this lands entirely on third-party integrations. And the path split is the one real architectural decision: if you need Fitbit data server-side, independent of your app being open, migrate to the Google Health API; if your Android app reads on-device anyway, Health Connect may already cover you, and it aggregates sources beyond Fitbit.

What the Google Health API actually is

A rebuilt REST surface: the 120-plus endpoints of the legacy API collapse into 31 data types, all read through the same four methods, under one resource shape.

The old API grew organically for a decade: an endpoint per metric, inconsistent formats, units and timezone behavior that varied by endpoint, and error handling you learned per corner case. The new API is the do-over. Every data type (steps, exercise, sleep sessions with stages, heart rate, SpO2, body fat, weight, active zone minutes, and so on, across activity and health-metric categories [2]) is exposed through the same four reads:

Three practical notes from the new model:

• reconcile is the sync primitive the old API never had. Instead of re-querying windows and diffing, you ask for what changed. Late-arriving and revised data (the perennial headache of wearable sync) has a first-class answer.
• Auth becomes standard Google OAuth 2.0, with scopes shaped like googlehealth.activity_and_fitness.readonly, split read/write per category [2]. You get standard Google auth libraries and users get familiar consent screens, at the price that nothing about your old auth carries forward.
• Webhooks auto-subscribe if you ask. Set subscriptionCreatePolicy to AUTOMATIC in your subscriber config and new users are subscribed per data type without per-user setup [4], a meaningful simplification if you run event-driven ingestion.

What you gain, and what it costs you

On balance the new API is the better one; the price is concentrated in three one-time costs, and two of them have lead times you don’t control.

The gains are real. Default intraday access is the headline: the old API gated anything below daily resolution behind a special application with a justification, which many consumer apps never got approved for. Under the new model, granular series like ~5-second heart rate come through the standard list method [2]. Add uniform units, timezones, and error semantics across all 31 types, and the day-to-day developer experience is a clear upgrade over the legacy surface.

The costs:

1. A mandatory security review. Every Google Health API scope is classified as Restricted, which triggers a privacy and security review of your application before you can go to production [2]. That review has a queue, the queue is filling with everyone else on the same deadline, and it gates everything downstream. This, not code, is your critical path: apply first.
2. A request-pattern rework, not a find-and-replace. Bundled data types and the four-method model mean the shape of your requests and responses changes, not just the URLs. Google publishes a migration guide and a parity tool for checking your legacy usage against new-API equivalents [5]; run it against your actual scope usage early, and use the exercise to drop the “we pull it but never use it” data types your consent screen no longer needs to ask for.
3. Full user re-consent. The auth change means your entire connected-Fitbit base must authorize again. This is the hard half, and it gets its own section.

The hard half: getting every user to say yes again

Migrating the code makes the new pipe work; only your users can fill it, and some of them won’t.

Treat re-consent as a funnel with real drop-off. Users who connected once, years ago, must notice a prompt, care, and complete a new OAuth flow before 30 October. The playbook:

• Start before the new flow ships. An in-product heads-up beats a surprise demand in the final week.
• Lead with what they keep, not what changed. “Reconnect to keep your sleep insights” outperforms anything containing the word “API.” Users care about their streaks and scores, not Google’s platform consolidation.
• Prompt where the value is felt: on the chart their Fitbit data powers, not in an email.
• Sequence by activity. Active users first (highest completion, most to lose), then dormant users, for whom this is honestly both a churn point and a reactivation excuse.
• Track completion, not sends: share of Fitbit-connected users re-authorized, weekly, against the 30 October wall. And instrument per-source data freshness through the cutover, so “this cohort went quiet” is a dashboard alert in hours rather than a support-ticket pattern in weeks.

The migration checklist, in dependency order

1. Apply for the Restricted-scope review now. Longest lead time, gates production access, shared queue [2].
2. Run the parity tool against your current Fitbit API usage to map endpoints to data types and surface gaps [5]. Trim scopes you don’t actually use.
3. Pick your path: Google Health API for cloud, Health Connect for on-device Android, or both [2][3].
4. Rework ingestion around the four-method model: reconcile for incremental sync, list where you want the new intraday granularity, roll-ups for summaries. Enable webhook auto-subscription if you’re event-driven [4].
5. Dual-run before cutover. Old and new pipelines in parallel for overlapping users; discrepancies are cheap to investigate in July and expensive to guess at in October, when there’s nothing left to compare against.
6. Launch the re-consent campaign and track weekly completion.
7. Hold freshness monitoring through the October cutover, per user, per source.

If you can’t get into the Google Health API

Google’s notice has no date for reopening [8]. If you were not onboarded, the cloud route may stay shut past 30 October. The phone is now the better route to Fitbit data than it has been at any point in the past decade.

On Android: Health Connect. The Google Health app, which replaced the Fitbit app in May 2026, can share data with Health Connect for any app the user approves. Google’s help center lists about 25 types it writes, including sleep stages, heart rate variability, resting heart rate, respiratory rate, skin temperature, VO2 max and cycle data. Oxygen saturation is the notable gap: Google Health reads it but does not write it [9].

On iPhone: Apple Health, new since August. For more than a decade Fitbit did not write to Apple Health. Google Health 5.05, rolled out from early August 2026, changed that: users can send exercise, sleep, steps, vitals and other wellness data from Fitbit and Pixel Watch into Apple Health, on iOS 16.4 or later [10][11]. Google lists categories rather than every type, and not every metric transfers [10].

The phone routes have real costs. Data arrives when the phone syncs, not on a webhook, and the user has to switch on sharing inside Google Health before your app sees anything; we covered those clocks in why wearable data arrives late. But they remove the two things that make the cloud route fragile right now: Google’s onboarding queue and the security review. For any product that already ships an iOS or Android app, they are now the more dependable way to keep Fitbit data flowing.

Before 30 October, if you are not onboarded:

1. Confirm where you stand with Google through the migration guide, and assume no cloud access until you hear otherwise [5][8].
2. Ship or extend your on-device reader with the Health Connect and HealthKit types you need. See HealthKit vs Health Connect for the differences.
3. Tell users exactly what to switch on: Health Connect sharing on Android or Apple Health sharing on iPhone, inside Google Health, then your app’s permission. An in-app guide with the menu path recovers most of them.
4. Expect a gap from users who do not update or do not switch sharing on, and measure it per user.
5. Keep the source with every value. Fitbit data arriving through a phone store sits next to steps and sleep from the phone and other wearables; see deduplicating health data across wearables.

Sahha’s SDK reads Health Connect and Apple Health, so apps built on it receive whatever Google Health writes to either store without a Google Health API project, as long as users have sharing switched on.

The lesson that outlasts the cutover

This keeps happening. Google Fit’s APIs: deprecated. iPhone sleep tracking: removed in iOS 18, overnight. Now the legacy API a decade of products was built on. Every health data source is a dependency another company can rewrite on its own schedule, and the structural responses are the same two as always: keep each source integration a replaceable module behind your own schema, so the next sunset is a contained project, or put the whole class of problem below an abstraction layer like Sahha, where the migration happens beneath the normalized stream your product actually reads.

Either way, the order of operations is the real takeaway: the review queue is the critical path, the tokens don’t transfer, and both of those clocks are already running. File the scope application this week and start the re-consent campaign early, and 30 October arrives as a non-event. That’s the best outcome a deadline can have.