Fitbit Web API Still Working After September 30? Shutdown Is October 30, 2026

Google’s migration notice distinguishes support ending from the final shutdown. We have checked the documentation, not a live user’s API connection.

Why is Fitbit Web API still working?

Google announced a one-time 30-day extension. Its September 29 community update attributes the extra time to scheduling bottlenecks for the mandatory Cloud Application Security Assessment (CASA), even while many development teams were approaching code completion. This is Google’s stated reason, not evidence about every project’s readiness. Extension announcement

A successful legacy request today only shows that request succeeded. It does not remove the shutdown deadline or establish that the successor is ready for your app.

September 30, October 30 and December 31 mean different things

• September 30, 2026: legacy support ends. Google no longer provides legacy bug fixes or API support.
• October 30, 2026: Google says the legacy infrastructure will be turned off and will no longer sync data to or from Fitbit users.
• December 31, 2026: the separate demo-account lifetime provision applies to the research and enterprise use cases described in the extension announcement. It does not keep the normal Fitbit Web API running through December.

Use Google’s current migration notice for the API deadline and the extension announcement for the demo-account conditions. Neither source supplies an exact shutdown hour; do not plan around an assumed end-of-day timezone.

Confirm Google Health API access first

As checked on October 1, 2026, Google says it is not onboarding new projects at this time, while working to expand access. The documentation’s registration steps do not guarantee that a new project can obtain production access today. Current access notice

Our planning recommendation: record access as a separate dependency from code completion. An existing participant should confirm its own project status. A developer without access should seek clarification through the official program channels and communicate the unresolved dependency to customers. This page cannot promise an admission date or a universal fallback that preserves the same data access.

Replace authorization, not just the base URL

Google Health uses Google OAuth 2.0 and a new registration model. Existing Fitbit access and refresh tokens cannot be transferred, so users must re-consent. Review your redirect flow, granted scopes and required app registration. Authorization changes, Migration guide

The application can temporarily support legacy and migrated users, but each individual user must have only one active integration. On a successful, verified migration, disable legacy syncing and revoke the old Fitbit tokens. Supporting both systems across the user base does not justify syncing one person through both. Cutover requirements

Google also changes the endpoint and data model. Map the operations your app actually uses against the API specifications; do not assume feature parity from a successful OAuth callback.

Map identity before switching the user

Call users.getIdentity to associate the existing legacyUserId with the new healthUserId. Google’s reference documents these fields for continuity between systems. Validate the returned identity before changing your application’s routing state. Identity reference

The critical boundary is between obtaining OAuth credentials and confirming a usable Google Health account. Treat those as separate checks.

Handle ACCOUNT_NOT_LINKED without cutting off legacy access

Google documents HTTP 400, status FAILED_PRECONDITION, reason ACCOUNT_NOT_LINKED when OAuth succeeds but the account has no active Google Health profile. This can include users who have not set up Google Health or migrated their legacy Fitbit account. Troubleshooting

Call users.getIdentity after exchanging the authorization code and before marking the account connected. On this error:

1. Keep the connection incomplete in your UI.
2. Guide the user to sign in to the Google Health app and create or link their profile, following Google’s guidance.
3. For an existing Fitbit user, keep their legacy connection active and do not revoke the legacy tokens yet.
4. Retry identity verification after the user resolves linking. Cut over only when the required identity and permissions checks succeed.

These steps follow Google’s migration handling. Retaining legacy access is a transition measure within its remaining operational window, not a way around October 30.

Include verification and security assessment in the plan

Google says all Google Health API scopes are categorized as Restricted, requiring a privacy and security review for access. About the Google Health API Its app verification guide describes OAuth verification and a security assessment for restricted-scope applications. Confirm the requirements for your app and coordinate assessment timing; an implemented endpoint does not establish public-launch approval. App verification

What should you do before October 30?

Our migration handoff checklist:

1. Confirm project access and the owner of verification and assessment work.
2. Compare required data types, scopes and operations with Google’s mappings.
3. Implement re-consent, identity mapping and the unlinked-account recovery path.
4. Test successful migration, partial permissions and failed linking separately.
5. Reconcile historical data after reauthentication where supported, and record gaps instead of silently marking them complete.
6. Communicate the final deadline and a recovery path to users who have not migrated.

Google describes historical backfill after users reauthenticate, provided their data remains available through Google Health. It does not establish that your application has already recovered every missing record. Data continuity guidance

Recheck the official access notice and shutdown date before your cutover. Both are external dependencies that can change after this article’s verification date.