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?

[SeanParkFit]

Hey @GordonFitbit 

Hi Fitbit Dev Team,

I am working on my migration strategy from the legacy Fitbit Web API to the new Google Health API. I’ve seen two different timelines and want to confirm my understanding of how they affect my existing integration and user tokens.

My Understanding of the Timelines:

1. May 19, 2026 (User Migration Deadline): This is the mandatory date for individual users to switch their login from a legacy Fitbit account to a Google Account.
2. September 2026 (API Sunset): This is the final decommission date for the legacy Fitbit Web API and its associated authorization system.

Specifically, I would like to confirm the following points:

• OAuth Token Validity: If a user completes their migration to a Google Account by May 19th, will their existing Fitbit OAuth 2.0 access and refresh tokens remain valid? My understanding is that these tokens will continue to work for the legacy Fitbit Web API without requiring the user to re-consent until the final September shutdown.
• Token Refreshing: Can I continue to use the current Fitbit Token Endpoint to refresh these tokens through the legacy infrastructure after the May 19th deadline?
• Webhook Continuity: Will existing webhook subscriptions for these migrated users continue to trigger and send sync data to my service as usual through September 2026?
• Onboarding New Users: After May 19th, will the standard accounts.fitbit.com login/authorization page still work for new authorizations, provided the user logs in with their Google Account?
• Transition Strategy: Since the Google Health API requires a Google-linked account, is it correct that we should wait until late May 2026 to launch our new integration to ensure a smoother re-consent flow for users who have already migrated?

Could you please confirm if this "bridge period" (May to September) allows us to maintain our existing Fitbit Web API integration for migrated users while we finalize the switch to the Google Health API?

Thank you!

[josh2112]

Gordon, can you tell us where to report bugs in the Google Health API? The documentation points to the Google Issue Tracker, but when clicking on the link I get "Component ID 1914241 does not exist or you do not have access".

There is one big bug in particular that I'd like to report, and it needs to be fixed before the Fitbit API goes away or there will be no way to reliably and consistently download data about running activities.

Specifically, a "structured" run activity (created through "Build a run" on the Fitbit app) sometimes reports as a "RUNNING" data point (with distance & pace included) and sometimes reports as a "STRUCTURED WORKOUT" activity (with no distance or pace included). It seems to be related to the date/time filtering in the data points API request. If the run data point is far enough down in the list of returned data points (say, 64th or later), it reports as a "STRUCTURED WORKOUT" with missing run data, otherwise it reports as "RUNNING" with full data.

I know this is not the place to report this issue. I'd love for someone to point me in the right direction!