Your Aggregator Wants Your Own Garmin API Key: What to Decide Next

Introduction

If your product gets Garmin data through a SaaS aggregator, the email may already be in your inbox: from a set date, the vendor needs you to bring your own Garmin API credentials. The notice follows Garmin's decision on 21 October 2026 to reopen its Connect Developer Program. It moves the relationship with Garmin from your vendor to your company.

Our overview of the reopened program covers what Garmin changed for health product teams in general. This article is for the team on the receiving end of the vendor's notice. It covers what the notice means for your product and which questions to put to your vendor before the deadline. The second half compares the two paths open to you, with what each one takes.

What Changed for Teams Using the Garmin API Through an Intermediary

Garmin now runs three tiers. Personal is for pulling your own data. The business tiers differ in delivery and scale: Starter delivers data by push only and has no historical data. Its number of users is capped. Enterprise adds ping/pull delivery and at least a month of history. It has no user cap and includes support, on terms Garmin sets with each company.

Garmin's program page lists no prices. Press reports put the Starter cap at 1,000 users and say Enterprise will be billed per monthly active user from April 2027, with existing partners moved to Enterprise automatically (DC Rainmaker).

The rule that matters most for aggregator customers sits in the developer agreement. Section 5.2(e) says a licensee needs Garmin's prior written permission to share or sublicense its license key. The same applies to giving anyone else access to the API. Platforms that served many apps through one shared registration are now asking their customers to register their own.

The clause itself predates the reopening: it appears in the same wording in the 2023 version of the developer agreement. The reopened program gives every company a clear route to its own key, which makes the shared model hard to keep. Strava took the same line earlier. Since June 2026 its API agreement bars developers from sharing an API token with a third party. It also bars using one token for more than one application.

What the Notice Means for Your Product

The vendor's switch date is the date your Garmin data stops arriving under the old registration. Treat it as a product deadline with four pieces of work behind it.

Your own Garmin application. You apply to the Garmin Connect Developer Program under your company's name. Press coverage says Starter applicants need a public website and a privacy policy. New Starter apps carry an unverified label until Garmin reviews them. Until then, new connections may be limited (the5krunner). Build that review time into the plan.

Your users' consent. Garmin users authorize each app separately. When the connection moves to your own app, every user connects their Garmin account once more. That needs an in-app prompt and a message for users who rarely open the app. Plan as well for the ones who never reconnect. Our article on OAuth across multiple wearables covers how that flow usually works.

Your contract. The agreement with your vendor was priced for a service that included Garmin access. Once the Garmin relationship is yours, check what the contract still covers and whether the price reflects that.

Your AI features. If your product uses Garmin data with AI, read the AI terms in the version of the developer agreement you accept. The March 2026 version asks for an AI transparency statement in your privacy policy when user data is used for training with AI or processed by it. Check the details with your counsel before the switch.

Questions to Ask Your Current Vendor

Most of these can be answered in one call. The answers decide which path makes sense.

1. From what date will you support our own Garmin credentials?

2. Who builds the reconnection flow when our users have to connect again?

3. What happens to historical Garmin data already collected under the shared registration?

4. Do our contract and price change once the Garmin relationship moves to us?

5. Who can access our users' Garmin data while it passes through your systems?

6. If another device maker adopts the same rule, how quickly can you follow?

Two Paths After You Get Your Own Garmin API Key

Both paths start the same way. You apply to Garmin and register your app under your company's name. The difference is where the integration runs once you have them.

Keep Your Current Vendor With Your Own Credentials

If the vendor supports customer credentials and the rest of its service still fits your product, this is the shortest route. Your team handles the Garmin application and the user reconnection. The vendor keeps running the integration. Garmin data still passes through the vendor's infrastructure before it reaches yours. The next change in a provider's rules will also reach you through the vendor's roadmap.

Run a Self-Hosted Garmin API Integration

The other path puts the integration in your own cloud. Garmin pushes data straight to a callback endpoint you host, so the data goes from Garmin straight to infrastructure you control. That simplifies HIPAA and GDPR questions about where health data is processed. It also means your team runs the service or works with a partner who does. Our article on data ownership in wearable health products goes deeper into what that ownership involves.

The right choice depends on how central wearable data is to your product. A team that uses Garmin data for one feature may be well served by the first path. A team whose product is built on wearable data usually wants the connection in its own hands.

What Moving to Open Wearables Involves

Open Wearables is an open-source platform, MIT licensed, that brings data from multiple wearables behind one API you run yourself. Each company deploys it in its own cloud and connects it to its own Garmin app. Garmin credentials are configuration in your deployment, so moving to your own app means changing keys. Your keys and your users' data stay in your deployment; Momentum has access only if you grant it.

Open Wearables does not grant Garmin access and does not replace Garmin's approval. You apply to Garmin yourself. Open Wearables is the software that runs your approved connection next to the other wearables your users connect, in one normalized data model.

For most teams the move off an aggregator is a re-integration. You deploy Open Wearables with your Garmin app connected and point your product at the new API. Users reconnect through your own consent flow. Our step-by-step migration guide walks through the technical stages from audit to cutover. The guide on adding a wearable API to an existing backend covers the integration side. The Open Wearables migration page summarizes the steps.

Open Wearables already runs in production. Heart Monitor, with around 90,000 monthly active users, adopted the open-source project and built its integration with its own team. User health data stays on Heart Monitor's own infrastructure.

Garmin is the latest provider to change its terms, after the Fitbit Web API deprecation. When your team owns the connection, it decides how to respond to the next change. More answers on the self-hosted model are in the Open Wearables FAQ on avoiding vendor lock-in.

How Momentum Supports the Move

Momentum builds and maintains Open Wearables. For teams moving off an aggregator, we start with an audit of the current integration. It covers the data your product uses and the way it reaches you. It also covers what the vendor's switch date means for your users. From there we plan the deployment around your Garmin application and run both setups in parallel before cutover.

Our wearables software development team works with health product teams on wearable data layers. If your vendor's notice has a date on it, tell us what you are building and when the switch happens.