How to Integrate the Garmin API (2026)

The Garmin API gives your app deep wearable data — all-day wellness metrics like heart rate, steps, sleep, stress, respiration, and Pulse Ox through the Health API, plus detailed per-activity data across 100-plus sport types through the Activity API. Access uses OAuth 2.0 with PKCE to obtain a per-user userAccessToken, and data is delivered by push/ping webhooks you register rather than by polling. The one-line "how": get approved for the Connect Developer Program, connect each user over OAuth, register callback URLs, and let Garmin POST the data to you.

Read this before you plan a Garmin build

Garmin is not a self-serve API. The Garmin Connect Developer Program is partner-approval-only: you apply, and Garmin's team must approve a partnership before you receive any API credentials. There is no sign-up-and-ship path.

More important for 2026: new sign-ups are reportedly on hold. As of this writing, the public access-request form has been removed, community and issue-tracker reports describe the program as "on hold" for new applicants for several months, and there is no published re-open ETA. Existing approved partners are said to keep working, but you may not be able to onboard as a fresh developer right now.

Verify current status directly on developer.garmin.com before committing to Garmin. This is a factual access constraint, not a knock on the product — Garmin has the broadest health-metric breadth of any wearable API, but you need to confirm you can actually get approved first. If approval is blocked, weigh the alternatives in Fitbit API vs Garmin API and the broader survey in wearable data APIs — including aggregators that resell Garmin access under their own partnership.

Because Garmin's developer docs are gated (most primary pages return HTTP 403 to anonymous fetches), every host, path, scope name, summary-type name, and token lifetime below is marked verify against the current partner docs. Do not hard-code any of these values from this page — read them from the spec Garmin gives you after approval.

What you'll need

• An approved Garmin Connect Developer Program partnership. This is the gating step and, as noted, may be paused — start here, because nothing else works without it.
• Your issued API credentials (a consumer/client identifier and secret, exact names per the current spec — verify).
• A public HTTPS server to host your OAuth redirect URI and your webhook callback endpoints.
• Somewhere to store a per-user userAccessToken mapped to your internal user ID.

Step 1: Apply to the Connect Developer Program (and wait)

Start the partnership application on developer.garmin.com. Historically this meant submitting an access-request form describing your company and use case; as of 2026 that public form is reportedly removed, so check the program overview page for the current path and status. Treat this as an "apply and wait" step, not a self-serve registration — approval is a manual, partner-level decision with no guaranteed timeline, and new applications may currently be paused. Do not build against Garmin on the assumption you will be approved; confirm access first.

Step 2: Register your app and get credentials

Once approved, you register your application in the developer portal and receive your API credentials. During registration you configure your OAuth redirect URI and your webhook callback URLs — Garmin's model has you register a callback endpoint per summary type you want to receive (see Step 4). Note which of Garmin's programs you have been granted: the Health API (all-day wellness), the Activity API (per-activity sport data), and possibly others such as a Training or Women's Health API — availability and exact scopes are per your partnership agreement, so verify what you actually have access to.

Step 3: Authenticate each user with OAuth 2.0 PKCE

Current Garmin docs specify OAuth 2.0 with PKCE (Proof Key for Code Exchange). The shape is the standard authorization-code-with-PKCE flow: generate a code verifier and challenge, send the user to Garmin's authorize endpoint, and exchange the returned authorization code (plus your verifier) for tokens at the token endpoint.

GET https://<garmin-authorize-host>/oauth2/authorize
  ?response_type=code
  &client_id=YOUR_CLIENT_ID
  &redirect_uri=https://yourapp.example.com/garmin/callback
  &code_challenge=GENERATED_CHALLENGE
  &code_challenge_method=S256
  &state=RANDOM_STATE

The exact authorize and token host names, parameter names, and required scopes are in the gated Garmin Connect Developer Program OAuth 2.0 PKCE Specification — the host above is a placeholder, so verify every URL against that spec. A historical caveat worth knowing: Garmin's Health API predates OAuth 2.0, and older integrations (and some lingering third-party references) used OAuth 1.0a. If you find OAuth 1.0a instructions, confirm whether they apply to your program before following them — new builds should use the current PKCE flow (verify).

The token exchange returns a per-user userAccessToken — Garmin's identifier for that connected user. Store it mapped to your internal user ID; you will use it to authenticate the callbacks you fetch later. Public secondary sources cite an access-token lifetime of roughly three months, refreshable via a refresh token — treat the exact lifetime and refresh mechanics as verify against the current spec.

Step 4: Register push/ping webhooks (the key difference)

This is where Garmin differs architecturally from most wearable APIs: you do not poll. You register HTTPS callback URLs per summary type in the developer portal, and Garmin POSTs data to you when a user's device syncs. There are two delivery modes:

• Ping Service — Garmin POSTs a lightweight notification saying new data exists. The payload includes a callbackURL that you then GET (authenticated with that user's OAuth token) to pull the actual summary. This keeps Garmin's POST small and lets you fetch on your own schedule.
• Push Service — Garmin POSTs the full updated data inline as JSON, so there is no follow-up GET. Same data, delivered directly.

Both modes retry on failed delivery, so your endpoint must return quickly and handle duplicates idempotently. Choose Ping when you want to control fetch timing and load; choose Push for the lowest latency and one fewer round trip. Which summary types exist (dailies, sleeps, epochs, stress, Pulse Ox, and so on) and their exact names come from the Health/Activity API spec — verify the summary-type names against the current docs rather than trusting any list here.

Step 5: Receive and process the callbacks

A Ping notification wraps arrays keyed by summary type; each record identifies the user and gives you the URL to fetch. The illustrative shape below is from public secondary docs — the exact host, path, and fields are gated, so verify against the partner spec:

{
  "dailies": [
    {
      "userId": "4aacafe82427c251df9c9592d0c06768",
      "userAccessToken": "8f57a6f1-26ba-4b05-a7cd-c6b525a4c7a2",
      "uploadStartTimeInSeconds": 1444937651,
      "uploadEndTimeInSeconds": 1444937902,
      "callbackURL": "https://<garmin-api-host>/<gated-summary-path>?uploadStartTimeInSeconds=1444937651&uploadEndTimeInSeconds=1444937902"
    }
  ]
}

For a Ping, look up your stored userAccessToken by userId, then GET the callbackURL with that user's OAuth authorization to retrieve the summary. For a Push, the same top-level envelope (for example a "dailies" array) carries the full metric fields inline instead of a callbackURL — you process it directly, no fetch needed. In both cases, key incoming records to your internal user by the Garmin userId/userAccessToken, acknowledge fast, and deduplicate on the upload time window.

Gotchas and production notes

• Approval is the whole game. Everything above is moot until you are an approved partner, and new sign-ups may be paused as of 2026 — verify on developer.garmin.com before you plan a roadmap around Garmin.
• Nothing here is a stable public contract. Hosts, paths, scopes, summary-type names, and token lifetimes are behind the partner NDA/docs and can change. Read them from the spec Garmin issues you, and do not copy the placeholders on this page into production.
• Webhooks, not polling. Design your ingestion around receiving POSTs, retries, and out-of-order deliveries. Your callback endpoints must be publicly reachable over HTTPS, fast, and idempotent.
• Store tokens per user and plan for refresh. Persist each userAccessToken (and refresh token) mapped to your user, and handle the roughly three-month expiry (verify) before it bites you in production.
• Consider an aggregator if approval is blocked. If you cannot get into the program, a wearable-data aggregator that already holds a Garmin partnership can resell access through one integration — compare that path in wearable data APIs and see how Garmin stacks up against the self-serve alternatives in Fitbit API vs Garmin API.