Google Health API reference: every data type, scope and method

The Fitbit Web API turn-down

As Google’s About page states it:

1. 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.”

2. October 30, 2026 — API turn-off

   “The Fitbit Web API will be turned off and will no longer function or sync data to or from Fitbit users.”

Quoted from Google’s About page, last updated 2026-09-29, read 2026-10-17. What else is confirmed and what is only reported: the Fitbit Web API retirement page.

What changes from the Fitbit Web API

Each point in Google’s words, with the page it comes from.

Google OAuth 2.0 replaces Fitbit authorization

“Streamlined identity & security: Replace legacy Fitbit Authorization (FOT) with Google OAuth 2.0.” Google — About

Restricted scopes and a review

“All Google Health API scopes are categorized as Restricted, necessitating a privacy and security review for access.” Google — About

“Most scopes for the Google Health API are restricted, which means you must complete verification before your app is publicly available.” Google — App verification

Unverified apps are capped

“If your app isn't verified, it's limited to 100 users.” Google — App verification

Every user re-consents

“Because of the switch to a new OAuth library, existing access and refresh tokens cannot be transferred, requiring users to re-consent to your updated integration.” Google — Migration guide

A new user identifier

“The legacy Fitbit Web API identifies accounts using a 6-character alphanumeric string (such as A1B2C3), whereas the Google Health API utilizes a healthUserId formatted as a string of up to 63 digits & characters.” Google — Migration guide

“To bridge this gap without losing user context, developers can query the getIdentity endpoint to get the Fitbit and Health user IDs.” Google — Migration guide

No dual-linking

“Never allow a single user to have both a legacy Fitbit Web API connection and a Google Health API connection active simultaneously ("dual-linking").” Google — Migration guide

Accounts must be linked first

“A user must sign in to the Google Health mobile app to link Google Health to their Google Account before your app can sync data through the Google Health API.” Google — Migration guide

A new base URL

“Service Endpoint: The base HTTP URL changes to https://health.googleapis.com.” Google — API specifications

The two restricted-scope sentences do not say the same thing — “all” on the About page, “most” on the app-verification page — so this page quotes both and lists the difference with the other disagreements. Verification, the security assessment and the quotas in full: access and rate limits. The move itself, step by step: migrating from the Fitbit Web API to the Google Health API.

All 44 data types, by scope family

Grouped by the scope family Google’s table lists for each type (Google’s own scope ids, in the Scopes page’s order); within a family, in the table’s order. Operations are as the table prints them.

The exercise data type’s exerciseType values are listed one by one, beside the HealthKit, Health Connect and Wear OS constants of the same name, on Google Health API exercise types.

Methods

The v4 discovery document (revision 20261014) defines 27 methods, 9 of them on users.dataTypes.dataPoints. The count is how many of the 44 table types list an operation that maps to the method.

Google’s data-types page on the rollup range: “A maximum query range of 14 days for calories-in-heart-rate-zone, heart-rate, active-minutes, and total-calories.” and “A maximum query range of 90 days for all other data types.” The table’s “update” has no method of that name; Google’s endpoint-mapping table points updates at patch, and each type that lists it carries a flag saying so.

The other 18 methods

• projects.subscribers.create — POST v4/projects/{projectsId}/subscribers — Registers a new subscriber endpoint to receive notifications. A subscriber represents an application or service that wishes to receive data change notifications for users who have granted consent.
• projects.subscribers.delete — DELETE v4/projects/{projectsId}/subscribers/{subscribersId} — Deletes a subscriber registration. This will stop all notifications to the subscriber's endpoint.
• projects.subscribers.list — GET v4/projects/{projectsId}/subscribers — Lists all subscribers registered within the owned Google Cloud Project.
• projects.subscribers.patch — PATCH v4/projects/{projectsId}/subscribers/{subscribersId} — Updates the configuration of an existing subscriber, such as the endpoint URI or the data types it's interested in.
• projects.subscribers.subscriptions.create — POST v4/projects/{projectsId}/subscribers/{subscribersId}/subscriptions — Creates a subscription for a specific user to a specific subscriber. This method requires the subscriber to have a SubscriptionCreatePolicy set to MANUAL for the given data types.
• projects.subscribers.subscriptions.delete — DELETE v4/projects/{projectsId}/subscribers/{subscribersId}/subscriptions/{subscriptionsId} — Deletes a specific user subscription, stopping notifications for this user to this subscriber.
• projects.subscribers.subscriptions.list — GET v4/projects/{projectsId}/subscribers/{subscribersId}/subscriptions — Lists all active subscriptions for a given subscriber. This can be filtered, for example, by user or data type.
• projects.subscribers.subscriptions.patch — PATCH v4/projects/{projectsId}/subscribers/{subscribersId}/subscriptions/{subscriptionsId} — Updates the data types for an existing user subscription.
• shl.m.getShlManifest — POST v4/shl/m/{externalShlId} — Forward a manifest request for a given SHL
• shl.r.get — GET v4/shl/r/{externalShlId}/{resourceToken} — Forward a resource request for a given SHL
• users.getIdentity — GET v4/users/{usersId}/identity — Gets the user's identity. It includes the legacy Fitbit user ID and the Google user ID and it can be used by migrating clients to map identifiers between the two systems.
• users.getIrnProfile — GET v4/users/{usersId}/irnProfile — Returns user's IRN Profile details.
• users.getProfile — GET v4/users/{usersId}/profile — Returns user Profile details.
• users.getSettings — GET v4/users/{usersId}/settings — Returns user settings details.
• users.updateProfile — PATCH v4/users/{usersId}/profile — Updates the user's profile details.
• users.updateSettings — PATCH v4/users/{usersId}/settings — Updates the user's settings details.
• users.pairedDevices.get — GET v4/users/{usersId}/pairedDevices/{pairedDevicesId} — Returns user's Device.
• users.pairedDevices.list — GET v4/users/{usersId}/pairedDevices — Returns the user's list of paired 1P trackers and smartwatches.

Rate limits

Google’s default quotas, as its rate-limits page prints them:

“When your application exceeds an allocated rate limit, the API rejects the request and returns the error 429 Too Many Requests.” — Google’s rate-limits page, last updated 2026-05-18. Verification, quota increases and 429 handling.

Release history

The 8 dated entries in Google’s release notes, newest first, with the headings Google gives each.

1. October 1, 2026

   New Beta Channel · New Data Type · New API Guide

2. August 17, 2026

   New Scopes · New Data Types · Highlighted Documentation Updates

3. August 14, 2026

   Updated migration guidance · New Promote Google Health page

4. June 22, 2026

   Google Health Status Dashboard

5. June 17, 2026

   Google Health API parity tool

6. May 26, 2026

   New Scopes · Scope Name Changes · New Data Types · New Endpoints · Webhooks · Highlighted Documentation Updates

7. April 14, 2026

   New Data Types · New Endpoints · Webhook Support · Additional features

8. March 24, 2026

   Core features highlights · Supported Data Types · Key Endpoints for Interaction

Where Google’s pages disagree

Comparing the data-types table with the Scopes page, the Fitbit mapping tables, the webhooks guide, the release notes and the discovery documents finds 31 disagreements, across 20 data types and the scope lists. They are published as found; none is corrected here.

• Rollup missing from the table (4): activity-level, daily-heart-rate-variability, daily-resting-heart-rate
• Operation name differs (11): body-fat, exercise, height, hydration-log, menstrual-period, moods, nutrition-log, ovulation-test, sleep, symptoms, weight
• No v4 DataPoint field (3): calories-in-heart-rate-zone, skin-temperature-sensors, total-calories
• Method missing from the table (1): exercise
• Reference link points elsewhere (1): floors
• Scope missing from the discovery document (5): food, food-measurement-unit, hydration-log, nutrition-log
• Scope missing from the Scopes page (3)
• Mapped type missing from the data-types table (1)
• Release note and webhook pages differ (1): total-calories
• Restricted-scope wording differs (1)

The ones that concern no single data type

• Scope missing from the Scopes page

  The v4 discovery document defines .reproductive_health.readonly ("See your Google Health reproductive health data"); the Scopes page does not list it.

  • the v4 discovery document: “https://www.googleapis.com/auth/googlehealth.reproductive_health.readonly”
  • the v4 discovery document: “See your Google Health reproductive health data”

• Scope missing from the Scopes page

  The v4 discovery document defines .logged_symptoms.readonly ("See your Google Health logged symptoms data"); the Scopes page does not list it.

  • the v4 discovery document: “https://www.googleapis.com/auth/googlehealth.logged_symptoms.readonly”
  • the v4 discovery document: “See your Google Health logged symptoms data”

• Scope missing from the Scopes page

  The v4 discovery document defines .mindfulness.readonly ("See your Google Health mindfulness data"); the Scopes page does not list it.

  • the v4 discovery document: “https://www.googleapis.com/auth/googlehealth.mindfulness.readonly”
  • the v4 discovery document: “See your Google Health mindfulness data”

• Scope missing from the discovery document

  The Scopes page documents .nutrition.readonly ("See your Google Health nutrition data."); the v4 discovery document does not define it.

  • Google's Scopes page: “.nutrition.readonly”
  • Google's Scopes page: “See your Google Health nutrition data.”

• Mapped type missing from the data-types table

  Google's Fitbit mapping table maps "Activity caloriesBMR" to basal-energy-burned, which the data-types table does not list; the v4 discovery document does have DataPoint.basalEnergyBurned.

  • Google's Fitbit migration API specifications: “Activity caloriesBMR”
  • Google's Fitbit migration API specifications: “basal-energy-burned”
  • Google's Fitbit migration API specifications: “The calories burned due to Basal Metabolic Rate (BMR) over a specific period of time.”
  • the v4 discovery document: “Optional. Data for points in the basal-energy-burned interval data type collection.”

• Restricted-scope wording differs

  Google's pages word the restricted-scope rule differently: About the Google Health API says "all"; App verification says "most".

  • Google's About page: “All Google Health API scopes are categorized as Restricted, necessitating a privacy and security review for access.”
  • Google's app-verification page: “Most scopes for the Google Health API are restricted, which means you must complete verification before your app is publicly available.”