Fitbit integrationFitbit data now comes through the Google Health API
Google ended support for the legacy Fitbit Web API on 30 September 2026 and turns it off on 30 October.
Fitbit data has not gone away: Google aggregates it at the account level, and the Google Health API reads that layer, in the same schema and the same deployment you already run.
Where things stand
What this means in practice
The Web API turns off
Support ended on 30 September 2026, and on 30 October the API stops syncing data to or from Fitbit users.
Existing connections sync until then
Workouts keep flowing for accounts already connected, up to the turn-off date Google has set.
No new Fitbit builds
Every integration has to move to the Google Health API, so starting on the Fitbit Web API now is work that expires within weeks.
The integration is frozen
Sleep, intraday heart rate and daily summaries exist in the Web API, and we will not be adding them.
Your data stays where it is
Everything already synced sits in your own deployment and schema, and the turn-off does not touch it.
Until the turn-off
What Fitbit still returns
For connections that already exist, workouts continue in the same schema as every other source.
Workouts
Calories, steps, distance and minimum, average and maximum heart rate.
Activity types
Mapped to one sport taxonomy, with a fallback for anything unrecognised.
Device name
Which Fitbit recorded the session.
The path forward
The Google Health API
Google now aggregates Fitbit data at the account level, and the Google Health API reads that layer, so Fitbit data keeps arriving after the Web API is gone.
Not to be confused with Health Connect
Health Connect is an on-device Android layer that needs a mobile SDK in your app. The Google Health API is a cloud integration with OAuth, and it is the one that carries Fitbit data.
What changes
Users connect to Google rather than to Fitbit, and Fitbit tokens cannot be carried over, so every user re-consents once through Google.
What you gain
Sleep with stages, continuous heart rate, heart rate variability, blood oxygen, respiratory rate and VO2 max, none of which the Fitbit path gives you today.
What stays the same
Same schema, same deployment, same cloud account, so your application code does not change.
Keep Fitbit data flowing
The Google Health API carries Fitbit data in the same schema and deployment you already run. Your code stays as it is.
FAQ
Do you have more questions?
When exactly does the Fitbit Web API shut down?
Support ended on 30 September 2026, and on 30 October 2026 the API is turned off and stops syncing data to or from Fitbit users. Google's announcement has the full timeline.
Our integration is live today. Will it break before then?
Existing connections keep syncing workouts until the turn-off on 30 October. Google no longer supports the API, though, so plan the move now rather than at the deadline.
Can we still set up a new Fitbit integration?
Not one worth building. Every integration has to move to the Google Health API, and the Web API turns off within weeks, so a new build would stop working almost as soon as it shipped.
Why are you not adding sleep and heart rate for Fitbit?
Both exist in the Fitbit Web API, and both stop working when it turns off. Building them would mean shipping features with a known expiry date, so that effort goes into the Google Health API path instead.
What happens to the Fitbit data we have already synced?
It stays in your own deployment, in your own schema, under your own credentials. The turn-off affects what arrives next, not what you already hold.
Is the Google Health API a replacement or a workaround?
A replacement, and Google's own successor to the Fitbit Web API. It also gives you sleep with stages, continuous heart rate, heart rate variability and blood oxygen, which the Fitbit path does not. One thing to plan for: Fitbit tokens cannot be carried over, so every user re-consents through Google.
Is that the same as Health Connect?
No, and the difference matters when you plan the work. Health Connect is an on-device layer on Android, so reading it means integrating a mobile SDK into your own app. The Google Health API is a cloud integration with OAuth, no mobile work involved, and it is the one that carries Fitbit data. For a Fitbit migration, the cloud path is the answer.
How much work is the migration?
The schema does not change, so your application code does not either. What changes is which provider a user authorises, and every user re-consents once. The migration guide has the detail.
Does Fitbit have an API at all after this?
Google serves Fitbit data through the Google Health API rather than a standalone Fitbit API. That is the interface to build against.