Migrating from the Fitbit Web API to the Google Health API

Why this is happening#

Fitbit accounts are being folded into Google accounts, and the developer platform is moving with them. The legacy Fitbit Web API — reported to expose 120+ individual endpoints — is being replaced by the Google Health API, described as built from the ground up with bundled data types rather than the old per-endpoint model. If you have a working Fitbit integration today, none of this is a URL swap: you re-map endpoints to a new schema, adopt Google OAuth 2.0, and put your users through a fresh consent flow.

This page is the move. For how the Fitbit integration itself is built, see the Fitbit API integration guide. If the retirement is prompting you to reconsider the provider entirely, weigh the options in Fitbit API alternatives and the Fitbit API vs Garmin API comparison. If your integration feeds a research study with enrolled participants, Fitbit data for research studies after the turndown covers what Google's research policy adds on top of this move.

What actually changes#

Because the two OAuth libraries differ, the recommended pattern is to run both in your codebase during the transition and put an abstraction layer over your health-data service, so the rest of your app does not care which path is live. That same insulation is what an aggregator can provide wholesale.

Dates: what Google confirms and what is still reported#

Google's Google Health API page (read October 12, 2026) gives two dates. Support for the Fitbit Web API ended on September 30, 2026, and the API keeps operating without bug fixes or API support until October 30, 2026, when Google turns it off and it stops functioning or syncing data to or from Fitbit users. Google says every current integration must move its apps and users to the Google Health API and Google OAuth 2.0 as soon as possible. While the legacy API is still active, Google's Health API migration guide says apps temporarily need to support both authentication methods across their user base, though never both for one user.

One date remains reported rather than confirmed. Vendor and community notices (Fitbit Community, Google Health support threads, and aggregator blogs) had users migrating their Fitbit login to a Google Account before roughly mid-May 2026. Google's Fit migration guide (updated September 10, 2026) lists the Google Health API as the recommended path for Fitbit Web API integrations. The Fitbit API deprecation status page grades each date as confirmed or reported. This login migration is one of the tracked changes listed by month in the monthly digest.

The migration, step by step#

1. Audit your current Fitbit usage. List every Web API endpoint, scope, and data type you consume, your user volume, and where refresh tokens live.
2. Watch the official notices. Subscribe to the Fitbit developer/community and Google Health API notices. Google's Google Health API page lists end of support on September 30, 2026 and the turn-off on October 30, 2026; treat any other date as provisional until confirmed there.
3. Register on the Google Health API console and set up Google OAuth 2.0 credentials for the new app.
4. Map endpoints and schema. Build an old-endpoint → new-bundled-data-type table and adapt to the new response format; flag any data type without a confirmed equivalent. Google publishes its own data-type, scope and endpoint mapping tables, reproduced in the Fitbit Web API to Google Health API mapping; each successor data type's operations, scopes and fields are in the Google Health API reference.
5. Add an abstraction layer over your health-data service so the legacy Fitbit path and the Google Health path can coexist during the bridge window.
6. Plan mandatory re-auth. Design a re-consent flow that has every user sign in with Google and re-grant permissions — you cannot reuse Fitbit tokens. Communicate the account-consolidation step, since un-consolidated accounts reportedly cannot use the new API.
7. Run both paths in parallel until the legacy API's October 30, 2026 turn-off, supporting both login methods across your user base but never both for one user; migrate users in cohorts and monitor for data gaps and auth failures.
8. Cut over, then decommission. Google's Google Health API page lists the turn-off for October 30, 2026, after which the legacy API no longer syncs data. Move remaining users to the Google Health API as soon as you can, keep a rollback path only until the turn-off, then retire the Fitbit Web API code.

Gotchas and how to keep users connected#

• Tokens do not carry over. The change of OAuth provider means a hard re-consent for every user. Design the reconnect UX early and expect a long tail of users who need reminding — see keeping users connected during a migration.
• Account consolidation is a gate, not a detail. If a user has not migrated their Fitbit login to a Google Account, they may be locked out of the new API entirely. Surface that step in your messaging.
• Data-type parity is not guaranteed. The new API's coverage versus the old Web API is still evolving; verify each data type you depend on before promising it will still be there.
• Do not hard-cut. While the legacy path still answers, run legacy and new in parallel, keep a rollback path, and let existing data keep flowing until each user reconnects.
• Consider an aggregator as insulation. A health-data aggregator that already supports both the legacy Fitbit Web API and the Google Health API can absorb the OAuth and schema change for you, so you keep a single integration instead of rebuilding. Vendors reported to be preparing for this include Terra, Validic, Thryve, Fitabase, and Rook — verify each one's current support status before relying on it. Sahha, a separate company from Thryve, says Fitbit data on Android reaches its SDK through Health Connect.

A note on effort and uncertainty#

Budget for this as a re-integration: new credentials, a new schema mapping, a new OAuth flow, and a user-facing re-consent campaign — not an afternoon of config. The engineering is tractable, but the timeline is the risky part, because Google turns the legacy API off on October 30, 2026 and the account-consolidation date still comes only from third-party notices. Build the abstraction layer, run in parallel, and confirm the account-consolidation date against the official Fitbit and Google Health developer notices before you schedule anything. This is general engineering guidance; verify the live docs at publish time.