API
Fitbit (Google)
Support for the legacy Fitbit Web API ended on 30 September 2026, and on 30 October 2026 the API is turned off entirely — it will no longer function or sync data to or from Fitbit users; Google directs developers to the Google Health API
departs 30 Oct 2026
Quick answers
- Is it true that Fitbit's legacy Web API is turned off on 30 October 2026 — migrate to the Google Health API?
- Yes. Fitbit (Google) has officially announced it, effective 30 Oct 2026. If your app reads or writes Fitbit user data through the **legacy Fitbit Web API** (the `api.fitbit.com/1/...` endpoints — steps, heart rate, sleep, activity, weight, and the OAuth 2.0 flow around them), it has a hard end date.
- When does it take effect?
- 30 Oct 2026. Verified against the vendor's own announcement.
- What should I use instead?
- Google's stated path is the **Google Health API**, which replaces the legacy Fitbit Web API.
What this means for you
If your app reads or writes Fitbit user data through the **legacy Fitbit Web API** (the `api.fitbit.com/1/...` endpoints — steps, heart rate, sleep, activity, weight, and the OAuth 2.0 flow around them), it has a hard end date. Per Fitbit's own developer reference, **support ended on 30 September 2026** — the API kept operating but Google stopped fixing bugs and providing API support — and **on 30 October 2026 the Web API is turned off entirely** and "will no longer function or sync data to or from Fitbit users." That second date is the real cliff: any integration still calling the legacy endpoints stops returning data, and anything writing data stops syncing, for every one of your users at once. This hits a large base — consumer fitness apps, research studies pulling wearable data, corporate wellness platforms, and dashboards built on Fitbit metrics all commonly sit on the legacy Web API. There is no quiet degradation after 30 October; the endpoints go dark.
Where to go
Google's stated path is the **Google Health API**, which replaces the legacy Fitbit Web API. This is not a hostname swap: the Google Health API uses **Google OAuth 2.0** (your project must be registered in the Google Cloud Console), and existing users must go through **mandatory re-consent** under the new scopes before their data flows again — so the migration includes a user-facing re-authorization campaign, not just a code change. Work backwards from 30 October 2026: register the Cloud project and configure OAuth, re-point your data reads/writes to the Google Health API, and drive existing users through re-consent well before the cutoff, because any user who has not re-consented loses data access when the legacy API is turned off. Review Google's migration guide for the endpoint and scope mapping; not every legacy data type maps one-to-one, so confirm the specific metrics your app depends on are covered.
- Google Health API — Google's named replacement for the Fitbit Web API (Google OAuth 2.0, Cloud Console project, mandatory user re-consent)
Fitbit’s developer documentation now carries a firm, two-date shutdown for the legacy Fitbit Web API:
- 30 September 2026 — support ended. The API kept operating, but Google stopped fixing bugs and providing API support.
- 30 October 2026 — the Web API is turned off and “will no longer function or sync data to or from Fitbit users.”
The second date is the one that matters. This is a full shutoff, not a slow deprecation.
Where this hurts
The legacy Web API — the api.fitbit.com/1/... endpoints for steps, heart rate, sleep, activity, weight and the OAuth flow around them — sits under a lot of software: consumer fitness and coaching apps, academic and clinical research studies that pull wearable data, corporate wellness platforms, and internal dashboards. All of them stop receiving (and syncing) data on 30 October 2026, simultaneously, for every user. There is no read-only grace period after the cutoff; the endpoints go dark.
What to do
Google’s replacement is the Google Health API, and the migration is more than a hostname change:
- It uses Google OAuth 2.0, so your project must be registered in the Google Cloud Console with the right OAuth configuration.
- Existing users must complete mandatory re-consent under the new scopes before their data flows again. A user who has not re-consented by the cutoff loses access when the legacy API is turned off.
Work backwards from 30 October: register the Cloud project, re-point reads and writes to the Google Health API, and run a user-facing re-authorization campaign early. Check Google’s migration guide for the endpoint and scope mapping — not every legacy data type maps one-to-one, so confirm the specific metrics your app relies on are covered before you cut over.
Entry changelog
- — last reviewed.
- — Entry created from Fitbit's official developer Web API reference (dev.fitbit.com/build/reference/web-api/), which states support for the legacy Fitbit Web API ended 30 September 2026 and the API is turned off on 30 October 2026, after which it will no longer function or sync data; Google directs developers to the Google Health API. Clears backlog B-082 — the first-party page is now server-rendered and carries firm calendar dates (previously only month-precision secondary sources were available). Detect fingerprint text:api.fitbit.com/1 matches the legacy versioned Web API host/path.
Put this countdown in your README
Building on Fitbit (Google)? Drop this badge into a project’s README or docs — it shows the days left and
refreshes on its own every night from this page. 
[](https://lastcall.dev/entries/fitbit-legacy-web-api-shutdown)Spot an error or a changed date? Tell us and it’s corrected the same night.