The Fitbit Web API has been improved and modernized to provide a more
standardized, consistent, and scalable foundation for developer integrations,
and is now called the Google Health API. The Google Health API represents the
strategic evolution of the legacy Fitbit Web API, rebuilt from the ground up on
Google's modern infrastructure.

With this platform, developers gain access to the full power of Google Cloud
developer tooling and the convenience of a familiar, streamlined way for users
to manage their permissions through Google OAuth 2.0.

## What do you get with the Google Health API?

- **Unified source of truth:** Our new "Reconciled Stream" handles the complex task of reconciling overlapping data points from multiple sources. This ensures apps display the same consistent data users see within the Fitbit app. This stream will be provided in addition to our first party stream which includes data from Fitbit and Pixel devices, as well as manual entries.
- **Technical modernization \& performance:** We have consolidated over 100 legacy endpoints down to a streamlined set of simplified data type bundles and eliminated inconsistencies in data formats, time zones, measurement units, and error handling. Furthermore, we now support the HTTP/REST protocol for high-performance data retrieval. Additionally, intraday data and webhooks are now available for all relevant data types through a dedicated list endpoint.
- **Enhanced webhooks \& scalability:** Benefit from expanded webhook support, including auto-subscriptions and detailed management for all relevant data types, designed to scale with the next generation of AI-driven health apps.
- **Streamlined identity \& security:** Replace legacy Fitbit Authorization (FOT) with Google OAuth 2.0. This allows developers to utilize standard Google authentication libraries, simplifying codebases while providing users with a familiar, centralized way to manage their permissions. All Google Health API scopes are categorized as Restricted, necessitating a privacy and security review for access.

Like what you see? [Get started now](https://developers.google.com/health/get-started)!

## API versions and the public beta channel

The Google Health API uses channel-based versioning in accordance with Google's
[API Improvement Proposals
(AIPs)](https://google.aip.dev/), specifically
[AIP-185: API
versioning](https://google.aip.dev/185#channel-based-versioning)
and [AIP-181: Stability
levels](https://google.aip.dev/181). The API is
available across two public channels: the stable `v4` channel and the public
beta `v4beta` channel. Google supports both channels through the standard
[support channels](https://developers.google.com/health/support).

> [!CAUTION]
> **Caution:** Using `v4beta` endpoints or beta data types in production applications is not recommended. The `v4beta` channel is not stable and is intended primarily for testing, prototyping, and evaluation.

### Compare stable and beta channels

In accordance with
[AIP-185](https://google.aip.dev/185#channel-based-versioning),
the `v4beta` channel acts as a superset of the stable `v4` channel. It includes
all stable `v4` functionality alongside early-access data types, fields, and
methods that are undergoing partner testing.

In the documentation, API elements that are only available in the beta channel
display the v4beta label.

| Feature | Stable channel (`v4`) | Public beta channel (`v4beta`) |
|---|---|---|
| REST base URI | `https://health.googleapis.com/v4` | `https://health.googleapis.com/v4beta` |
| gRPC package | `google.devicesandservices.health.v4` | `google.devicesandservices.health.v4beta` |
| Reference docs | [v4 REST](https://developers.google.com/health/reference/rest/v4/users.dataTypes.dataPoints) and [v4 RPC](https://developers.google.com/health/reference/rpc/google.devicesandservices.health.v4) | [v4beta REST](https://developers.google.com/health/reference/rest/v4beta/users.dataTypes.dataPoints) and [v4beta RPC](https://developers.google.com/health/reference/rpc/google.devicesandservices.health.v4beta) |
| Stability level | Production-ready and governed by [AIP-180 backward-compatibility rules](https://google.aip.dev/180). | Unstable preview subject to incompatible changes or removal at any time without notice. |
| Intended use | Live, user-facing production applications. | Early testing, prototyping, schema validation, and developer feedback. |
| Support | Supported through the standard [support channels](https://developers.google.com/health/support). | Supported through the standard [support channels](https://developers.google.com/health/support) for bug reports, troubleshooting, and design feedback. |

### How to treat the v4beta channel

When exploring capabilities tagged with v4beta, follow
these guidelines:

- Use `v4beta` primarily in development, staging, and non-production testing environments. Shipping production features that depend on `v4beta` endpoints or beta-only data types is not recommended.
- Expect schemas, field names, endpoint behaviors, and data representations in `v4beta` to change without warning. Beta features and data types can also be removed entirely if they don't meet validation goals.
- Isolate experimental `v4beta` client code behind feature flags or separate modules so that breaking changes in the beta channel don't disrupt your core `v4` integration.
- Get support, report issues, and share implementation feedback for `v4beta` through our standard [support channels](https://developers.google.com/health/support) to help shape the final API design.

### Promotion from v4beta to stable v4

New data types and features enter `v4beta` to support partner testing and
market validation before graduating to the stable `v4` channel.

Google evaluates beta features against the following criteria before promoting
them to `v4`:

- Partner testing confirms that the data model, field semantics, and query patterns meet real-world application requirements.
- Developer feedback and design reviews are complete, and the schema is ready to be locked under [AIP-180 backward-compatibility
  guarantees](https://google.aip.dev/180).
- End-to-end data pipelines, device synchronization, and service reliability meet production quality standards.
- In alignment with [AIP-185 deprecation
  rules](https://google.aip.dev/185#deprecating-api-functionality), any fields or behaviors deprecated during beta testing are removed rather than promoted to `v4`.

While [AIP-181](https://google.aip.dev/181#beta)
provides a general rule of thumb of roughly 90 days for beta evaluation, the
actual timing for promoting a feature from `v4beta` to `v4` depends on feature
complexity, hardware availability, and validation feedback. Some features may
graduate sooner, while others may remain in `v4beta` longer or be discontinued.

When a data type or feature is promoted to the stable `v4` channel, Google
announces the graduation in the [Release notes](https://developers.google.com/health/release-notes). At that
point, update your requests from `https://health.googleapis.com/v4beta` to
`https://health.googleapis.com/v4` before releasing the integration to production users.

## What about the Fitbit Web API?

The legacy Fitbit Web API is being turned down according to the following
timeline:

- **September 30, 2026 (End of support):** Support for the Fitbit Web API ends. The API will continue to operate, but Google will no longer fix bugs or provide API support.
- **November 2, 2026 (API turn-off):** The Fitbit Web API and Fitbit OAuth endpoints will be turned off and will no longer function or sync data to or from Fitbit users. Requests to these endpoints will fail and return an HTTP `410 Gone` status code.

All current integrations utilizing the Fitbit Web API and Fitbit Authorization
must migrate their applications and users to the Google Health API and Google
OAuth 2.0 as soon as possible to ensure uninterrupted data continuity.

See the [migration guide](https://developers.google.com/health/migration) to get started.

## What devices are supported?

All Fitbit devices and Google Pixel watches, current and previous, will
collect data that is returned through the Google Health API. The type of data
available will depend on the functionality the devices support.

The list of current devices can be found on the [Google
Store](https://store.google.com/us/category/watches_trackers).

## How do I provide feedback?

Your feedback is highly valued. We encourage you to share your thoughts through
our support channels, which are listed on the [Support](https://developers.google.com/health/support) page.

While we have gone to great lengths to ensure these APIs support you well, the
Google Health API is actively evolving. Please be aware that based on your
feedback, we may introduce changes between now and the end of May that would
require corresponding updates on your end.

## Roadmap

These are a list of features that are coming in 2026.

### Q4 2026

**Data Types (read \& write)**

- Granular skin temperature
- Basal Metabolic Rate
- We'll be adding data types to reach parity with Health Connect. You can expect many more of the Health Connect data types to be added in Q4 2026 and Q1 2027.

**Features**

- Public beta channel for early access to new data types
- Statistics endpoint to monitor webhooks telemetry