Google Fit, Fitbit, Strava and Garmin Changed Their APIs Since 2024. Plan for the Next Health API Shutdown

On 30 October the Fitbit Web API stops working. Any app that has not moved to the Google Health API, which needs every user to consent again, stops receiving those users’ data [4][7]. It is the latest in a run: since May 2024, Google Fit closed to new developers and is being deprecated, WHOOP moved to a new API version, Samsung deprecated its Android SDK, Strava rebuilt its developer program and Garmin paused new applications [1][2][3][5][6].

None of these is a scandal on its own. Platforms change for good reasons: security, privacy, AI scraping, consolidation. Taken together, though, they say something every team building on health data should plan for. Every integration you have will change again, usually on someone else’s schedule, and what that costs you is decided by architecture choices made long before the change arrives.

What changed, and when?

There is precedent. Microsoft announced in April 2019 that HealthVault would close, and on 20 November 2019 it shut down and deleted the data in it; third-party apps built on it simply stopped [8].

How much notice did developers get?

The range is the point. A team can get two and a half years to plan, or wake up to a rule that already applies:

• Same day. Strava’s end of support for apps routing data through intermediaries took effect on the day it was announced, and Garmin’s pause applied immediately to anyone not already in [5][6].
• Weeks to months. Strava gave existing developers 29 days to subscribe and about three months before removing club endpoints [5]. The Fitbit Web API turns off about seven months after its replacement launched, and Google moved the date once, from 30 September to 30 October [4][7].
• Years. Google closed Google Fit to new developers in May 2024 and says its APIs will be deprecated in 2026, without giving a calendar day for the shutdown [1].

You cannot plan around a notice period you do not get. You can plan around the certainty that one will come.

What did the changes cost existing apps?

The same five costs show up again and again:

1. Rewrites. New endpoints, new schemas, new identifiers. WHOOP changed sleep and workout IDs to UUIDs; the Google Health API brings a new console, OAuth, data types, endpoint schema and response format [2][7].
2. New gatekeeping. Every Google Health API scope is restricted and needs a security review; Strava reviews any app beyond 10 athletes; Garmin is not accepting new applicants at all [5][6][7]. Even the Google Health API paused new project onboarding while it expanded access [4].
3. Re-consent. Fitbit tokens do not carry over, so every connected user has to approve the app again before 30 October [7]. Users who never see or act on the prompt are lost.
4. Tighter terms. Strava now bans AI use of its data, including in prompts, and limits caching to seven days; Oura restricts AI use for aggregators [5][9]. A terms change can break a product without touching its code.
5. Features with no replacement. Some Google Fit APIs have no successor, and Strava removed club endpoints outright [1][5].

We covered several of these in depth: the Fitbit migration, Google Fit’s end, Garmin’s pause, Strava’s changes and AI restrictions across providers.

Why do platforms keep changing the rules?

• Consolidation. Google is folding Fitbit and Google Fit into one Google Health stack [4].
• Security and privacy. Restricted scopes and security reviews follow from health data’s sensitivity [7].
• AI. Strava cited AI scraping and intermediaries abusing its API; Oura wrote AI restrictions into its agreement [5][9].
• Commercial control. Health data underpins subscriptions and, for Strava and Oura, IPO stories. Platforms want to know who is using it and how [5].

None of these pressures is going away, so the safest assumption is that every integration you have will change again.

Seven rules for surviving the next change

1. Own your schema. Map every source into one internal model with one adapter per provider, so a provider change is a contained project, not a rewrite. See normalizing wearable data across providers.
2. Track consent per user and per source. When re-consent comes, you need to know exactly who to ask, through which channel, and who has answered.
3. Keep provenance, and history where the terms allow. Store the source, device and version with every value. Keep raw history if your terms permit it, and know where they do not: Strava caps caching at seven days [5].
4. Monitor freshness per source. A silent provider change shows up first as data that stops arriving. Alert on it per user and per source.
5. Read changelogs and terms, not just docs. Assign an owner to every provider’s changelog, developer forum and policy page. Terms changes are as breaking as API changes.
6. Prefer on-device stores where they cover your needs. Apple Health and Health Connect sit under many sources at once and do not need a developer account per brand, though they have their own limits on history, background access and detail. See why wearable data is late.
7. Budget integrations as recurring work. Every provider integration has a maintenance cost every year. Put it in the plan, or buy it from someone who does; our build vs buy guide breaks down the cost.

The short version

Between May 2024 and October 2026, Google Fit, WHOOP, Samsung, Fitbit, Strava and Garmin all changed their APIs or developer terms [1][2][3][4][5][6]. Notice ranged from none to about two and a half years, and the costs repeated: rewrites, new reviews, re-consent, tighter terms and lost features. Apple’s HealthKit is the stable exception, not a frozen one [10]. Products that own their schema, track consent per source, monitor freshness and budget for maintenance will treat the next change as routine.