Introducing the next phase of the Fitbit Web API

[GordonFitbit]

Hi Everyone,

Today marks the start of a new chapter! We are officially opening availability for the next generation of our platform: The Google Health API.

This update is a total modernization of our foundation, rebuilt from the ground up on Google’s infrastructure to provide a more scalable and reliable experience for your integrations. By moving to the Google Health API, you’ll gain access to:

• Unified Source of Truth: A new Reconciled Stream that merges overlapping data points, enabling you to surface the same data in your app as they see in the Fitbit app.
• Technical Modernization: We consolidated 123 endpoints down to a streamlined set of data type bundles across REST endpoints and with consistent format and error-handling. 
• Enhanced Identity & Security: Google OAuth 2.0 replaces legacy Fitbit Authorization, simplifying your code via standard libraries and giving users a familiar, streamlined way to manage permissions.
• Updated Webhooks: Our new webhooks now offer support for auto-subscriptions across all relevant data types.

The Timeline:

• Now: Start building! Access the Google Health API documentation, migration guides, and developer tools at https://developers.google.com/health.
• End of May 2026: Target launch date for your new integration.
• Legacy Fitbit Account users will not be able to access the Google Health API. To ensure a seamless transition for your users, we recommend not to launch your new API integrations and OAuth implementation until late May, 2026.
• September 2026: Final deprecation of legacy endpoints. Previous versions of the Fitbit Web API will be decommissioned and data will stop syncing.

To maintain your application's connectivity, you will need to register your project in the Google Cloud Console and migrate to the new endpoints. Please keep in mind that mandatory user re-consent is required, as silent migration is not possible.

We will be providing a suite of tools—including a comparison tool, API Explorer, and a user-linking API to map legacy user IDs to new user IDs—to make this version transition as smooth as possible. We’re excited to see how these new capabilities transform your apps!

Sincerely, 

The Fitbit Team

[GordonFitbit]

@Guy_,

We emailed all of the Fitbit Web API developer accounts that this is happening.  We are providing a lot of content in the Google Health API documentation to help with the migration.  If there are things that are missing, please let us know.  

[GordonFitbit]

Hi @JeffCohen 

We understand this is a tight timeline.  I'm providing feedback to leadership as I receive it.  Unfortunately, we cannot convert the existing tokens to the Google OAuth library because it is a different technology.  What additional tools or help do you need to make the transition quicker?  

[JeffCohen]

Hi @GordonFitbit thanks again for the reply.  I could be wrong, but I would think Google could figure out a way to transform valid Fitbit tokens into valid Google tokens automatically when the cutover happens, by reimplementing the Fitbit API as a shim on top of the Google Health API.  Existing Fitbit scopes can be mapped to Google scopes, even if imperfectly.  With time, users can reauth with the Google flow to take full advantage of the Google API, but I don't see why there has to be a cold cutoff date.  Providing a backward compatibility layer, supported for just 12 months, would give everyone the proper time needed to both rewrite code AND time for users to reauthorize.

Another thing that could be done is to pre-validate those of us with already valid Fitbit apps so we can avoid the weird "submit a video" requirement in order to get into production.  We're already in production with multiple Fitbit apps.  While I like the idea to going foward, I might be able to have just one "app" registered with Google for our platform instead of the old Fitbit requirement of one Fitbit app per clinical study, there's a real risk that my approved Fitbit apps won't be approved with Google, and then I'm in trouble with existing clients.

Thanks again,

Jeff

[Guy_]

@GordonFitbit - the proposal by @JeffCohen  makes a lot of sense.

Instead of a break everything that has ever been developed, over years of careful development, and start again approach, that neither the developers nor Google could possibly handle in such a short time frame, adopt the more logical upward transparent migration where nothing breaks at all.

It is also highly likely that many of the apps that have been going for a long time that people still depend on no longer have the original developers to modify them, let alone Google having the resources to handle the mass of approvals, even if they did. (Google have already proven they don't have the resources to assign to a proper Clocks and Apps approval process).

Having an intelligent compatible upgrade path would alleviate any such problems and reduce the load on everyone, to completely nothing, nothing would get broken at all, and any new features could get introduced gradually over time by developers.

[Haider2802]

Hi @GordonFitbit, I can see my sleep score on the fitbit app, but it was missing on Fitbit web api. As you are migrating to google, is there any plan to add the sleep score with the new api?

Also, any update on connected device list api? I didn't fine any update on the roadmap page.

[nstarr2]

Hi @GordonFitbit,

I want to echo the concerns of @JeffCohen and @Guy_ from the perspective of a Hobbyist/Personal Use developer.

Many of us use the Fitbit Web API for personal health dashboards and home automation (via tools like n8n or Home Assistant). The 'Personal' application type was the heart of the Fitbit developer community because it allowed us to access our own data (including Intraday) without enterprise-level overhead.

I have two major concerns regarding this migration:

1. The 7-Day Token Trap: Standard Google OAuth for 'Testing/Unverified' apps forces refresh tokens to expire every 7 days. For personal automation, this is a massive regression from the long-lived tokens in the legacy API. Will there be a 'Personal Use' tier that allows individuals to access their own data with long-lived tokens?

2. The 'Devices' Gap: I am already experiencing 403 Forbidden errors on the legacy /1/user/-/devices.json endpoint for my Sense 2, despite having the settings scope. If this feature isn't even on the roadmap for the Google Health API yet (as mentioned to Haider2802), we are effectively being cut off from our hardware data months ahead of the deprecation.

Is Google planning to support the 'Personal' developer who just wants to access their own minute-by-minute data, or is the platform moving toward an enterprise-only model?