Garmin's Developer Program Is Paused: What It Means for Your Roadmap

If Garmin is anywhere on your wearables integration roadmap right now, you've probably already run into this: the Garmin developer program isn't accepting new applications. There's no application form to submit and no published timeline for when that changes.

This is a narrower problem than it first looks, and getting the scope right matters before you change any plans. Garmin runs two separate developer programs, and only one of them is affected. We've also heard the same story independently from several teams building wearable-data products, which suggests this isn't an isolated account getting rejected. It's a structural pause on the acquisition side of Garmin's developer program.

This piece covers what's actually closed, what's still open, why the distinction matters for planning, and what teams are doing instead of waiting.

What's Actually Closed in the Garmin Developer Program

The affected program is the Garmin Connect Developer Program, sometimes called the Garmin Connect Developer Program APIs (GCDP). This is the layer that exposes structured health and activity data: steps, heart rate, sleep, workouts, the kind of data a wearables integration actually needs to build features on top of.

According to a reply from the Garmin Connect Developer Program team on Garmin's own developer forums, the application form for new partners has been removed, and new API access requests are paused with no projected reopening date. There's no waitlist or notification list either; Garmin's guidance is to monitor developer.garmin.com directly for updates. Garmin's official program FAQ doesn't go quite that far in its own wording, currently saying only to "stay tuned for more updates on the program," so treat this as a strongly corroborated, current-as-of-writing status rather than a permanent policy announcement from Garmin's press office. Check developer.garmin.com yourself before making a roadmap decision that depends on this.

What's Still Open: Connect IQ vs. the Garmin Developer Program

Connect IQ is a separate program, and it isn't affected by this pause. Connect IQ covers watch faces, data fields, widgets, and applications that run on the device itself, built with Garmin's SDK. If your use case is an on-watch app or a custom data field, that path remains open regardless of what happens with the Developer Program APIs.

The distinction matters because it's easy to see "Garmin developer program" and assume the whole platform locked its doors, when what's actually closed is narrower: specifically the pipe that gets structured health and activity data off the device and into your backend. If your roadmap needs that data pipe rather than an on-device app, the Connect IQ program doesn't help you, and that's the gap this article is actually about.

Why This Is a Real Roadmap Problem, Not a Minor Inconvenience

We keep hearing versions of the same story from teams building wearable-data products: Garmin support is on the roadmap, sometimes already committed to a customer or investor, and there's no application path left to get it. Our piece on why mobile health apps struggle with wearable integrations goes into how fragmented and provider-specific this kind of integration work already is even when access isn't the blocker. Losing the ability to even start the application makes that fragmentation worse, not because the technical work changed, but because the starting gate did.

Garmin is a large share of the fitness and endurance-sport wearable market, which is exactly the segment most likely to have Garmin users asking for support. A product that can't add Garmin is stuck at step zero, waiting on a form that no longer exists, regardless of how well the rest of the integration is executed.

What Teams Are Doing Instead of Waiting

There isn't a way around Garmin's own pause for a team's own integration: existing Garmin connections keep working, and the freeze only blocks new applications. What teams stuck at the application stage are actually doing is building out every other provider first, so the rest of the wearables roadmap doesn't sit idle while Garmin's queue is closed.

Open Wearables is built provider-agnostic for exactly this kind of gap. Apple Health, Whoop, Oura, and the rest of a product's wearable roadmap can be built and shipped now, independent of where a Garmin application sits in the queue. When Garmin clears that application, the same self-hosted layer picks up the Garmin connection without re-architecting anything, since each deployment applies for and uses its own Garmin developer credentials the same way a direct integration would.

Momentum can help with the Garmin application itself, since the process isn't always straightforward, and build the rest of the integration in parallel so a team is ready to flip the switch the moment access clears, rather than starting from zero once it does. Our Open Wearables FAQ on avoiding vendor lock-in covers the broader mechanics of why a provider-agnostic, self-hosted layer keeps a product from depending on any single vendor's roadmap decisions.

What This Means for Planning

If Garmin isn't on your roadmap yet, this changes the calculus on when to add it. Providers whose developer programs are currently open won't necessarily stay that way, and the lesson from Garmin's pause is that access itself is a planning risk, not just a technical integration cost. Our cost analysis of wearables integration covers the engineering side of that calculus; access risk is the part that doesn't show up in an engineering estimate at all.

If Garmin is already committed on your roadmap, the honest path is to build the rest of the integration now and let Garmin slot in once your own application clears, rather than waiting to start the whole project until Garmin is unblocked. We wrote about the broader version of this problem, teams outgrowing what a single vendor relationship can give them, in why teams outgrow SaaS wearable APIs. Garmin's pause is a sharper version of the same underlying issue: when your product's access to a provider depends entirely on one vendor's application queue, that queue closing is entirely out of your control.

If Garmin Is on Your Roadmap Right Now

If you're weighing what a closed application means for a Garmin feature already on the timeline, it's worth a short conversation before you write off the date entirely. Get in touch and we'll walk through the options, including how a wearables integration engagement can get the rest of your integration built and ready while your own Garmin application is pending.