For our digital health partners, this is one of those updates that cannot be treated as just another technical release. Fitbit has officially announced the deprecation of its legacy Web API, with a full transition to the new Google Health API by September 2026. At first glance, this may look like a routine modernization effort, but it is actually a much deeper shift in how wearable data is accessed, managed, and integrated into digital health products.
This transition introduces changes across identity, infrastructure, data models, and compliance requirements. With Google OAuth 2.0 replacing Fitbit’s existing authorization system, and a completely restructured API architecture, teams will need to rethink not only their integrations but also their user flows and data pipelines. The requirement for mandatory user re-consent and the need to support both old and new systems during the transition add further complexity.
For companies relying on Fitbit data, this means a coordinated migration that touches product, engineering, and user experience at the same time. More importantly, it reflects a broader trend: health data ecosystems are becoming more centralized, standardized, and tightly controlled by platform providers.
At first, the announcement may look like a standard API upgrade, but it introduces structural changes across infrastructure, identity, and data handling that will directly impact how integrations are built and maintained.
The most visible change is the transition from the Fitbit Web API to the Google Health API, and it is more than a rebranding. The API has been rebuilt on Google Cloud infrastructure, introducing a new developer environment, updated tooling, and a more scalable foundation. For developers, this means adapting to a new ecosystem rather than simply updating endpoints.
Authentication is also changing fundamentally. Fitbit’s proprietary authorization system is being replaced by Google OAuth 2.0, aligning with widely used industry standards. While this simplifies implementation in the long run, it requires updates to existing authentication flows, user permission handling, and account linking logic. It also introduces tighter control over access and consent through Google’s identity layer.
The API structure itself has been streamlined. Instead of managing over 120 individual endpoints, developers now work with bundled data types across standardized REST endpoints. This reduces complexity but requires reworking how data is requested and processed. Additional improvements include consistent error handling, new “list” endpoints for better access to intraday data, and enhanced webhook functionality with auto-subscriptions across data types.
One of the most important changes lies in how data is structured. The new API introduces two distinct data streams. A reconciled stream merges overlapping data from multiple sources into a single, unified dataset, reflecting what users see in the Fitbit app. In parallel, a device and manual log stream provides access to raw Fitbit or Pixel data and user-entered logs.
The migration to the Google Health API introduces several practical challenges that teams need to address early to avoid disruptions in their integrations and user experience.
One of the most immediate challenges is the requirement for mandatory user re-consent. Users will need to actively re-authenticate through Google OAuth after the migration, which introduces a clear risk of drop-off. Without careful communication and well-designed user flows, this step can lead to broken integrations and interrupted data continuity.
Another complexity lies in identity management. Legacy Fitbit user IDs are not directly compatible with the new Google-backed identity system. This means teams must establish a reliable way to map old and new user accounts. The provided getIdentity API plays a critical role here, enabling developers to associate identities across both systems and maintain continuity.
During the transition phase, many teams will need to operate both systems simultaneously. Supporting legacy Fitbit authentication alongside Google OAuth introduces additional engineering overhead and increases the risk of inconsistencies. Managing this “bridging phase” requires careful coordination to ensure a seamless experience for users. For more information, check out our guide on integrating multiple wearable APIs!
Finally, the new API introduces stricter requirements around privacy and security. Applications must be registered through Google Cloud, and access to health data is contingent on passing privacy reviews and security assessments. This adds a new layer of operational responsibility, particularly for teams that have not previously worked within Google’s compliance frameworks.
To navigate this transition successfully, product and engineering teams need to start preparing early. The migration impacts multiple layers of the product, from data pipelines to user experience, and requires a structured approach.
Teams should begin by focusing on a few key areas:
Preparation should also focus heavily on the user experience. Since re-consent is mandatory, teams need to design clear, intuitive flows and communication strategies to guide users through the process. Without this, there is a significant risk of drop-off and data disruption.
From a technical perspective, ensuring data continuity is critical. Teams should validate how the new API structure behaves in practice and confirm that data remains consistent across systems during the transition. We have covered that in our data portability blog post!
The Fitbit migration highlights a broader reality: health data ecosystems are constantly evolving. APIs change, authentication models shift, and data structures are redefined. To keep up, teams need to move beyond one-off integrations and start thinking in terms of long-term resilience.
This starts with building interoperable and reliable infrastructure. At Thryve, this is exactly the problem we solve with our API. We enable teams with:
Book a demo with Thryve to explore how you can build scalable, future-proof health data solutions.
Friedrich Lämmel is CEO of Thryve, the plug & play API to access and understand 24/7 health data from wearables and medical trackers. Prior to Thryve, he built eCommerce platforms with billions of turnover and worked and lived in several countries in Europe and beyond.
.png)
