Can You Feed Wearable Data to an AI? Strava Says No, Garmin Says Yes, WHOOP Says Nothing

One of these six providers prohibits putting its data into a language model’s context window. One prohibits it for middleware companies and permits it for direct developers. One permits it, including for training, provided you publish a disclosure and collect explicit consent. The other three do not mention artificial intelligence anywhere in their terms.

If your product reads more than one of them, all of those rules apply to it at the same time.

That is the actual state of the licence layer under health AI as of 28 August 2026, and it is not what most roadmaps assume. The common assumption is that health data is health data, that the constraints are privacy constraints, and that what a model may do with it is a question about HIPAA or the AI Act. The binding constraint, for a growing number of teams, is a contract nobody reads until procurement asks for it.

The matrix

Three postures, six providers, and no two of the restrictive ones drawing the line in the same place.

Strava draws it hardest, and drew it first

The provider with the strictest AI terms in this set is not a wearable company, and it started nearly two years ago.

Strava announced on 15 November 2024 that its terms would “explicitly prohibit third parties from using any data obtained via Strava’s API in artificial intelligence models or similar applications” [6]. The same announcement contains a sentence worth keeping: Strava said its “previous terms already disallowed the use of Strava user data in model training and development” and that the change made this more explicit. Strava also estimated the changes would affect “less than .1% of applications.”

The current API Policy, effective 1 June 2026, is considerably broader. Section 5.3 reads:

You may not use the Strava API Materials or Strava Data, directly or indirectly, in connection with the development, training, evaluation, or operation of any AI Application.

The word doing the most work there is operation. A prohibition on training is one thing, and most teams building health features do not train anything. A prohibition on operation reaches the ordinary case: a user asks a question, your product puts their recent activities in front of a model, the model answers.

The enumerated activity list removes any doubt. It runs through “training, pre-training, post-training, fine-tuning, reinforcement learning, alignment, grounding, evaluation, benchmarking, embedding generation, retrieval-augmented generation, ingestion into a context window or working memory” [2].

Two neighbouring sections matter as much, and both are worth quoting in full rather than summarising, because the summaries understate them.

Section 5.4 reaches past AI entirely:

You may not process or disclose Strava Data, even publicly viewable Strava Data, including in an aggregated, de-identified, or anonymized manner, for the purposes of analytics, analyses, customer insight generation, or product or service improvements. You may not combine Strava Data with other customer data for these or any other purposes. The restrictions in this Section 5.4 apply to data derived from Strava Data and to output that incorporates or was generated using Strava Data.

Three things there that a multi-source health product should read twice. De-identification is no defence. Combining Strava Data with other customer data is prohibited outright, which describes the core operation of every aggregation platform. And the restriction follows through to “output that incorporates or was generated using Strava Data,” so a model response built partly on Strava rows is itself covered.

Section 5.16 then closes the structural route:

You may not, and may not authorize any third party to: (a) operate, offer, or facilitate any abstraction layer, integration-platform-as-a-service, no-code-AI platform, pass-through proxy, intermediary, or aggregator that re-exposes the Strava API Materials, in whole or in part, to third parties; (b) operate any MCP Server, agent-mediated interface, or analogous mechanism that exposes the Strava API Materials, Strava Data, or any subset thereof; (c) share, transfer, multiplex, or otherwise re-use API Tokens or authentication credentials across multiple servers, services, applications, or end users; or (d) build a Developer Application whose primary purpose is to enable third parties to access the Strava API Materials or Strava Data through your credentials or infrastructure.

That is an aggregator prohibition written in architectural language rather than in defined terms. It does not ask what kind of company you are. It asks what shape your integration is, and it names “no-code-AI platform,” “aggregator” and “any MCP Server” explicitly [2].

Oura splits it by who you are

Oura’s API and MCP Agreement, effective 8 June 2026, reaches a similar destination by a different route, and the route matters because it produces a different answer for different readers.

Section 2(a)(i) authorises a direct developer to access and process User Data “whether directly or through the use of another technology (including any AI Platform) to which you input or provide such User Data,” in the manner for which user consent was obtained [1]. That is an express permission for inference-time use, and it is the opposite of Strava’s position.

Section 2(c) then removes it for anyone who passes data onward:

no Aggregator shall relay, transmit, transfer, make available, disclose, distribute, redistribute, or otherwise provide or permit any Oura Data or User Data (or any data or information derived therefrom) to any AI Model, AI Platform, large language model, or other artificial intelligence or machine learning system, whether operated by such Aggregator, any End Customer, or any third party.

An Aggregator is defined as anyone, “including any User,” who obtains the data “through or in connection with the Oura API, the MCP Server, or any other means” and provides it, or anything derived from it, to a third party [1]. Company size is irrelevant. The trigger is onward provision.

Two details in that clause carry the weight. The End Customer language means a platform cannot solve the problem by handing data over and letting its customer take the AI step. “Derived therefrom” means the restriction is not limited to raw records: a score, a weekly summary, or a single boolean about whether recovery is trending down is information derived from Oura Data. Section 2(d) leaves one route out, a separate written agreement with Oura, which is a negotiation rather than a checkbox.

Then Section 4(a), which applies to every licensee rather than only to aggregators, adds twenty prohibited uses. Four bear on AI. Subsection (iii) prohibits training, fine-tuning, developing or improving any model “regardless of the training technique used,” and extends to “incorporating User Data, Oura Data, Oura Intellectual Property or Oura Confidential Information into any training dataset, evaluation dataset, or benchmark dataset.” Subsection (iv) prohibits “creating or modifying any AI Model weights, parameters, embeddings, or persistent representations.” Subsections (x) and (xx) prohibit retention beyond the agreement’s periods and “aggregating, caching, or storing” User Data [1].

Garmin permits it, and asks for paperwork

Garmin is the reason this piece cannot be written as a story about an industry closing ranks.

Section 15.10 of the Garmin Connect Developer Program Agreement contemplates AI use directly, and permits it:

Licensee’s Privacy Policy shall include a conspicuous artificial intelligence transparency statement (the “AI Transparency Statement”) if End User Data will be used for training with, or processing by, artificial intelligence systems.

The statement must “clearly inform End Users of the nature and purpose of any processing or training by artificial intelligence systems,” and must comply with applicable law “including mechanisms for (i) obtaining explicit consent from each End User before initiating any processing of End User Data; (ii) allowing End Users to withdraw such consent easily at any time; and (iii) updating to reflect changes in applicable laws, regulations, or Garmin policies” [3].

Note what is being permitted. Not merely inference: the clause says “used for training with, or processing by,” which contemplates the training case that Oura and Strava both prohibit outright.

It is a consent regime rather than a prohibition, and it has teeth. Section 15.7 requires the licensee, at Garmin’s reasonable request, to make available information necessary for Garmin to determine compliance with its obligations “including but not limited to the data protection requirements and the artificial intelligence transparency requirements” [3]. The AI transparency requirement is named as an auditable obligation.

The three that say nothing, and why that is not permission

WHOOP’s API Terms of Use contain no AI language. Searched term by term on 28 August 2026, the words artificial intelligence, AI, machine learning, model, training, embedding, LLM and inference do not appear anywhere. “Algorithm” appears once, at Section 3.1.10, in a reverse-engineering prohibition [4].

The Google Health API Developer and User Data Policy, effective 24 March 2026, likewise contains no AI clause. Its operative restriction is on “transferring or selling user data to third parties like advertising platforms, data brokers, or any information resellers even if aggregated or anonymized” [5].

Apple’s App Review Guidelines say nothing about models either. Guideline 5.1.3(i) prohibits using or disclosing health and fitness data to third parties “for advertising, marketing, or other use-based data mining purposes other than improving health management, or for the purpose of health research, and then only with permission,” and 5.1.2(vi) states that HealthKit data “may not be used for marketing, advertising or use-based data mining, including by third parties” [7].

Silence is genuinely different from prohibition, and it would be dishonest to present these three as restrictive when they are not. But treating silence as permission carries two specific risks.

General clauses can reach model pipelines anyway. “Use-based data mining, including by third parties” is not a defined term with settled scope in 2026, and a training corpus is not obviously outside it. “Transferring to third parties even if aggregated or anonymized” is broad enough to cover sending records to a model provider.

And silence is not stable. The most useful sentence in this entire research pass is Strava’s, from November 2024: its previous terms “already disallowed” model training, and the update merely made this explicit. That is a provider stating, in public, that the absence of an express AI clause never meant permission. Any of the three silent providers can take the same position about what your product has been doing since 2024.

Both restrictors kept the AI layer for themselves

The two providers that prohibit AI use of their data each wrote the same exception.

Strava’s Section 5.3 prohibition “does not extend to use of the Strava MCP” [2], and Section 5.16, which otherwise bars agent-mediated interfaces, carves out the official Strava MCP. Oura’s document is titled the API and MCP Agreement, bans aggregators from any AI use, and Oura ships Oura Advisor, its own AI coach, while Section 4(a)(ix) prohibits developing any product or service “that competes with or replicates the Oura Platform” [1].

So the restriction is narrower than it first appears. Neither company has concluded that language models and personal health data are a bad combination, because both are shipping exactly that combination. What the clauses do is confine it to a route the provider operates.

Whether that is competitive reservation or something more mundane, we cannot tell you, and the honest answer is that both readings fit. A provider that cannot audit what a third party does with its data downstream has a real liability and privacy interest in keeping model access to an interface it controls, and that explanation requires no strategic intent at all. What the drafting does establish, whatever the motive, is the outcome: the sanctioned path for a model to see this data runs through the provider’s own server.

This is the same move, one layer up, as the one we traced across six companies in what builds a moat in health data. The sensor stopped differentiating a decade ago. The interpretation layer is differentiating now, briefly, and the licence is the cheapest instrument available for defending it.

Samsung went and asked the users directly

The clearest version of the same move is not in a developer agreement at all.

In July 2026 Samsung Health users began seeing a toggle titled “Consent to the Use of Health Data for AI Training and Modelling” [8]. The categories it covers, per Samsung’s own documentation, are broad: body measurements, nutrition, step count and activity, and sleep; medication data “including prescriptions and dosages”; health records meaning “diagnoses, prognoses, test results, past records and treatments”; and cycle tracking data “including physical conditions and physiological indicators.” The stated purpose includes “human review, to improve Samsung Health, including algorithms” [8].

Declining it initially appeared to cost users their data sync, and Samsung clarified the following day that only data retained specifically to train AI is deleted on opt-out, with tracking functionality intact [8].

Set that beside the developer terms above and the shape of the market is hard to miss. The same providers narrowing or auditing what a third-party developer may do with health data are, in parallel, building the consent infrastructure to train on that data themselves. Oura and Strava reserved the inference layer through an MCP carve-out. Samsung reserved the training layer by asking its users for it.

None of that is improper, and user consent is the right mechanism. It is simply worth being clear-eyed that the restrictions in this post are not the industry deciding health data and AI should be kept apart. They are the industry deciding who gets to put them together.

What a fragmented matrix does to your architecture

The practical consequence is not a policy problem. It is a design problem, and it lands in the part of the system that assembles context.

A prompt is a single object. It either contains restricted data or it does not. If your coach builds one context window from every source a user has connected, then the narrowest clause among those sources governs the whole feature, because there is no meaningful sense in which the Strava rows in that prompt were treated differently from the WHOOP rows.

That leaves three workable designs, and one that does not work:

Filter by source before assembly. Every record carries provenance already, because you needed it for deduplication. The same metadata can gate which sources are eligible to enter a model context, per provider, per use. This is the only design that survives a matrix this fragmented, and it is not expensive if provenance is already there.

Split the feature by pathway. Data a user routed through HealthKit or Health Connect from their own phone arrives under Apple’s and Google’s rules rather than a device maker’s API agreement. That is a genuinely different licence, and neither platform mentions AI. It is not a loophole and it is not unencumbered, but it is a different document.

Negotiate. Oura’s Section 2(d) points at a separate written agreement. If AI over Oura cloud data is core to your roadmap and you are an aggregator, that conversation takes longer than the sprint in which someone notices the clause.

What does not work is a single global policy. “We do not train on user data” is the most common formulation, and it is now insufficient against at least two of these six documents, because neither Strava’s Section 5.3 nor Oura’s Section 4(a)(iv) is limited to training.

The pathway is the licence, not the brand

The unifying lesson is that teams reason about integrations as a list of logos, and the rules do not work that way.

The same resting heart rate can arrive under three different sets of terms depending on whether it came from a provider’s cloud API, from the platform health store on the user’s phone, or from your own SDK reading the sensor directly. Strava is the cleanest illustration in our own integration list: Strava writes activities into Apple Health and Health Connect, so an app reading them through the platform never touches the Strava API and is not a party to the API Policy at all.

We are not going to present that as a solved question, because it is not. Oura’s Aggregator definition reaches data obtained “through or in connection with the Oura API, the MCP Server, or any other means,” and that last phrase does not obviously stop at the API boundary for a company that also holds an Oura API agreement. Strava’s Section 5.16 restricts abstraction layers and pass-through proxies as structures, independent of which endpoint they call. A team operating both pathways should get an answer from counsel before shipping, not after.

Where we sit

Sahha is an Aggregator under Oura’s definition. We obtain data and provide it to our customers, which is the entire product, so Section 2(c) constrains us in exactly the way it constrains everyone else in that position. If you are building an AI feature over Oura cloud data through any middleware, including ours, the self-serve path under the current agreement does not authorise it, and the route is a separate written agreement with Oura.

Four connections in our integration list run against a provider’s cloud API: Oura, WHOOP, Garmin and Dexcom [9]. Everything else, including Strava, reads data the user has already routed into HealthKit or Health Connect on their own device. That is a different pathway carrying a different document, which is a real distinction and a narrower one than a marketing page would make of it. It does not make the data unencumbered. It makes it encumbered by Apple’s and Google’s rules instead, which say nothing about AI today and are not promised to stay that way.

We went looking for this answer for our own roadmap, found that four of the six documents had changed inside eighteen months, and found that nobody had put them side by side.

The short version

Strava prohibits AI use of its data including at inference, and has since November 2024. Oura prohibits it for aggregators including where the customer runs the model, permits it for direct developers at inference, and prohibits training and embeddings for everyone. Garmin permits both processing and training with a published disclosure, explicit consent and an audit right. WHOOP, the Google Health API and Apple’s HealthKit rules say nothing about AI, which is not the same as permitting it, on Strava’s own account of its pre-2024 terms.

Both providers that restrict AI exempted their own MCP servers.

If you read more than one source into a single context window, the narrowest of these governs your architecture, and none of it is discoverable from an API reference.