The Fitbit Web API Shuts Down in September 2026: What Your Health App Has to Migrate

Introduction

If your product reads Fitbit data through the Fitbit Web API, you have a dated deadline rather than a vague platform risk. Fitbit's own developer documentation now carries the notice: the legacy Fitbit Web API is being deprecated in September 2026, and developers are told to migrate their applications to the Google Health API to keep data flowing for their users.

That is a short runway for work that touches authentication, data mapping, and every existing user's consent. Teams that treat it as a swap of one base URL for another will find the token problem late, and the token problem is the part that involves users rather than code.

This article covers what actually changes, what the Google Health API gives you in return, and how to sequence a migration that has to be done before the turndown. If you have been through a provider disruption before, the shape will be familiar from Garmin's developer program pause, with one difference: this one has a published date attached.

What the Fitbit Web API Deprecation Actually Breaks

The Fitbit Web API is the REST interface that health and fitness products have used for years to pull activity, sleep, and heart-rate data from Fitbit accounts. After the turndown it stops syncing data for Fitbit users, which means any product depending on it loses that source rather than seeing it degrade.

Three things break at once, and they break in different parts of your stack. The endpoints themselves stop serving data. The OAuth grants your users approved are tied to Fitbit's authorization server rather than Google's, so they cannot be transferred to the new API. Any historical backfill logic written against Fitbit's resource shapes and rate limits needs rewriting against a different schema.

The practical consequence is that this is not a migration you can ship quietly behind a feature flag. Users have to act, and that puts product, support, and lifecycle messaging on the critical path alongside engineering.

The Google Health API Is an Aggregation Layer, Not a Fitbit Replacement

The most common misread is treating the Google Health API as the Fitbit Web API with a new name. It behaves differently in a way that changes what your product receives.

A single OAuth connection to a user's Google account returns data from the sources connected to that account, so Fitbit data arrives alongside data from Google Fit and other connected applications through the same integration. For a product that only ever wanted Fitbit, that is more data than you asked for. For a product that wants coverage without maintaining a separate integration per provider, it is a meaningful simplification, and it sits closer to how we already think about integrating multiple wearables without vendor lock-in.

Coverage is broad. Steps, distance, calories, hydration, heart rate, resting heart rate, HRV, VO2 max, respiratory rate, SpO2, weight, body fat, core body temperature, blood glucose, workouts, and sleep with stages are all available, delivered either by polling or by notify-only webhooks. Notify-only matters for how you build: the webhook tells you something changed rather than handing you the payload, so your sync logic still has to fetch. If you are building anything time-sensitive on top of that, the patterns in our guide to real-time alerts from wearable data apply directly.

The Token Problem Is the Schedule Problem

Existing Fitbit OAuth tokens cannot be carried over to the Google Health API. Every user whose Fitbit connection you want to keep has to re-consent through Google OAuth before the September 2026 turndown.

Re-consent rates are never one hundred percent. Some users have stopped opening the app, some will decline, and some will hit the flow at a moment when they are not willing to read an authorization screen. Whatever fraction you lose is a fraction of your connected-device base, and for a product where wearable data drives the core experience, that is churn risk rather than a data-completeness footnote.

Which is why the sequencing matters more than the code. Ship the new integration first and run both paths in parallel, so a user who re-consents moves across cleanly while everyone else keeps working on the old path. Then drive re-consent through the surfaces users actually see, prioritising the cohort whose engagement depends on wearable data. Leave the deprecation of your Fitbit code path until after the turndown date, not before it. Teams adding a second connection path into a system that already has one will recognise the shape of this work from adding a wearable API to an app that already has a backend, and the OAuth patterns for a multi-wearables app carry over almost entirely.

Aggregation Creates a Deduplication Problem

Pulling from an aggregation layer means the same real-world activity can arrive more than once. A user walks for forty minutes carrying a phone while wearing a tracker, and both sources report it. Sum them and you have shown that user roughly twice the steps they took.

This is the class of problem that gets discovered in production, usually through a support ticket about numbers that look wrong. Handling it means deciding source priority per data type, reconciling overlapping time ranges, and keeping provenance on every record so you can explain where a figure came from months later. We worked through this in Open Wearables 0.6.2, which was largely about data accuracy for products reading several sources at once, and it is the same reason reliable health scores depend on the ingestion layer being right before any scoring logic runs.

Products aggregating a single provider today tend to underestimate this. It is worth budgeting for explicitly rather than discovering it after the migration is live.

What We Shipped, and What It Means If You Self-Host

Open Wearables 0.7.0 added a Google Health API integration built for this turndown, with the deduplication and provenance handling described above included rather than left as an exercise. The project's existing Fitbit integration is now feature-frozen: it stays available and supported as-is, and no new data types or features will be added to it, because the forward path is the Google Health API.

If you run Open Wearables yourself, the migration is a provider configuration change plus the user re-consent campaign, and the normalization work is already done. If you are reading this from a closed wearable API, the timeline is whatever your vendor decides it is, which is the structural argument we made in why teams outgrow SaaS aggregators. The code and current provider coverage live in the Open Wearables repository.

Either way, September 2026 is close enough that the re-consent campaign, not the integration, is what should be on this quarter's roadmap.

Getting Help With the Migration

We build and run wearable data infrastructure for health products, including migrations off deprecated provider APIs. If the Fitbit Web API deprecation lands in the middle of a roadmap you cannot pause, our wearables integration team can take the data layer while yours keeps shipping product.

Related Articles

Open Wearables 0.7.0: a Google Health API integration built for the Fitbit sunset: the release that added the integration described here.

Garmin's Developer Program Is Paused: What It Means for Your Roadmap: the last provider disruption and how teams absorbed it.

How to Implement OAuth for a Multi-Wearables App: the auth patterns a second connection path needs.

Open Wearables 0.6.2: Wearable Data Accuracy for Multi-Device Health Apps: deduplication and provenance when several sources overlap.

How to Add a Wearable API to an App That Already Has a Backend: integrating without rebuilding what you have.

Wearable API Integration: Why Teams Outgrow SaaS Aggregators: why vendor timelines become your timelines.