Garmin Paused Its Developer Program. Here's How Apps Still Get Garmin Data

Garmin’s Connect Developer Program is the cloud door to Health, Activity, Women’s Health, Training and Courses. As of 17 September 2026 that door is not taking new names.

The public pages lead with one line: “Stay tuned for more updates on the program” [1] [2]. The application form for new partners is not a working path. Developers posting Garmin’s email on the forums have been quoting the same paragraph:

We are currently evolving and modernizing the Garmin Connect Developer Program. During this transition, we have temporarily paused the review and approval of new API access requests. We appreciate your understanding as this work continues. At this time, we are unable to provide a specific timeline for when new application processing will resume. We will share additional updates as they become available. [3]

Existing partners keep working. Connect IQ is a different program and is still shipping. The Health API has not been deprecated. What has stopped is admission.

If your Q4 plan was “we’ll get Garmin API access and then personalize training,” that plan is now a bet on a reopen date Garmin has declined to set. This is what still works, what each fallback actually returns, and what an aggregator can and cannot do about it.

The authorization taxonomy this sits inside — HealthKit, Health Connect, OAuth, partner programs — is in four authorization models.

What is actually known

The program, when it is open, is one application covering five APIs [1]:

• Health API — all-day summaries: heart rate, sleep, steps, stress, pulse ox, body composition, respiration, Body Battery, and related types, as JSON, after the user syncs to Garmin Connect. Ping/pull or push [2].
• Activity API — full activity files across Garmin’s activity types.
• Women’s Health API — cycle and pregnancy information Garmin collects.
• Training API — push structured workouts and plans to the watch.
• Courses API — push courses to the device.

A coaching product usually wanted at least Health inbound and Training outbound. Both sit behind the same closed form.

Four things this is not

It is not a deprecation. Garmin has not announced a turndown of the Health API. Compare Fitbit’s Web API, which has a September 2026 date and tokens that do not transfer, and Google Fit REST, which ends with 2026. Those are sunsets. This is an admissions freeze.

It is not Connect IQ. Connect IQ builds software that runs on the watch: watch faces, data fields, widgets, device apps, audio content providers. It can use device sensors, FIT recording, BLE to a phone, and OAuth to a web service [5]. That is a viable product for an on-watch experience. It is not a replacement for server-side daily HRV and sleep summaries, and it is not a way to push a Training API workout plan into Connect.

It is not “Garmin data is unavailable.” Users still sync to Connect. Connect still writes a subset of that data into Apple Health and Health Connect when the user enables it. Your app can still read those stores if you have a native integration. You do not get the Health API payload from that.

It is not a problem an aggregator magically dissolves. See below.

What still reaches your app

1. Health Connect, if the user enabled Garmin there

On Android, Garmin Connect can write into Health Connect. Google’s own Health app help lists Garmin watches as a Health Connect source, with the user syncing the watch to Garmin Connect first [11]. Third-party setup guides put the native write on Android 14+ and a recent Connect version, toggled at Connect → Settings → Connected Apps → Health Connect [12]. Confirm on the device in front of you rather than on a version number in a blog.

Your app then reads Health Connect under Android’s runtime permission model, including the 30-day default history window and the separate background-read permission [6]. You get types Health Connect knows about — steps, heart rate, sleep sessions, exercise sessions — not Garmin composites (Body Battery, Training Readiness, Training Load) that never leave Connect. The write is one-way: Connect does not read Health Connect back.

You need an installed Android app. A backend cannot pull Health Connect.

2. Apple Health, if the user enabled Garmin there

Garmin documents sharing Connect data with Apple Health [7]. The write is initiated from Garmin Connect, one-way into HealthKit. Your iOS app then reads HealthKit, with all of HealthKit’s properties: per-type sheet, read denial indistinguishable from empty, background delivery entitlement [8].

What actually lands is whatever Connect offers in that Connected Apps screen on that day. Do not spec Body Battery, Training Readiness, HRV Status, Garmin’s sleep score, or workout GPS off this path. Confirm on a device: Health app → Apps → Garmin Connect. Third-party inventories of the native sync have been consistent that the composites stay in Connect [9]; they are not a substitute for Garmin’s own list.

3. The phone, for users who have no Garmin at all

Most of a general-population user base will not own a Garmin, or will not connect it. Phone motion still produces steps, distance, flights, and — with the right modelling — sleep timing rather than stages. That is a different payload from overnight HRV, and it is the payload you can ship without a partner program. Smartphone versus wearable adoption is the coverage math; sleep stages without a wearable is the honesty about stages.

4. Direct Health API, if you are already a partner

If Garmin already issued you a consumer key, nothing in the public pause language takes it away. Keep the integration. Do not assume a second app, a new legal entity, or a contractor can get a second key while the form is gone.

What an aggregator can actually do

Wearable APIs sit in two credential models.

The aggregator is the Garmin partner. Users OAuth into the aggregator’s Garmin application. The aggregator’s existing credentials keep working through a pause of new applications, in the same way yours would. You never see a consumer key. The consent screen is theirs, or a white-label of theirs, depending on the contract.

You are the Garmin partner. You register a Garmin application so your brand is on the consent screen and the rate limits are yours, then you paste the consumer key into the aggregator’s dashboard. That is Sahha’s documented Garmin setup today [10]. It is also how several “bring your own credentials” pipelines are sold.

The second model cannot mint a key Garmin is not issuing. If a vendor’s onboarding still says “request Garmin Health API access, then paste the key here,” they are not a workaround for this pause. They are the same queue.

Ask, in writing: Do we need our own Garmin Connect Developer Program app, or do we ride on yours? If the answer is yours, and you do not have one, this path is closed until Garmin says otherwise.

The payload gap, in one table

The rows that hurt coaching products are the composites and the Training API. Those are exactly the rows that have no fallback. If pushing structured workouts to the watch was the feature, Connect IQ can run something on-device; it cannot replace the Training API’s cloud-to-watch plan push. That feature is paused for anyone not already a partner.

Confirm the write actually landed

Do this on a real phone, not from a spec:

• iPhone: Health → Apps → Garmin Connect. The types listed are what your HealthKit queries can see. If Garmin Connect is missing, the user never enabled the write.
• Android: Health Connect → App permissions → Garmin Connect, or Connect → Settings → Connected Apps → Health Connect. Same test: no Garmin row, no Garmin samples.
• Independence: the iPhone toggle does not enable the Android write, and the reverse. A user who switched phones has to grant again.

Third-party inventories of which composites stay in Connect are a hint [9]. The screen in front of you is the spec.

What to do this week

1. Open developer.garmin.com/gc-developer-program/overview. If stay-tuned is still the headline, take new Health API work off this sprint.
2. Inventory who on your team already has partner credentials. That person is now a single point of failure, not an onboarding step.
3. Ask every aggregator in your shortlist the credential question above. Discard the ones that require a key you cannot obtain.
4. Ship Health Connect and HealthKit reads anyway. They are the on-device stores for more than Garmin, and they are the only Garmin-adjacent path that does not need Garmin’s form. See HealthKit versus Health Connect.
5. Decide, explicitly, what the product does for a user whose Garmin never appears. If the answer is “nothing,” you have placed a hardware-plus-partner-program requirement on the user without saying so.
6. Watch the same URL. Garmin has told applicants there is no notification list [4].

A health data layer such as Sahha still has to live inside these constraints: we document bringing your own Garmin app for the cloud path, so we cannot honestly sell that path as a bypass of a freeze we are in ourselves. What we can do, and what any competent on-device integration can do, is keep reading HealthKit and Health Connect — including whatever Garmin wrote there — and keep producing a signal from the phone when nobody wrote anything. That is a coverage strategy, not a Garmin API.

The honest Q4 plan is the on-device stores, the phone, and a calendar reminder aimed at a page that currently says stay tuned.