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.

The Workaround Teams Are Actually Using

The practical path we're seeing work is routing Garmin data access through a party that already holds an active Garmin developer relationship, instead of waiting on a new application to open. This usually means one of two shapes: a self-hosted wearable data layer whose operator already has Garmin developer credentials, or a services partner running your product's Garmin connection under their existing account with Garmin's sign-off.

This isn't a loophole. Garmin's developer terms already contemplate third parties building on behalf of a client, and the mechanics look similar to how OAuth works across a multi-wearables app: the end user still authorizes their own Garmin account, the data still flows under Garmin's terms, the only thing that changes is whose developer credentials the connection runs through.

This is where a self-hosted model like Open Wearables plays out differently than it might first seem. Momentum doesn't hold a shared Garmin relationship that customers route through: each deployment applies for and uses its own Garmin developer credentials, the same as any direct integration would. What that ownership does buy a team is control over the timeline, since the infrastructure and the rest of the provider integrations can be built and ready to go the moment a Garmin application clears, rather than waiting on a vendor's own release schedule on top of Garmin's. Our Open Wearables FAQ on avoiding vendor lock-in covers the broader mechanics of why self-hosting 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 options are: wait with no defined timeline, or route the connection through a party that already has access. 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.