Health Data Has Four Authorization Models, and a Cross-Platform App Is Usually Running Three

“We support wearables” is usually scoped as one integration. It is four authorization models that do not share a consent UI, a failure mode, or a path to your server.

HealthKit puts a system sheet on the iPhone and will not tell you whether the user denied a read [1]. Health Connect puts a runtime grant on Android and, by default, will not let you read further back than thirty days from that grant [2]. Oura and WHOOP use OAuth 2.0, so a backend can pull, and a revoked token at least returns 401 [3] [4]. Garmin’s Health API is OAuth too, but only after Garmin has admitted you to a partner program that is currently telling new applicants to stay tuned [5].

A cross-platform coaching app is typically running HealthKit, Health Connect, and one OAuth cloud at once. The partner-program cell is the one that closed.

This is the map. The deep dives sit underneath it: what still works now that Garmin paused new API access, why a web app cannot read Apple Health, and why App Review rejects HealthKit apps.

The four models

Oura and WHOOP sit in the OAuth column because a backend can pull after consent. They still have a partner-program admission step — ten users until production approval — which is why the licence layer and the permission layer are different conversations.

Two facts fall out of that table immediately.

A server cannot OAuth against Apple Watch. There is no HealthKit REST API [6]. The Watch writes to the phone; the phone’s HealthKit store is readable only by an app running on that phone with a granted type. If your architecture is a Next.js app with a webhook and no iOS binary, Apple Watch is not a source. Capacitor does not create a web API; it creates a native app that happens to render HTML.

OAuth is not the general case. It is the case for vendors who published a cloud and still let you in. That set is smaller than the device list on a marketing page, and it moves: Fitbit’s Web API sunsets in September 2026, Google Fit’s REST API ends with 2026, and Garmin’s program is paused for new applicants.

HealthKit: consent on the phone, silence on the read

HealthKit is a framework on iOS, iPadOS, watchOS and visionOS [6]. You add the HealthKit capability, you set NSHealthShareUsageDescription (and NSHealthUpdateUsageDescription if you write), you call requestAuthorization(toShare:read:), and the system presents a sheet listing every type you asked for.

Three properties of that sheet decide architecture.

Read denial is invisible. authorizationStatus(for:) reports whether your app may save a type. It does not report whether the user allowed a read. Apple’s privacy design is that revealing a denied read would itself leak information. You query; you get samples or an empty array; empty is also what you get when the user has no Apple Watch, or did not wear it, or had a quiet day [1] [7]. Provenance (HKSourceRevision, HKDevice) tells you who wrote a sample. It does not tell you why nothing was written. We unpacked the hardware split in Apple Health without an Apple Watch.

The grant is to your app, not your company. A backend never holds a HealthKit token. Background delivery, which is how you sync without the user opening the app, requires the com.apple.developer.healthkit.background-delivery entitlement on iOS 15 and later; without it, enableBackgroundDelivery fails with authorization denied [8]. If you do not call the observer-query completion handler, HealthKit backs off and, after three failures, stops sending background updates [14].

App Review sits on this model. Guideline 2.5.1 requires HealthKit to be used for health and fitness purposes and to integrate with the Health app. Guidelines 5.1.2(vi) and 5.1.3(i) prohibit using that data for advertising, marketing, or use-based data mining, including by third parties [9]. The review post is the field guide; the architectural point here is that choosing HealthKit is choosing Apple’s privacy regime, not just Apple’s sensors.

Health Connect: consent on the phone, extra permissions beside the types

Health Connect is the on-device store on Android [10]. From Android 14 it is a framework module; on 13 and lower it is a Play Store app. You declare each type in the manifest, you declare the same set in the Play Console Health apps form, and you request runtime permission. Google’s permission APIs will tell you what was granted, which is the first material difference from HealthKit.

The second is the extras.

History is a separate permission. By default an app can read data for up to 30 days prior to when any permission was first granted. PERMISSION_READ_HEALTH_DATA_HISTORY lifts that. Without it, reading older records errors. Reinstalling the app revokes permissions and restarts the clock from the new grant [2]. We covered the step-counting version of this in Health Connect without a wearable.

Background is a separate permission. PERMISSION_READ_HEALTH_DATA_IN_BACKGROUND is required to read after the user or the system has backgrounded you. Decline it and you have a foreground-only integration that looks like a passive one in the spec.

The 30-day history window is not the 30-day change-token window. Incremental sync uses getChangesToken / getChanges. Those tokens expire about a month after they are issued; an expired token is a full resync, not a denied permission [15]. Teams that treat “30 days” as one number mix a consent rule with a cursor lifetime.

The server still cannot pull. Health Connect has no OAuth. Google’s cloud path is the Google Health API, which is account-centric, uses Restricted scopes, and documents Fitbit and Pixel hardware. Do not assume it returns a Samsung or Garmin watch that wrote into Health Connect on the phone.

OAuth cloud: the model everyone wishes they had

Oura, WHOOP, Withings, and Fitbit-via-Google expose cloud APIs. The user signs in at the vendor, your backend receives an authorization code, you store a refresh token, you pull or subscribe to webhooks. A revoked grant fails as an HTTP error. That is why this model dominates architecture diagrams drawn before anyone has shipped on iOS.

It has its own gates.

Oura caps a new application at ten users until Oura approves it for production, and Gen3 and later users without an active Oura Membership cannot be read through the API at all [3]. WHOOP is similar: development is limited to ten members; a public launch requires App approval [4]. Those are partner-program dynamics wearing OAuth clothing.

The licence layer is not the permission layer. Strava’s API Policy prohibits putting Strava data into a context window. Oura splits aggregator vs direct developer. Garmin (for those already in) permits AI processing subject to a disclosure and consent regime. We quoted those documents in Can you feed wearable data to an AI?. An OAuth grant is not a licence to do whatever your product does with the payload.

Coverage is the users who connected that cloud, not the users who own a watch. An Apple Watch user has nothing to OAuth against unless they also have Oura or WHOOP. A Garmin user has a cloud, but you may not be allowed to call it.

Partner program: OAuth behind a door that can close

Garmin’s Connect Developer Program is the clean example, because it is five APIs behind one application: Health, Activity, Women’s Health inbound; Training and Courses outbound [5]. The Health API is REST, ping/pull or push, JSON summaries after the user syncs to Garmin Connect [11]. None of that is available until Garmin has issued you credentials.

As of this writing, the public program pages lead with “Stay tuned for more updates on the program” [5]. Applicants posting Garmin’s reply on the developer forums have been told new API access requests are paused, with no timeline [12]. Existing partners keep working. Connect IQ, which builds watch faces and on-device apps, is a different program and is still shipping — 9.2.0 went out on 25 August 2026 [13].

The architectural fact is independent of this particular pause. A partner program is an authorization model whose first failure mode is you never get in. You cannot retry it in code. You cannot A/B it. You put it on a critical path only if you have a fallback that does not need it. For Garmin, that fallback is whatever Connect writes into Health Connect and Apple Health, plus the phone, which is a different and thinner payload. The Garmin post is the current state of those paths.

Other vendors run quieter versions of the same gate: Oura’s production review, WHOOP’s App approval, Dexcom’s partner process, the Google Health API’s Restricted-scope security review. If your roadmap says “we’ll add X once we get API access,” you have a partner-program dependency, even if the word Garmin never appears.

Which model actually covers the user

The Watch-versus-phone type split is Apple Health without an Apple Watch. Pixel via the Google Health API is still not a Galaxy Watch that only wrote into Health Connect.

What a real architecture does

A product that spans iPhone, Android, and a couple of premium wearables is not choosing one row of the first table. It is running:

1. A native iOS surface (your app or an SDK inside it) that requests HealthKit types, handles empty reads as ambiguous, and uploads. Background delivery entitlement on, observer queries registered at launch, completion handler called on every path.
2. A native Android surface that requests Health Connect types and history and background, persists a change token, and degrades when any of the three is declined or the token has expired.
3. OAuth clients for the clouds you can actually enter, with token refresh, webhook verification, and a source filter before anything hits a model, because the licences disagree.
4. A partner-program queue treated as a lead time, not a sprint task, with an explicit product for users who never get that source.

The silent-failure row is the one to design first. HealthKit empty, Health Connect revocation, and a watch left in a drawer are indistinguishable from a user who stopped moving unless you have another signal. Cloud 401s at least throw. Partner-program silence does not even produce a user.

There are two structural answers, and both are defensible. Keep each source a thin module behind your own types, so the next closed form is a contained project. Or put the class of problem below an abstraction layer such as Sahha, which still has to obtain the same four grants — it does not invent a fifth — but presents one schema and one webhook to the product. What does not work is drawing a single OAuth box and labelling it “wearables.”