What changed
Google's current Health API documentation says support for the legacy Fitbit Web API ended on September 30, 2026. The API continues operating temporarily, but on October 30 it will be turned off and will no longer function or sync data to or from Fitbit users. Developers must migrate integrations to the Google Health API. The replacement also moves authorization from legacy Fitbit authorization to Google OAuth 2.0. Google says it is not currently onboarding new projects to the Health API, although it is working to expand access.
Why it matters
This is a hard compatibility deadline rather than a documentation deprecation. Apps, dashboards, automations and research systems that still read or write Fitbit data through the legacy Web API can stop working after October 30. Migration also changes the identity/authentication boundary, so teams need to test consent, token handling, scopes, data-type mapping and user relinking rather than merely swapping an endpoint hostname. The restricted onboarding state creates an additional risk for developers trying to launch a new Fitbit-connected product during the transition.
The old API stops working on October 30
Google says the legacy Fitbit Web API entered unsupported operation after September 30 and will be turned off October 30. After that date it will no longer function or sync Fitbit user data.
Authentication moves to Google OAuth 2.0
The Google Health API replaces legacy Fitbit authorization with Google OAuth 2.0. Existing integrations therefore need to account for a new authorization flow and permission-management surface as part of the migration.
The replacement API is not fully open to new projects
Google's documentation currently says it is not onboarding new projects to the Google Health API and is working to expand access. Existing developers should verify project eligibility rather than assuming a new integration can be provisioned immediately.
Treat this as a data-pipeline migration
Builders should inventory every Fitbit endpoint and data type they use, map those dependencies to the Health API, test OAuth consent and refresh behaviour, validate historical and ongoing sync semantics, and plan for users who do not complete any required relinking before the cutoff.