Why Garmin has no personal API.
Garmin does not offer a personal API. The Garmin Connect Developer Program requires applicants to be a legal entity — a company, university, hospital, or research institution — and personal-use applications are rejected. There is no self-serve path for an individual to get API access to their own Garmin data. That single fact is the root of every "why can't I just get my data out?" thread on the internet, and it's why a small industry of workarounds exists.
What the developer program actually is
Garmin does have APIs, and they're good ones. The Connect Developer Program includes a Health API and an Activity API. The catch is who they're for.
Access is granted to organizations. You apply as a legal entity, describe your use case, and get vetted. Research institutions, corporate wellness platforms, and coaching products live here. There are no licensing fees — it was never about money. It's about controlling who touches user health data at scale which, to be fair to Garmin, is a defensible position for a company holding millions of people's biometrics.
What that means for you: if you're one person who wants to read your own runs, there's no queue to stand in. "I want my own data" is a personal-use application, and those are rejected.
Why "just use garth / python-garminconnect" stops working
The unofficial libraries don't use the official API. They can't — you'd need a partner agreement. Instead they log in to Garmin Connect the way your browser does and use the same internal endpoints the website uses.
That works, right up until it doesn't. Those endpoints and that login flow are internal implementation details. Garmin never promised they'd be stable, publishes no changelog for them, and has no reason to warn anyone before changing them. Add a Cloudflare challenge, rotate an OAuth exchange, change a token format — every tool built on top breaks simultaneously.
This is the part people underestimate. It isn't that the DIY route is hard to build; a weekend gets you a working script. It's that the maintenance never ends, and it's unscheduled. Your script breaks on Garmin's timetable, not yours — which in practice means the morning of a race, or the week you actually wanted the data.
This isn't hypothetical: garth is deprecated
In March 2026 Garmin changed its authentication flow. garth — the Python library that handled Garmin SSO for most of the ecosystem, and the dependency underneath a large share of Garmin integrations, including python-garminconnect — was deprecated by its maintainer. Its README now opens with this:
"Garth is deprecated and no longer maintained. Garmin changed their auth flow, breaking the mobile auth approach that Garth depends on."
The final release shipped on 28 March 2026. Existing saved sessions can keep working until their token expires, but new logins don't work at all. If you have a Garmin script that mysteriously started returning 401s this spring and you couldn't work out why: this is why. It wasn't your code.
This is the clearest illustration of the whole problem on this page. A single undocumented change on Garmin's side deprecated the library the ecosystem was built on, and there was no warning, no changelog, and no migration path. That's the risk you take on with the DIY route — not "might break someday," but "did break, this year, for everyone at once."
python-garminconnect — its Garmin client is in-house, which is why the March change didn't take it down. We're not claiming immunity: Garmin can change the flow again tomorrow and we'd have to chase it. The difference is only who does the chasing.
The uncomfortable question: is this allowed?
Worth being honest about, because most pages on this topic skip it.
Garmin's terms of service govern use of Garmin Connect, and automated access outside the official API isn't something Garmin formally sanctions. The data is yours in any moral sense — it came off your wrist. The access route is not one Garmin has blessed.
Official partner integrations don't have this ambiguity, because they use the sanctioned API. Everything else — including ghurt — lives in the grey area. We'd rather you knew that going in than found out later.
Your actual options
Four practical routes, with the real tradeoffs. Two of these aren't us.
| Option | Cost | Good for | The tradeoff |
|---|---|---|---|
| Official Garmin API | Free, but closed to you | Companies and institutions | Requires a legal entity. Personal applications rejected. Not an option for an individual. |
| DIY with an unofficial library | Free + your time | Developers who enjoy the tinkering and don't mind downtime | Breaks without warning, on Garmin's schedule. You're the on-call engineer for your own sleep data. |
| Official partner apps e.g. Tredict |
Free tier available | People who want sanctioned auth and Garmin-focused analysis | Garmin-only, and you work inside that product's model of your training. Genuinely the most "legitimate" route — if it fits, use it. |
| Hosted MCP connectors various, some free |
Often free | Getting Garmin into an LLM quickly | Usually single-device. Check who holds your credentials, what's stored, and whether anyone is actually maintaining it. |
| ghurt | Free tier, then $10/mo | People who want Garmin + Oura + Whoop answered as one dataset, without maintaining anything | Needs a Garmin password (no personal OAuth exists), and lives in the same grey area as any non-partner tool. |
How to choose
Genuinely, not as a sales pitch:
- You enjoy the tinkering and can tolerate downtime? Build it yourself. It's free, you'll learn the internals, and fixing it when it breaks is part of the fun for some people.
- You want the most sanctioned route and only care about Garmin? Look at an official partner like Tredict first. Sanctioned auth is a real advantage and the free read tier costs you nothing to try.
- You want Garmin in an LLM and nothing else? A free single-device connector may be all you need. Check who's maintaining it.
- You wear more than one device, or you want the connection to just keep working? That's the gap ghurt fills. It's the one thing a Garmin-only tool structurally can't do.
Why we built ghurt anyway
Short version: because the maintenance is the whole problem, and multi-device is where it gets genuinely hard.
One person maintaining one Garmin script is a hobby. One service maintaining Garmin, Oura, and Whoop — each with different auth, rate limits, response shapes, and date semantics — and normalizing them so an AI can reason across all three, is a different kind of work. When Garmin changes something, we fix it once and everyone's connection keeps working.
That's the honest pitch. Not "we cracked Garmin." Just: someone has to keep doing this, and it may as well not be you.
Common questions
Does Garmin have a personal API?
No. Garmin doesn't offer a personal or consumer API. The Connect Developer Program requires applicants to be a legal entity — a company, university, hospital, or research institution — and personal-use applications are rejected. There's no self-serve path for an individual to get API access to their own Garmin data for use in another tool.
Can I get Garmin API access as an individual developer?
Not through the standard partner program, which is business-only. Garmin has at times offered limited self-serve access for a developer to read their own account's data for experimentation, but that access is scoped to the account owner — it can't be extended to other users or used commercially.
Community reports also indicate the program has been intermittently paused. Check developer.garmin.com for the current position rather than relying on second-hand accounts.
Why do unofficial Garmin libraries keep breaking?
Because they depend on Garmin's internal login and session mechanism, which is undocumented and can change without notice. Garmin has no obligation to keep it stable, publishes no changelog for it, and doesn't announce changes in advance. When it changes, every tool built on it breaks at once — and stays broken until someone reverse-engineers the new flow.
The clearest example: in March 2026 Garmin changed its auth flow and garth — the SSO library most of the Python ecosystem depended on — was deprecated. Its maintainer's words: "Garmin changed their auth flow, breaking the mobile auth approach that Garth depends on." New logins stopped working entirely.
Is garth still usable? What about python-garminconnect?
garth is deprecated and no longer maintained, with its final release on 28 March 2026. If you already hold a saved session with a valid token it may keep working until that token expires, but new logins don't work. Libraries built on top of garth for authentication inherited the same breakage.
Anyone is free to fork it and rebuild the auth flow — that's the open-source answer. It just means someone has to do that work, and keep doing it every time Garmin changes something.
Will Garmin ever open a personal API?
We don't know, and anyone who tells you they do is guessing. The program's shape has changed over the years. If it opened tomorrow it would be good news for everyone, including us — we'd rather use a sanctioned API than maintain a session layer.
Does this apply to Oura and Whoop too?
No — and the contrast is instructive. Both Oura and Whoop offer standard OAuth that any individual can authorize in a couple of clicks, with no password ever leaving their login screen. Garmin is the outlier here, not the norm. That's precisely why "connect my Garmin" is a hard problem and "connect my Oura" isn't.