Key Takeaways
- Google is turning down the legacy Fitbit Web API in September 2026. It is a hard cutoff, not a gradual deprecation, and new Fitbit developer registrations have already closed.
- Today's Fitbit Web API reliably supports workouts and activity data (type, duration, calories, distance, average heart rate) over pull-based OAuth 2.0, rate-limited to 150 requests per hour per user.
- Sleep, intraday heart rate, and daily activity summary are technically available in Fitbit's API but were never built out against it by platforms like Open Wearables, and will not be added now that the API is being retired.
- The successor is the Google Health API: a cloud REST API with no SDK, aggregating Fitbit, Pixel, and other connected sources, with webhooks and a reconcile/list choice for handling overlapping data sources.
- Migrating is closer to adding a new provider than patching an existing integration: a new OAuth flow, a broader data model, and an event-driven sync architecture.
In September 2026, Google is turning down the legacy Fitbit Web API. If your app reads workout, activity, sleep, or heart rate data from Fitbit through that API, this is not a distant deprecation notice to file away. It is a hard cutoff with a fixed date, and new Fitbit developer registrations have already closed, so there is no path to start fresh on the old API even if you wanted to.
This is a practical guide to what is actually shutting down, what still works until then, and how the migration to Google's successor API looks in practice.
What Is Actually Happening
Fitbit's Web API, the one documented at dev.fitbit.com with its own OAuth 2.0 flow and REST endpoints, is being retired by Google. It will stop syncing data entirely once the shutdown lands. This is not Fitbit changing a rate limit or deprecating one endpoint. It is the whole API surface going away.
Two details matter for anyone currently building on it:
- New developer registrations are closed. If you do not already have Fitbit API credentials, you cannot get them. This alone should end any conversation about starting a new integration against the legacy Fitbit API today.
- The API is feature-frozen in the meantime. Existing integrations keep working until the shutdown date, but nobody, including Fitbit itself, is investing further in this surface. Data types that were never implemented against it will not be implemented now.
What the Fitbit Web API Actually Supports Today
If you are running against the current API, here is where it stands. Workouts and activity data (activity type, duration, calories, distance, average heart rate during logged activities) work over OAuth 2.0, pull-based, with no webhook support, so you are polling on a schedule rather than receiving push notifications.
Sleep, intraday heart rate, and daily activity summary are technically available in the Fitbit Web API, but Open Wearables never built these out against it, and will not now, given the shutdown date. Check your own integration's actual coverage rather than assuming; some teams did implement these against the raw Fitbit API directly. If you're relying on a platform like ours that didn't, that gap doesn't get resolved by the shutdown, it just becomes permanent.
Rate limiting sits at 150 requests per hour per user, returning HTTP 429 when exceeded. That number matters for the migration too, since Google's replacement has different limits and a different request model entirely.
The Successor: Google Health API
Google's replacement is the Google Health API, a cloud REST API that requires no SDK. It carries Fitbit account data along with Pixel and other connected sources, aggregated under a single Google Health identity rather than Fitbit's separate developer platform.
The practical implications of switching:
- OAuth changes. You are authenticating against Google's OAuth 2.0 flow and requesting Google Health scopes, not Fitbit's client credentials. This is a genuine re-implementation of your auth layer, not a config change.
- Broader data model. Because the Google Health API aggregates across every source connected to a user's Google Health account, not just Fitbit, you get access to 24/7 metrics (steps, distance, calories, hydration, heart rate, resting heart rate, HRV, VO2 max, respiratory rate, SpO2, weight, body fat, core temperature, blood glucose), workouts, and sleep with stages, most of which never existed on the old Fitbit path for platforms like ours that only implemented workouts and activity against it.
- Webhooks, finally. Unlike Fitbit's pull-only model, the Google Health API supports notify-only webhooks. A notification tells you what changed and when; you fetch the actual data over REST in response. That changes your sync architecture from scheduled polling to event-driven fetches.
- Deduplication becomes your problem, or isn't. A user's steps might be reported by both their phone and a connected Fitbit at once. Google's API exposes a reconcile mode, which returns one merged, deduplicated total matching what the native Google Health app shows, and a list mode, which returns raw per-source data tagged by device. This did not exist as a concept on the old Fitbit API, because there was only ever one source.
What Migrating Actually Involves
The honest scope of this migration is closer to adding a new provider than updating an existing one. You are not patching an integration; you are replacing an OAuth flow, a data model, and a sync mechanism.
A few things worth deciding early:
- Don't wait for the deadline to start. OAuth re-implementation, testing against real Google accounts, and validating your new data model against production traffic all take longer than the runway remaining before the September shutdown makes comfortable.
- Decide on reconcile vs. list mode before you build storage for it. If your existing schema assumes one authoritative value per metric per day, reconcile mode is the closer match. If you need to know which physical device produced a reading, list mode is the only path, but you take on deduplication logic yourself.
- If you are on Open Wearables or a similar abstraction layer, check whether the migration is already absorbed. A unified schema across providers means the switch from Fitbit to Google Health API can be a provider swap rather than a data-model rewrite on your end, since the same endpoints and field names keep working regardless of which upstream API is feeding them.
If You're Evaluating Whether to Migrate at All
There are two paths off the old Fitbit API: the Google Health API described above, or reading the same underlying data on-device through Health Connect (Android) or Apple Health (iOS), which avoids Google's cloud OAuth entirely at the cost of needing a mobile app under your own brand. Which one fits depends on whether you already have a mobile presence and how much of your roadmap depends on server-side access to this data.
Either way, the deadline is fixed and the old registration path is already closed. The only real decision left is which successor to build against, not whether to move.
If you want the specifics of how Open Wearables handles the Google Health API side of this, the integration page covers the OAuth flow, data model, and webhook mechanics in detail. For what the Fitbit connector still does until the shutdown, see the Fitbit integration page.
See related articles
Fitbit Alternatives for Developers
Google CASA and OAuth Verification for Health Apps
Google Health API: A Practical Guide to Getting Started
Google Health API and Google Health Connect: What's the Difference
FAQ
Is Fitbit's API really shutting down?
Yes. Google has confirmed that the legacy Fitbit Web API will be turned down in September 2026 and will stop syncing data. New Fitbit developer accounts are no longer being issued.
Does Open Wearables still support Fitbit?
Yes, for workout and activity data, until the shutdown date. The integration is feature-frozen: Open Wearables is not adding new Fitbit data types, since the API itself is going away.
What Fitbit data is not supported?
Sleep, intraday heart rate, and daily activity summary are available in the Fitbit Web API but were never implemented by platforms like Open Wearables, and will not be added given the shutdown.
What should I migrate to instead of the Fitbit API?
The Google Health API. It is Google's cloud OAuth layer for Google Health data, and it aggregates data from Fitbit accounts, Health Connect, Google Fit, and other connected sources under one integration.
How long do I have to migrate?
The shutdown is set for September 2026. New Fitbit developer registrations are already closed, so the runway is shorter than it may appear. Start the OAuth re-implementation and data model changes well before the deadline rather than waiting for it.
Can I avoid Google's cloud OAuth entirely?
Yes, by reading the same underlying data on-device through Health Connect on Android or Apple Health on iOS instead of the Google Health API. This requires shipping your own mobile app and going through its app store review process.