Garmin Connect's Unofficial Python API: What Garth Was, Why It's Deprecated, and What to Use Instead

Short answer: Garth — the unofficial Python library for Garmin Connect — is deprecated and no longer maintained. Its final release, 0.8.0, was published on 28 March 2026, one day after the maintainer announced the project was ending. Fresh logins no longer work. Saved sessions may keep running until their OAuth1 token expires (roughly a year from issue). The MCP server built on Garth — the one listed on this site's Garth (Garmin Connect) server page — has not shipped a release since 1 February 2026 and pins Garth to the 0.5.x line, so the install snippet on that page will not produce a working login today. If you are starting fresh in Python, use garminconnect (python-garminconnect), which removed its Garth dependency and authenticates through the Android app's mobile SSO flow. If you want your data inside an LLM, expect to drive a real browser.

Everything below is the honest version of that answer: what Garth actually did, what Garmin changed in March 2026, which options still work in September 2026, and which "fixes" circulating online are unverified.

What Garth actually was

Garth was a Python client for the Garmin Connect API with OAuth authentication. It was created by Matin Tamizi, with the first PyPI release (0.1.0) on 5 July 2023. In his deprecation post, Tamizi says he spent until 3 August 2023 getting the mobile auth flow stable, and that the approach then ran "with almost no issues for over 2.5 years."

It shipped three things that made it the default choice in the Python fitness-data ecosystem:

• Session handling. garth.login(email, password), garth.save("~/.garth") and garth.resume("~/.garth") gave you a durable session. MFA was handled with a terminal prompt or a custom callback (prompt_mfa), and the OAuth1 token was documented as surviving roughly one year while the OAuth2 token auto-refreshed.
• Typed data classes. Instead of hand-parsing JSON, you could call garth.DailySteps.list(period=7), garth.DailyStress.list("2023-07-23", 2), garth.DailySleep.list(period=7) and similar for sleep, HRV, hydration, intensity minutes and training status. The docs list a long set of data types (SleepData, HRVData, WeightData, DailyHeartRate, BodyBatteryData, TrainingReadinessData, Activity, BloodPressure and others).
• A raw escape hatch. garth.connectapi(path, params=...) hit any Garmin Connect endpoint directly, and garth.upload(file) pushed a FIT activity back up. This is what made Garth useful as a foundation: when Garmin added an endpoint the typed layer did not cover, you called it yourself.

That combination is why so much downstream software depended on it. Garth's own README claims the library "reached 350k+ downloads per month on PyPI and was translated into multiple other programming languages." PyPI shows a lower figure today — 219,943 downloads in the last month at the time of writing — which is consistent with a project that has been publicly deprecated for six months.

What Garmin changed in March 2026

The breakage was not one bug. It was a set of server-side changes that landed across roughly a week, and they attacked the login path Garth depended on rather than the data path.

The first reports cluster around 15–17 March 2026. Users started seeing 401 Unauthorized at the OAuth1 exchange step — the SSO login itself succeeded and produced a service ticket, but exchanging that ticket at connectapi.garmin.com/oauth-service/oauth/preauthorized failed. Then, from 17–18 March, fresh login attempts began returning 429 Too Many Requests from the mobile login endpoint. One reporter reproduced the 429 with a plain curl -I https://sso.garmin.com/mobile/api/login from a residential connection with no application code involved, and the response carried Server: cloudflare.

The important distinction, and the one that still holds in September 2026, is between logging in and making API calls:

• Existing saved sessions kept working. garth.resume() with a valid stored token continued to return data for many users, because no new authentication was required.
• Fresh logins stopped working. garth.login(email, password) failed for most people, in most regions, on both the old /sso/signin endpoint (Garth 0.6.x) and the newer /mobile/api/login endpoint (Garth 0.7.x).

A separate failure mode compounded it: API calls from datacenter and cloud IPs started returning 401 even with valid tokens. Several users reported that the same token worked from a home connection and failed from a cloud runner. Garmin's forums thread on the change — titled "TLS fingerprinting blocks third-party clients" — collects the customer-side version of the same story, including users running Garmin Connect MCP servers that stopped working overnight.

Tamizi's diagnosis was that Garmin had migrated the login API flow and deployed Cloudflare protection that Garth's mobile-auth approach could not survive. He announced the deprecation in discussion #222 on 27 March 2026: "I'm not in a position to dedicate the time to adapt Garth to these changes." He kept the repository up, released a final version with a deprecation warning, and invited forks. That final version is 0.8.0, uploaded 28 March 2026. The official documentation now carries a banner reading: "Garth is deprecated and no longer maintained. New logins will not work due to changes in Garmin's auth flow."

There is a further claim worth flagging early, because it shows up in pull requests and issue threads: that the login endpoints were disabled outright, that /mobile/api/login returns 400 and the OAuth token endpoint returns 401 regardless of client, and that the only working transport is JavaScript fetch() executed inside a real browser. That claim comes from a Garth pull request (#225, "Revive garth: replace HTTP transport with Camoufox browser automation") whose author tested seven approaches and reported 403 or 400 for all HTTP-level clients and 200 only for in-browser fetch. It is a single maintainer's testing, not Garmin documentation, and it conflicts with other users who report that a User-Agent override alone was enough. Treat the "no HTTP fix exists" position as well-argued but contested.

The MCP server on this page: still listed, still installable, not still working

The Garth (Garmin Connect) MCP server is a real, MIT-licensed community server published by the same author, with 30 tools covering sleep, stress, intensity minutes, activities, body composition, devices, gear and a get_connectapi_endpoint escape hatch. It is a thin wrapper: the health and wellness tools call Garth's typed data classes, the activity and device tools call the Connect API directly.

Three facts decide whether it works for you:

1. The last release is from before the breakage. PyPI lists garth-mcp-server 0.0.10, uploaded 1 February 2026; the GitHub repository shows a release tagged v0.10.0 on the same date. Nothing has shipped since Garmin changed the auth flow.
2. It pins an old Garth. The published dependency is garth>=0.5.14,<0.6.0. So uvx garth-mcp-server resolves a Garth from the 0.5 line, not the final 0.8.0 — the version series that predates even the endpoint migration.
3. Its authentication instructions depend on a login that no longer works. The documented setup is to run uvx garth login and paste the output into GARTH_TOKEN. That is exactly the command Garth's own documentation now marks as non-functional for new logins.

The practical consequence: the install snippet is fine, the tools are real, and if you already hold a valid saved Garth session you may be able to hand the server a working GARTH_TOKEN. But a first-time setup on a machine with no stored session will not authenticate. That is a property of Garmin's change, not a defect introduced by this directory listing or by the server's author.

If you are evaluating Garmin tooling for an assistant, the neighbouring listings are worth reading before you commit: the garmin-connect skill syncs daily health data into markdown files, and the garmin skill wraps a non-interactive gc CLI. Both depend on the same underlying authentication surface, so the same question — can you still log in? — applies to them.

What actually works in September 2026

python-garminconnect: the maintained successor

garminconnect (python-garminconnect, by Ron Klinkien) is now the practical replacement for Garth in Python. It is actively maintained: version 0.3.16 was published on 18 September 2026, five days before this article, and PyPI recorded 634,506 downloads in the last month — roughly three times Garth's current figure.

The authentication change is the point. The library no longer uses Garth or the OAuth1/OAuth2 flow it depended on. Per its README, it authenticates through the same mobile SSO flow as the official Garmin Connect Android app, exchanges the resulting service ticket for DI OAuth Bearer tokens at diauth.garmin.com, and stores them at ~/.garminconnect/garmin_tokens.json (mode 0600, in a 0700 directory). The DI token auto-refreshes before each request, so a full credential login — and any MFA prompt — is only needed when the refresh token itself expires or is revoked. It uses curl_cffi for TLS-fingerprint impersonation, and login() tries several strategies in sequence (mobile, SSO widget, web portal), only declaring success when the API accepts the resulting token.

Installation and a first call look like this:

pip install --upgrade garminconnect curl_cffi

import os
from datetime import date
from garminconnect import Garmin

client = Garmin(
    os.getenv("EMAIL"),
    os.getenv("PASSWORD"),
    prompt_mfa=lambda: input("MFA code: "),
)
client.login("~/.garminconnect")          # saves tokens; later runs just load them

today = date.today().isoformat()
stats = client.get_stats(today)
print(stats)

Two things make migration cheap. First, the constructor accepts is_cn=True for China-region accounts and return_on_mfa=True for two-step MFA flows — the same concerns Garth handled with --domain garmin.cn and return_on_mfa. Second, the library exposes connectapi(path, **kwargs) and download(path, **kwargs) alongside login(tokenstore) and logout(tokenstore), so raw calls that you wrote against garth.connectapi(...) transfer almost verbatim. Verified against the published source of 0.3.16, the class exposes 165 public methods spanning activities, workouts, gear, menstrual cycle, nutrition, golf and a query_garmin_graphql call.

A rough mapping for the common cases:

Garth	python-garminconnect
garth.login(email, password)	Garmin(email, password).login("~/.garminconnect")
garth.save("~/.garth") / garth.resume(...)	Handled inside login(tokenstore)
garth.connectapi(path, params=...)	client.connectapi(path, **kwargs)
garth.download(path)	client.download(path, **kwargs)
garth.DailySteps.list(period=7)	client.get_daily_steps(start, end)
garth.DailySleep.list(period=7)	client.get_sleep_data(date)
garth.DailyStress.list(...)	client.get_all_day_stress(date)
garth.DailyHRV.list(period=7)	client.get_hrv_data(date)

Two caveats on the migration. The token format changed, so an old ~/.garth directory is not reusable — a fresh login is required once. And the library dropped the garth.* hooks that some integrations touched, which is why projects such as withings-sync migrated with code changes rather than a version bump.

garth-ng: the fork, and why you probably should not pick it

A fork exists. garth-ng (by CyberFossa) keeps import garth working — the package name changed, the import did not, by design — and restores the session API as garth.configure(storage=garth.FileTokenStorage("~/.garth")) with garth.save/garth.resume equivalents. It swaps the HTTP stack for curl-cffi and adds data types Garth never had, including blood pressure, nutrition and personal records.

The adoption numbers are the reason to hesitate. The repository shows 2 stars and 0 forks, created 6 April 2026. On PyPI the latest stable release is 1.1.0 (12 April 2026), with a 2.0.0 alpha from 14 June 2026 that is still marked as a pre-release. Downloads run around 4,000 a month — two orders of magnitude below garminconnect. The fork's own claim is that it "restores compatibility"; whether it still does in September 2026 is a claim from its maintainer, not something independently verified here. If you adopt it, pin the exact version and test login yourself on day one.

Browser-transport workarounds

If your requirement is specifically "Garmin data inside an MCP client," the working pattern in 2026 is a real browser. The clearest example is garmin-connect-mcp, which routes every API call through page.evaluate(fetch(...)) inside headless Chromium, inheriting a genuine Chrome TLS fingerprint, with 27 tools and session cookies captured from a manual login. Its README is explicit about the trade-off: "Session cookies expire after a few hours. Re-run the login flow when they do." That is a heavier, more fragile setup than a library login, and it needs Playwright plus a Chromium download.

The Garth PR that proposed the same architecture (Camoufox browser automation, session cookies with roughly a one-year lifetime) was closed as a draft and not merged. It reported 137 unit tests and 72 of 72 live integration tests passing at the time, and it is honest about the costs: not thread-safe, one session at a time, 200–300 MB of RAM, roughly 500 MB of browser binaries, and placeholder tokens that break code inspecting token contents.

The official API — real, but not for you

Garmin does operate an official Garmin Connect Developer Program, and the frequent claim that "Garmin has no API" is wrong. The program covers a Health API (all-day heart rate, sleep, steps and similar), an Activity API (over 30 activity types), a Women's Health API, a Training API and a Courses API, all using OAuth 2.0, with no licensing or maintenance fee.

The catch is eligibility, and it is stated plainly in Garmin's own FAQ: "it is only for business use." Applications are reviewed, with a status decision within two business days and a typical integration taking one to four weeks. Access to some metrics may additionally require a licence fee or a minimum device order quantity. So the official path is available to a company building a product, not to an individual who wants their own sleep data in a script. Note also that this program is separate from Connect IQ, which is free but is about watch faces, data fields and on-device apps, not cloud data access.

That gap — an official API that is enterprise-only, and unofficial clients that Garmin actively blocks — is the structural problem under this whole topic. It is the same complaint developers made in the Garmin forums thread, from users who pointed out they were not asking for more than access to data their own devices generated.

Evidence table

Claim	Grade	Source
Garth's final release is 0.8.0, uploaded 28 March 2026	verified	PyPI JSON API, garth release metadata, read 23 Sep 2026
Garth was deprecated on 27 March 2026 with the announcement "Deprecating Garth"	verified	matin/garth discussion #222, dated 27 Mar 2026
The library claims 350k+ monthly PyPI downloads at peak	vendor-claimed	Garth README and deprecation post
Garth's current download volume is 219,943/month	verified	PyPI project page, read 23 Sep 2026
Fresh logins no longer work; existing saved sessions may work until the OAuth1 token expires (~1 year)	vendor-claimed, consistent across sources	Garth README and docs banner; Garth issue #217 user reports
Garmin's auth change landed mid-March 2026 (reports cluster 15–19 March)	verified	matin/garth issues #199 and #217, with curl reproduction; python-garminconnect issue #332 (17 Mar 2026)
The 429 on /mobile/api/login comes from Cloudflare and is not per-IP or per-account	verified for the reproduction, not for the cause	Garth issue #217 (curl -I from residential IP, Server: cloudflare)
API calls from datacenter/cloud IPs return 401 even with valid tokens	vendor-claimed	Garth issue #217 reports; python-garminconnect issue #332
/mobile/api/login and the OAuth preauthorized endpoint are disabled, and no HTTP-level client works	unverified and contested	Garth PR #225 (author's own test matrix); contradicted by users reporting a User-Agent override works
garth-mcp-server's last release is 0.0.10 / v0.10.0, dated 1 February 2026	verified	PyPI JSON API and GitHub releases, read 23 Sep 2026
garth-mcp-server depends on garth>=0.5.14,<0.6.0	verified	PyPI dependency table, read 23 Sep 2026
Its documented GARTH_TOKEN comes from uvx garth login, which no longer performs new logins	verified	garth-mcp-server README; Garth docs banner
python-garminconnect 0.3.16 published 18 September 2026	verified	PyPI JSON API, read 23 Sep 2026
python-garminconnect uses the Android mobile SSO flow with DI OAuth Bearer tokens and curl_cffi	vendor-claimed	python-garminconnect README and PyPI metadata (curl_cffi>=0.15.0)
It exposes connectapi(), download(), login(tokenstore) and 165 public methods	verified	published source of garminconnect 0.3.16, read 23 Sep 2026
python-garminconnect's 634,506 monthly downloads exceed Garth's	verified	PyPI project pages, read 23 Sep 2026
garth-ng exists, keeps import garth, and restores the session API	vendor-claimed	cyberfossa/garth-ng README
garth-ng latest stable is 1.1.0 (12 Apr 2026); 2.0.0a1 (14 Jun 2026) is a pre-release; ~4k downloads/month; 2 stars	verified	PyPI JSON API and GitHub repository metadata, read 23 Sep 2026
A browser-transport MCP server works by routing calls through page.evaluate(fetch(...)), with cookies expiring in hours	vendor-claimed	etweisberg/garmin-connect-mcp README
The official Garmin Connect Developer Program is business-use only, uses OAuth 2.0, has no licence fee, and reviews in two business days	verified	Garmin Connect Developer Program FAQ, read 23 Sep 2026
Garmin launched a paid Connect+ tier that restricts third-party access to features competing with it	unverified	third-party project README only; not confirmed in Garmin's own materials
One user reports Garth 0.6.3 still logs in while 0.7.0+ returns 429	unverified and contested	Garth discussion #222 comment (Jun 2026); contradicted by #217 reporters who saw 429 on 0.6.3

Caveats

This is a fast-moving area and the article has a shelf life. Garmin has changed its auth surface repeatedly within a single year: a 401-then-429 sequence in March 2026, endpoint migrations, and an apparent React-based web stack with /gc-api/ endpoints that the maintainer of python-garminconnect was still investigating in March. Anything marked "works" here should be re-tested before you build on it.

I did not run a login against Garmin to write this. No Garmin account was used, no credentials were entered, and no library was executed against the live API. Every "works" statement is sourced to a maintainer, a vendor README, or a public issue thread — not to my own test. Where that distinction matters, the evidence table above grades it as vendor-claimed.

The "no HTTP fix exists" claim is contested. The most-cited technical explanation (PR #225) comes from one developer's testing matrix. Other users in the same threads report that overriding the User-Agent to a desktop browser string was enough to get a fresh login, at least temporarily, and at least one other reports it working from some networks and not others. Both cannot be universally true, which is a good sign the behaviour is region-, IP- and time-dependent.

Region and network matter more than the library you pick. The most consistent pattern across every thread is that residential connections fare better than cloud and CI runners, and that the same token can work from one network and fail from another. If you are deploying to a cloud runner, plan for authentication to be the part that breaks, and design around a token bootstrap you can run locally.

Old tokens are not a migration path, they are a grace period. Garth's docs put the OAuth1 token lifetime at roughly one year. A session issued in, say, January 2026 is close to expiry or already past it. Do not build a new system on the assumption that a stored session will carry you.

Token files are credentials. Both Garth's ~/.garth and python-garminconnect's ~/.garminconnect/garmin_tokens.json hold refresh tokens that grant persistent account access. python-garminconnect documents 0600 on the file and 0700 on the directory, and has shipped security hardening around symlinked token paths and atomic writes. Do not put a Garmin password in shell history, a shared CI variable, or a public repository.

Unofficial access is a cat-and-mouse game, not a supported integration. No source in this article documents Garmin's own developer policy for personal-use clients, and I found no published statement from Garmin permitting or prohibiting them. Assume the mechanics can change without notice or announcement — that is exactly what happened in March 2026, and there was no migration guide on the other side of it.

Verdict

Use it if you need Garmin data in Python and can accept an unofficial client: adopt garminconnect (0.3.16 or later), migrate your garth.connectapi calls across largely unchanged, and bootstrap the login on a residential machine before copying tokens to wherever the job runs. If you specifically want an LLM to read your Garmin data, a browser-transport MCP server is the pattern with the most current evidence behind it, at the cost of Playwright, a Chromium download and session cookies that expire in hours.

Be skeptical if you are following a tutorial, README or directory listing written before April 2026 that starts with pip install garth or uvx garth login. That includes the install snippet on the Garth MCP server listing here: the server is real and the tools exist, but a first-time login through the documented path will not authenticate, because the last release predates the breakage and pins a Garth from the 0.5 line. Be equally skeptical of "garth is dead, here is the fix" posts that assert a single universal workaround — the reports genuinely disagree, and the disagreement looks like network and region dependence rather than anyone being wrong.

Watch for three things. First, whether a maintained fork reaches real adoption: garth-ng preserves import garth, which would make migrations trivial, but 2 stars and roughly 4,000 monthly downloads is not yet a community. Second, whether Garmin opens its official Developer Program to individuals — the APIs exist, use OAuth 2.0, and cost nothing, and eligibility is the only wall. Third, whether browser-transport tools stabilise: if session cookies keep expiring in hours, "works today" will keep meaning "re-run the login flow today."

FAQ

Is Garth still maintained? No. The maintainer announced the deprecation on 27 March 2026 in discussion #222, saying he was not in a position to adapt the library to Garmin's auth changes. The final release, 0.8.0, was published 28 March 2026. The repository and documentation remain online for reference, and the docs carry a deprecation banner.

Can I still install and use Garth today? You can install it — pip install garth still resolves 0.8.0, which requires Python 3.10 or later. Whether it works depends entirely on whether you already have a valid saved session. Garth's documentation is explicit: "New logins will not work due to changes in Garmin's auth flow," and existing sessions may keep working until the OAuth1 token expires, roughly a year from issue.

Does the Garth MCP server listed on this site still work? Partly. The server is real, MIT-licensed, and exposes 30 tools. But its last release was 1 February 2026 — before the March auth change — and it depends on garth>=0.5.14,<0.6.0. Its setup instructions require a token from uvx garth login, which no longer performs new logins. If you already hold a working saved session, you may be able to supply a valid GARTH_TOKEN; a fresh setup will not authenticate.

What should I use instead of Garth in Python? garminconnect (python-garminconnect) is the maintained choice. It dropped the Garth dependency, authenticates through the Android app's mobile SSO flow to obtain DI OAuth Bearer tokens, and was last released on 18 September 2026. It also exposes connectapi() and download(), so most raw Garth calls port across with minimal edits. Expect to log in once more, because the token format changed.

Is there an official Garmin Connect API I can use instead? Yes, and no. Garmin runs the Garmin Connect Developer Program with Health, Activity, Women's Health, Training and Courses APIs, all OAuth 2.0, with no licensing or maintenance fee. But Garmin's own FAQ states it "is only for business use," applications are reviewed, and some metrics may require a licence fee or minimum device order quantity. Individual developers wanting their own data are, in practice, outside the program.

Why do I get 429 Too Many Requests even with correct credentials? The 429 in March 2026 was not a credential problem. It came from Cloudflare in front of Garmin's SSO endpoints, and one reporter reproduced it with a bare curl -I request carrying no authentication headers at all, from a residential IP. Users reported the same result with invalid and valid credentials, from fresh IP addresses, and after waiting more than 24 hours. That points at the edge blocking the request pattern rather than rate-limiting your account.

Do I need a browser, or is there an HTTP fix? The reports conflict. One detailed test matrix (PR #225) concluded no HTTP-level client works and only in-browser fetch() succeeds; other users reported that overriding the User-Agent to a desktop browser string was enough to log in. Since Garmin's edge behaviour appears to vary by network and region, the honest answer is that a plain HTTP client is unreliable and a real browser is the approach with the most consistent reports behind it.

Is using an unofficial Garmin client against the rules? I could not find a published Garmin developer policy addressing personal-use clients, so I am not going to assert one. What is documented is the practical outcome: unofficial clients have been broken repeatedly by server-side changes, with no notice and no migration path. The Garmin forums thread on the topic is developers arguing they should be able to reach data their own devices generated; Garmin has not published a response to that request in the sources reviewed here.

Sources

All sources were fetched and read on 23 September 2026.

• matin/garth — repository README and deprecation notice, https://github.com/matin/garth (deprecation announced 27 Mar 2026)
• "Deprecating Garth" — discussion #222, https://github.com/matin/garth/discussions/222 (posted 27 Mar 2026)
• Garth documentation, https://garth.readthedocs.io/en/latest/ and Getting Started page (deprecation banner; session and env-var behaviour)
• PyPI, garth project page and JSON API — 0.8.0 uploaded 28 Mar 2026; 219,943 downloads last month
• matin/garth issue #199 — "401 Unauthorized on OAuth1 token exchange … ~March 15-17, 2026" (opened 17 Mar 2026)
• matin/garth issue #217 — "429 Too Many Requests on /mobile/api/login" (opened 19 Mar 2026; updated 22 May 2026)
• matin/garth pull request #225 — "Revive garth: replace HTTP transport with Camoufox browser automation" (opened 31 Mar 2026; closed)
• Garmin Forums — "TLS fingerprinting blocks third-party clients", https://forums.garmin.com/apps-software/mobile-apps-web/f/garmin-connect-web/433892/tls-fingerprinting-blocks-third-party-clients
• cyberjunky/python-garminconnect — README and repository, https://github.com/cyberjunky/python-garminconnect (source read at 0.3.16)
• cyberjunky/python-garminconnect issue #332 — "Did Garmin change authentication API?" (opened 17 Mar 2026; closed 11 Apr 2026)
• cyberjunky/python-garminconnect releases page (0.3.12 released 22 Aug 2026)
• PyPI, garminconnect project page and JSON API — 0.3.16 uploaded 18 Sep 2026; 634,506 downloads last month
• PyPI, garth-mcp-server project page and JSON API — 0.0.10 uploaded 1 Feb 2026; dependency garth>=0.5.14,<0.6.0
• matin/garth-mcp-server — repository README, latest release v0.10.0 dated 1 Feb 2026
• MCP.Directory — Garth (Garmin Connect) server listing, https://mcp.directory/servers/garth-garmin-connect
• cyberfossa/garth-ng — repository README and release metadata (created 6 Apr 2026; v2.0.0-alpha.1 on 14 Jun 2026)
• PyPI, garth-ng project page and JSON API — 1.1.0 uploaded 12 Apr 2026; 4,013 downloads last month
• etweisberg/garmin-connect-mcp — repository README, https://github.com/etweisberg/garmin-connect-mcp (created 30 Mar 2026)
• diegoscarabelli/garmin-health-data — repository README and PyPI page (2.11.2, 26 May 2026)
• Garmin Connect Developer Program — Overview and Program FAQ, https://developer.garmin.com/gc-developer-program/