---
title: "Fitbit Data for Research Studies After the Web API Turndown"
canonical: "https://aifitnessapi.com/migrate/fitbit-research-studies-after-turndown"
cluster: "Migrations"
primary_query: "fitbit data for research studies after the web api turndown"
last_reviewed: "2026-10-12"
description: "Moving an enrolled Fitbit study to the Google Health API before the October 30, 2026 turn-off: re-consent, the research attestation, gaps and backfill."
publisher: "AIFitnessAPI — independent, not sponsored"
cite_as: "\"Fitbit Data for Research Studies After the Web API Turndown\", AIFitnessAPI, https://aifitnessapi.com/migrate/fitbit-research-studies-after-turndown"
---

# Fitbit Data for Research Studies After the Web API Turndown

> Google ended support for the Fitbit Web API on September 30, 2026 and turns it off on October 30, 2026, which is 18 days away as of October 12, 2026. Fitbit Web API tokens cannot be transferred to its successor, the Google Health API, so every participant whose data you still need has to re-consent with a Google Account. Google's research policy also requires approval or a waiver from an independent review board, such as an IRB or ethics committee. Missing the cutoff does not have to cost you a participant's data, because Google says it stays available while they keep syncing to the Google Health app and can be backfilled once they re-authenticate, though your dataset may have a gap until then.

- Canonical: https://aifitnessapi.com/migrate/fitbit-research-studies-after-turndown
- Last reviewed: 2026-10-12
- Publisher: AIFitnessAPI (https://aifitnessapi.com) — independent, not sponsored
- Cite as: "Fitbit Data for Research Studies After the Web API Turndown", AIFitnessAPI, https://aifitnessapi.com/migrate/fitbit-research-studies-after-turndown

---

## Where things stand, as of October 12, 2026

Google's [developer documentation](https://developers.google.com/health/about) says the Fitbit Web API "is now called the Google Health API". End of support came on September 30, 2026. The old API keeps operating, but Google no longer fixes bugs or provides API support. On October 30, 2026, Google turns it off, and it "will no longer function or sync data to or from Fitbit users". As of October 12, 2026, that is 18 days away.

Google says current integrations "must migrate their applications and users to the Google Health API and Google OAuth 2.0 as soon as possible". The [general Fitbit Web API to Google Health API migration guide](/migrate/fitbit-web-api-to-google-health) covers the engineering: Google OAuth, endpoint mapping, and running both paths side by side. This page covers what a study adds on top of that.

This page is not legal or IRB advice; confirm what your study needs with your IRB or ethics committee and with counsel.

## What Google's research rules add

Google publishes a [Google Health API User Data and Health Research Policy](https://developers.google.com/health/policies/health-api-user-data-and-research-policy) and a [Google Health API Research Pledge](https://developers.google.com/health/policies/health-api-research-pledge), both marked "Effective as of March 24, 2026". The policy says the API may be used for human subjects research only if the research is submitted for review, reviewed or approved by an independent board, such as an IRB under 45 C.F.R. §§ 46.101-115 or an Ethics Committee under Directive 2001/20/EC or 2005/28/EC. Google may "deny or revoke your authorization for health research". What lands on a study team:

- **Health Research Attestation.** A completed intake form, the IRB/EC approval or waiver letter, the IRB/EC accreditation, and the exact data requested with the rationale for its use.
- **Restricted scopes.** Google's overview says every Google Health API scope is Restricted and needs a privacy and security review for access.
- **Disclosure.** A dialogue box, or a series of them, covering nature, purpose and duration; risks and benefits; privacy, security and data handling; a point of contact; retention periods; how to withdraw; how to delete one's data through the study lifecycle; and anything else the board requires. Participants must be able to save, store or email it, and each must sign before participating. Google says to follow the FDA's "Use of Electronic Informed Consent Questions and Answers" or substantially similar standards.
- **Limited Use.** Use data only for its intended purpose, "Immediately de-identify participant data to the greatest extent possible", get separate informed consent for any new study unless the board explicitly waives it, and keep access need-to-know. Disclose a Limited Use statement in the app or on a website. Google's example reads: "The use of information received from Google Health API will adhere to the Google Health API User Data and Health Research Policy, including the Limited Use requirements."

## Devices and variables to check against your protocol

- **Devices.** Google says all Fitbit devices and Google Pixel watches, current and previous, collect data returned through the Google Health API, and the types available depend on what each device supports. The data-types page notes an exception: "Fitbit Ace devices are not supported by the Health API." A study with children enrolled on Ace devices needs a plan now.
- **Variables.** Google's [data-types table](https://developers.google.com/health/data-types) lists 44 data types, such as `steps`, `heart-rate` and `sleep`, each with its scope, webhook support, storage resolution and compatible devices. Storage resolution is the minimum interval at which data points are stored, for example 1 minute for steps. Google warns that the API "is actively evolving", so check every variable in your analysis plan against the table.
- **Missingness.** The "True zeros support" column marks types that can record an explicit zero, so an active zero, such as zero active minutes, is distinguishable from missing or unrecorded data. Code the two differently; see [storing a missing day versus a zero day](/architecture/missing-data-and-gaps).
- **Streams.** Google offers a Reconciled Stream that reconciles overlapping data from multiple sources, and a first-party stream of Fitbit and Pixel devices plus manual entries. Our recommendation: name yours in the data-management plan.

## Build your own integration or use a research platform

Our recommendation turns on four factors.

| Factor | Points toward building | Points toward a platform |
| --- | --- | --- |
| Engineering capacity | Engineers who can run Google OAuth, webhooks and the Restricted-scope review | Nobody on the team who can |
| Time | The work fits in the 18 days left as of October 12, 2026 | It does not fit |
| Participants | Few enough to walk through re-authorization one at a time | Too many to handle by hand |
| Platform status | Your platform has not finished its own move to the Google Health API | It confirms in writing that it has |

Ask any platform, in writing, whether it has completed its own move to the Google Health API and how it handles participant re-consent. The policy binds "Health Research Applications and Web Services", so a platform does not remove the study's own IRB and consent duties. Our [comparison of wearable research platforms](/fitness-apis/wearable-research-data-platforms) covers what Fitabase, Labfront, Empatica and Ametris document as of October 17, 2026, including Fitabase's published plan for its move to the Google Health API.

## The move, step by step

1. **Triage the roster.** For each participant still collecting data, record device model, legacy Fitbit user ID, collection end date, and whether they have signed in to the Google Health mobile app. Flag Ace devices. Google wants every user migrated as soon as possible, but in our reading a participant finishing before October 30 can be completed on the legacy API, which keeps operating, unsupported, until then. Pull and check their data before it stops.
2. **File the attestation and scope request.** Assemble the four attestation items and request only the scopes the protocol needs, in line with the Pledge's data minimization. File now, not after the engineering is done.
3. **Take the change to your board.** In our reading, a re-authorization campaign is new participant contact. Ask your IRB or ethics committee whether it needs an amendment and what participants must be told.
4. **Update consent and disclosure.** The policy requires confirming a participant's eligibility before obtaining informed consent and requesting access to their data, so screen first. Then check your consent documents against Google's disclosure list and add the Limited Use statement. If the study sets up participants' Google accounts, the Pledge says not to use their real name or email address and to default to the most privacy-protective settings.
5. **Map participant IDs before the first new sync.** `users.getIdentity` returns both `legacyUserId` and `healthUserId`. A legacy ID is a 6-character alphanumeric string and a `healthUserId` is "a string of up to 63 digits & characters", so check column widths. Our recommendation: keep the pair in the study's coded linkage table, away from the analysis dataset. [Mapping users to wearable accounts](/architecture/identity-and-account-linking) covers the account model.
6. **Run the re-authorization campaign.** Every participant must re-consent with a Google Account and sign in to the Google Health mobile app before you can sync their data. Until they sign in, calls return HTTP 400 with reason `ACCOUNT_NOT_LINKED`; Google says not to mark them connected and to keep their legacy connection and tokens. Completing Google Health authorization must automatically disable legacy syncing and revoke legacy tokens, so never dual-link anyone. [Keeping users connected during a migration](/migrate/keep-users-connected-during-migration) covers re-consent and migrating in waves.
7. **Plan for participants who miss October 30.** Google says their data stays available "as long as they continue syncing their device to the Google Health app" and can be backfilled once they re-authenticate, though you may have a gap. Ask them to keep syncing, log each gap window, and run [a resumable backfill job](/architecture/historical-backfill).
8. **Update the data-management and publication plans.** Record each participant's switch date and the stream you read, then apply the rules below.

Google's [migration guide](https://developers.google.com/health/migration) advises making re-consent mandatory only "after several weeks of warnings", never prompting mid-workout, and keeping a graceful recovery path after the cutoff. With 18 days left as of October 12, 2026, we would warn now and lean on that recovery path.

## Publication and prohibited uses

Google's policy says you "may not suggest that Fitbit approves of the study design, scientific validity of the research, or otherwise endorses the study findings unless provided in writing by Fitbit". It asks you to notify Fitbit for the Fitbit Publication Library, disclose the data source and prefer summary-level aggregate data. Publishing individual-level de-identified data calls for an accepted technique "like differential privacy" or an expert determination that re-identification risk is very small. The Pledge warns that some Fitbit information, like daily step counts, "may be publicly visible on Fitbit in accordance with users' privacy settings, or on social media". Google also recommends an NIH Certificate of Confidentiality.

The policy's examples of prohibited uses include ads, selling to data brokers or resellers, credit-worthiness or lending, and PHI uses without a valid HIPAA Authorization reviewed by an IRB or EC.

## Sources

- [developers.google.com/health/about](https://developers.google.com/health/about) — Rename to the Google Health API; September 30, 2026 end of support and October 30, 2026 turn-off; migrate as soon as possible; all scopes Restricted with a privacy and security review; device coverage; Reconciled Stream and first-party stream; API actively evolving. (checked 2026-10-12)
- [developers.google.com/health/migration](https://developers.google.com/health/migration) — Tokens cannot be transferred and users must re-consent; Google Health app sign-in and ACCOUNT_NOT_LINKED handling; no dual-linking; users.getIdentity with legacyUserId and healthUserId formats; data availability, gaps and backfill after re-authentication; re-consent timing, no mid-workout prompts, recovery path. (checked 2026-10-12)
- [developers.google.com/health/data-types](https://developers.google.com/health/data-types) — 44 data types with scope, webhook support, storage resolution and compatible devices; true zeros support; storage resolution example of 1 minute for steps; Fitbit Ace devices not supported. (checked 2026-10-12)
- [developers.google.com/health/policies/health-api-user-data-and-research-policy](https://developers.google.com/health/policies/health-api-user-data-and-research-policy) — Effective date; independent board review with the IRB and Ethics Committee citations; approval or waiver required; Health Research Applications and Web Services; deny or revoke; Health Research Attestation items; eligibility before consent; disclosure contents; FDA e-consent guidance; Limited Use and example statement; prohibited uses; NIH Certificate of Confidentiality; publication rules. (checked 2026-10-12)
- [developers.google.com/health/policies/health-api-research-pledge](https://developers.google.com/health/policies/health-api-research-pledge) — Effective date; data minimization; privacy-protective Google accounts for research subjects; public step-count re-identification warning. (checked 2026-10-12)

## FAQ

### What happens to a study participant's Fitbit data if they have not re-authorized by October 30, 2026?

Google says the data stays available as long as the participant keeps syncing their device to the Google Health app, but your dataset may have a gap for that person. Once they re-authenticate through the Google Health API, Google says you can backfill their historical data. Log each participant's gap window so you can check the backfilled records against it.

[Permalink](https://aifitnessapi.com/migrate/fitbit-research-studies-after-turndown#faq-1)

### What goes into Google's Health Research Attestation for a Fitbit study?

Google's research policy lists four items: a completed intake form, the IRB or ethics committee approval or waiver letter, the board's accreditation, and the exact data requested with the rationale for its use. Google also classifies every Google Health API scope as Restricted, which requires a privacy and security review. We have no verified processing time for either, so file early.

[Permalink](https://aifitnessapi.com/migrate/fitbit-research-studies-after-turndown#faq-2)

### Should a study team build its own Google Health API integration or use a research data platform?

Our recommendation is to build only if you already have engineers who can run Google OAuth, webhooks and the Restricted-scope review within the 18 days left as of October 12, 2026, and few enough participants to re-authorize one at a time. Otherwise use a platform, but only one that confirms in writing that it has completed its own move to the Google Health API and explains how it handles re-consent. Either way, a platform does not remove the study's own IRB and consent duties under Google's policy.

[Permalink](https://aifitnessapi.com/migrate/fitbit-research-studies-after-turndown#faq-3)

### Can a pediatric study keep collecting from Fitbit Ace devices through the Google Health API?

No. Google's data-types page notes that Fitbit Ace devices are not supported by the Health API, and Google says the Fitbit Web API stops functioning on October 30, 2026. We could not verify any other documented route for Ace data, so raise it with your IRB or ethics committee and your sponsor now.

[Permalink](https://aifitnessapi.com/migrate/fitbit-research-studies-after-turndown#faq-4)

### Do participants who already signed our consent form have to consent again for the Google Health API?

They at least have to re-authorize, because Google says existing Fitbit access and refresh tokens cannot be transferred, which requires users to re-consent. Whether your signed informed-consent document also needs revising is for your IRB or ethics committee to decide. Google's research policy lists what the participant disclosure must cover, so compare your current document against that list before you ask.

[Permalink](https://aifitnessapi.com/migrate/fitbit-research-studies-after-turndown#faq-5)