.png)
Last updated: 18 September 2026
Twelve days. That is what is left before the legacy Fitbit Web API stops serving data on 30 September 2026.
We published a full strategic overview of the Fitbit API deprecation earlier this year covering what changed, why it matters, and how to think about the transition. Now we are providing a tactical guide for teams using Thryve who need to know exactly what happens on 30 September, which of the two available paths is right for them, and what to do this week.
As of today, Google has not communicated an extension. We are planning on the basis that the date holds.
Fitbit connections stop returning data. Once Google turns the API off, existing authorizations can no longer retrieve user data.
Within 24 hours, we will proactively disconnect all Fitbit connections on the Thryve side. A connection that still reads "Connected" while no data arrives is not useful to your users or to you. Marking connections as disconnected gives your app an accurate status to work from, so you can guide users to a new source if needed.
Your historical Fitbit data stays. Everything already ingested remains available against the same end-user ID, under the Fitbit data source. You simply stop receiving new Fitbit data.
There is no migration of existing authorizations. This is worth repeating because it catches teams out: Google provides no mechanism to carry an existing Fitbit authorization over to Google Health. Every single user must re-authorize, whichever path you choose.
This is the full-fidelity route and the one we recommend for the long term. It delivers the broadest data coverage and behaves like any other Thryve web source.
The critical point to understand is that Google Health does not permit shared infrastructure. Unlike the Fitbit Web API, where Thryve could operate credentials on behalf of many customers, Google Health requires each partner to bring their own OAuth credentials, tied to their own Google Cloud project and their own verified app. We cannot run this for you, and we cannot accelerate it, the review sits between you and Google.
A detailed setup guide is available on request. Contact us here!
Everything above is work you control and can move through quickly. The timeline is set by two things you do not control:
Until both are complete, you are capped at 100 users on an unverified configuration.
If you cannot finish verification in time, or you have decided that the CASA cost and annual renewal do not justify the integration, there is now a route on both platforms that avoids Google Health credentials, OAuth verification, and CASA entirely.
The mechanism is the same on both platforms: Google Health writes the user's data into the platform health store, and Thryve reads it from there via our SDK. You already have this integration if you support Apple Health or Health Connect today.
One important note: Google shipped the Apple Health sync recently, and the public Google Health communities show a number of open bugs. The integration is still in its early stages and minor issues should be expected.
Requires iOS 16.4 or higher and a Google Account. The steps the end user must complete:
What Google Health writes to Apple Health:
Requires Android 9 or higher. This route has been available longer and is the more stable of the two. The same chain applies: the user grants Google Health write access to Health Connect, then connects Health Connect to your app via the Thryve SDK.
What Google Health writes to Health Connect:
Set the data source priority. Health Connect resolves overlapping data from multiple apps using a priority order in the user’s app. If Google Health is not at the top of that list, another app on the device can take priority for shared types like steps, and you will read the wrong number. Put Google Health high in the priority list and make this an explicit step in your onboarding instructions. It is the most common cause of "the data is wrong" reports on this route.
On both platforms, data is tagged with the on-device source, Health Connect or Apple Health, not as Google Health. To identify Google Health as the originating app, check the third-party data source parameter on the record.
If you are on Path A and your users have migrated their Fitbit account to a Google Account and are actively using Google Health, we can potentially recover some of the data missed during your gap period once the connection is live. The recoverable window is limited, and Google has not yet published a definitive historical lookback limit for the Google Health API.
Data delivery currently uses cron-based scheduled retrieval, with a maximum delay of up to 15 minutes for new data. We will switch to ping-based event-driven retrieval once it is stable in production in the coming weeks. The switch does not change what data you receive.
If you are unsure which path fits your situation, or you want us to review your scope list before you submit to Google, get in touch with us here!
mith Tony Joseph is a Product Manager at Thryve, where he works at the intersection of wearable data, medical device integrations, and API-driven infrastructure, helping insurers and digital health providers unlock real-time health data at scale. An engineer turned PM, Amith brings experience across health data, AI strategy, and social impact, including co-founding OpenGrad Foundation, an Ed-tech non-profit that has directly impacted 3,000+ students across India. He holds a Master's in Global Management from ESMT Berlin.
.png)
.png)