About the Google Health API

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!

API versions and the public beta channel

The Google Health API uses channel-based versioning in accordance with Google's API Improvement Proposals (AIPs), specifically AIP-185: API versioning and AIP-181: Stability levels. 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.

Compare stable and beta channels

In accordance with AIP-185, 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 and v4 RPC v4beta REST and v4beta RPC
Stability level Production-ready and governed by AIP-180 backward-compatibility rules. 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. Supported through the standard support channels 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 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.
  • End-to-end data pipelines, device synchronization, and service reliability meet production quality standards.
  • In alignment with AIP-185 deprecation rules, any fields or behaviors deprecated during beta testing are removed rather than promoted to v4.

While AIP-181 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. 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 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.

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 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