Fitbit Web API Shutdown: What Breaks in September and How to Migrate to the Google Health API

Sometime in September, 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 September 2026 Google turns it down [1], 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 September. 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 September 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 September, per user, per source.

The lesson that outlasts September

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 September arrives as a non-event. That’s the best outcome a deadline can have.