---
title: "Fitbit API Integration Status"
description: "The Fitbit Web API turns off on 30 October 2026. Fitbit data continues through the Google Health API, self-hosted in your own cloud and MIT licensed."
canonical_url: "https://openwearables.io/integrations/fitbit"
---

# Fitbit data now comes through the Google Health API

Fitbit integration

Google ended support for the legacy Fitbit Web API on 30 September 2026 and turns it off on 30 October.

Fitbit data has not gone away: Google aggregates it at the account level, and the Google Health API reads that layer, in the same schema and the same deployment you already run.

[Google Health API integration](https://openwearables.io/integrations/google-health) [Read the migration guide](https://openwearables.io/blog/fitbit-web-api-shutdown-2026-migration-guide)

Where things stand

## What this means in practice

[Google's timeline](https://developers.google.com/health/about)

### The Web API turns off

Support ended on 30 September 2026, and on 30 October the API stops syncing data to or from Fitbit users.

### Existing connections sync until then

Workouts keep flowing for accounts already connected, up to the turn-off date Google has set.

### No new Fitbit builds

Every integration has to move to the Google Health API, so starting on the Fitbit Web API now is work that expires within weeks.

### The integration is frozen

Sleep, intraday heart rate and daily summaries exist in the Web API, and we will not be adding them.

### Your data stays where it is

Everything already synced sits in your own deployment and schema, and the turn-off does not touch it.

Until the turn-off

## What Fitbit still returns

For connections that already exist, workouts continue in the same schema as every other source.

### Workouts

Calories, steps, distance and minimum, average and maximum heart rate.

### Activity types

Mapped to one sport taxonomy, with a fallback for anything unrecognised.

### Device name

Which Fitbit recorded the session.

The path forward

## The Google Health API

Google now aggregates Fitbit data at the account level, and the Google Health API reads that layer, so Fitbit data keeps arriving after the Web API is gone.

[Google Health API integration](https://openwearables.io/integrations/google-health)

### Not to be confused with Health Connect

Health Connect is an on-device Android layer that needs a mobile SDK in your app. The Google Health API is a cloud integration with OAuth, and it is the one that carries Fitbit data.

### What changes

Users connect to Google rather than to Fitbit, and Fitbit tokens cannot be carried over, so every user re-consents once through Google.

### What you gain

Sleep with stages, continuous heart rate, heart rate variability, blood oxygen, respiratory rate and VO2 max, none of which the Fitbit path gives you today.

### What stays the same

Same schema, same deployment, same cloud account, so your application code does not change.

## Keep Fitbit data flowing

The Google Health API carries Fitbit data in the same schema and deployment you already run. Your code stays as it is.

[Google Health API integration](https://openwearables.io/integrations/google-health) [Book a demo](https://openwearables.io/book)

FAQ

## Do you have more questions?

### When exactly does the Fitbit Web API shut down?

Support ended on 30 September 2026, and on 30 October 2026 the API is turned off and stops syncing data to or from Fitbit users. [Google's announcement](https://developers.google.com/health/about) has the full timeline.

### Our integration is live today. Will it break before then?

Existing connections keep syncing workouts until the turn-off on 30 October. Google no longer supports the API, though, so plan the move now rather than at the deadline.

### Can we still set up a new Fitbit integration?

Not one worth building. Every integration has to move to the Google Health API, and the Web API turns off within weeks, so a new build would stop working almost as soon as it shipped.

### Why are you not adding sleep and heart rate for Fitbit?

Both exist in the Fitbit Web API, and both stop working when it turns off. Building them would mean shipping features with a known expiry date, so that effort goes into the Google Health API path instead.

### What happens to the Fitbit data we have already synced?

It stays in your own deployment, in your own schema, under your own credentials. The turn-off affects what arrives next, not what you already hold.

### Is the Google Health API a replacement or a workaround?

A replacement, and Google's own successor to the Fitbit Web API. It also gives you sleep with stages, continuous heart rate, heart rate variability and blood oxygen, which the Fitbit path does not. One thing to plan for: Fitbit tokens cannot be carried over, so every user re-consents through Google.

### Is that the same as Health Connect?

No, and the difference matters when you plan the work. Health Connect is an on-device layer on Android, so reading it means integrating a mobile SDK into your own app. The Google Health API is a cloud integration with OAuth, no mobile work involved, and it is the one that carries Fitbit data. For a Fitbit migration, the cloud path is the answer.

### How much work is the migration?

The schema does not change, so your application code does not either. What changes is which provider a user authorises, and every user re-consents once. The [migration guide](https://openwearables.io/blog/fitbit-web-api-shutdown-2026-migration-guide) has the detail.

### Does Fitbit have an API at all after this?

Google serves Fitbit data through the Google Health API rather than a standalone Fitbit API. That is the interface to build against.