429 Too Many Requests on /mobile/api/login — persists even from browser/curl without any code

[giobarsa]

Description
Since March 17-18, 2026, all fresh login attempts return 429. The issue is not limited to our application — the same endpoint returns 429 from a plain curl -I with no authentication headers, from a residential IP in Italy:
curl -I https://sso.garmin.com/mobile/api/login
HTTP/1.1 429 Too Many Requests
Server: cloudflare
CF-RAY: 9dec3d344f67ea3c-FCO
FCO = Fiumicino (Rome, Italy) Cloudflare node. The block has persisted for over 4 hours with no recovery.
What works

resume() / load() with existing saved tokens → works fine
connect.garmin.com/status → returns 301 (reachable)
sso.garmin.com root → returns 404 (reachable)

What fails

Any fresh login(email, password) → 429 immediately
The block affects both garth 0.6.3 (old endpoint /sso/signin) and garth 0.7.0 (new endpoint /mobile/api/login)

Timeline

March 17: first 429 errors appeared in production logs (garth 0.6.3)
March 19 morning: updated to garth 0.7.0 — same 429, different endpoint
March 19 afternoon: confirmed 429 from plain curl on residential IP, no application involved

Question
Is this a known Cloudflare rate-limit affecting the Italian region or a broader issue? Is there a recommended probe endpoint to detect Garmin SSO availability without triggering rate-limits ourselves? We are considering using connect.garmin.com/status (returns 301) as a health check probe — would that be appropriate?
We have stopped all login attempts on our end to avoid prolonging the block. Happy to provide additional diagnostics if useful.

[rod-trent]

Affecting the US, as well.

[sintei]

Affecting Sweden as well.

[grisumedia]

429, every time.
It doesn't matter if I enter valid login data or not. Even with a fresh IP address.
Tested two German fiber connections and a mobile connection.
No way to login, still with 0.7.11

[artcmd]

I got the same 429 issues on GitHub Actions. When I run it on my Linux server (US East), there's no issue.
I'm using 0.6.3 version.

[theverex]

Same issue here in AU. Tried many different IP Addresses and still will not work.

[coleman8er]

Seeing the same issue since March 17, US-based, tried across several states. Browser login and the Garmin Connect mobile app both work fine. It's specifically the SSO login endpoint that's returning 429 globally. Watching PR #218.

[flocsy]

Same for me from digitalocean in Frankfurt, even though these tokens were actively used until 17th Mar 2026 (when it stopped working)

However interestingly some (but not all) of my old tokens (7 Oct 2025) on my local laptop in Israel still work. So it's not that simple as "existing" tokens vs new logins.

[Columbo]

I had to pin my requirements.txt directly to PR 218 and switch to a self-hosted-runner. For the self-hosted runner I use a proxmox vm. For me it seems to work again if I avoid using the Github runners and if i work with the unmerged commit PR218. If you want to know more about my setup, have a look at it: https://github.com/Columbo/garminsync

[flocsy]

I had to pin my requirements.txt directly to PR 218 and switch to a self-hosted-runner. For the self-hosted runner I use a proxmox vm. For me it seems to work again if I avoid using the Github runners and if i work with the unmerged commit PR218. If you want to know more about my setup, have a look at it: https://github.com/Columbo/garminsync

I tried it now, and at first I thought it works, but no. It works for some existing tokens, but not all of them, and for those that it doesn't work I can't login. So I don't see any improvement using #218 or not.

[coleman8er]

Seeing the same issue since March 17, US-based, tried across several states. Browser login and the Garmin Connect mobile app both work fine. It's specifically the SSO login endpoint that's returning 429 globally. Watching PR #218.

Workaround: Playwright browser auth
Spent a few days banging on this. Here's where I landed.

Didn't work:

• Waiting 24+ hours with zero requests — 429 on the very first attempt
• Tried from residential IPs in multiple US states (and one from an airplane as a bonus) — 429
• PR Remove SSO_PAGE_HEADERS from login POST and MFA verify #218 branch — 429

The block isn't per-IP or per-account. It's seems to be the SSO login endpoint itself, at the Cloudflare level.

What worked:
You can still log into connect.garmin.com in a browser. So I used Playwright to automate that. Open a real Chromium window, log in like a regular human person, grab the SSO ticket from the redirect, exchange it for OAuth1/OAuth2 tokens. Never hits /sso/signin or /mobile/api/login.

Here is the script if anyone wants it, it's imperfect but allows your personal data to flow again, locally, until this is resolved. Seems PR 218 won't be the entire fix.

Also worth noting: Garmin is blocking connectapi.garmin.com from GitHub Actions runner IPs too. Valid tokens, 401 anyway. Had to move the sync to run locally. @Columbo self-hosted runner approach would also get around this.

[cyberjunky]

@coleman8er you don't run into 401 Unauthorized errors? I begin to believe they made the OAuth tokens legacy, they put in a new React app, with new /gc-api/ endpoints, and those tokens don't work on it.. I'm looking into JWT now.

[coleman8er]

@cyberjunky I did get 401s, but only from GitHub Actions runner IPs. Same tokens work fine from my home network. I pulled daily summaries, sleep, activities, HRV, weight about an hour ago.

So for me it seems like two separate blocks: SSO login endpoint 429'd everywhere, and connectapi 401s specifically from datacenter/cloud IPs. Are you hitting 401s from a residential IP or a cloud provider?

[cyberjunky]

Are you hitting 401s from a residential IP or a cloud provider?

Yes, a Dutch consumer internet connection.

[flocsy]

I think it's not that simple, because even from my residential location I exit via my work VPN, that probably places me to some cloud/datacenter, and it still works.

But I'm a bit pessimistic about this, 'cause it sounds like this is part of the intentional or unintentional changes Garmin did in the past half a year, since they started using Cloudflare and all the problems regarding their forums (can't post images, code snippets, ... and in the past few weeks many people say they are logged out multiple times a day) started. Based on the willingness (0?) or the capability (0?) of Garmin to fix those issues I don't see how this can be fixed without them. Especially if they do these crackdowns intentionally, then anything we do here will be read by them and they'll block that too, and at best it'll become a constant mouse/cat fight.

[cyberjunky]

Just wait i think they are rolling out their new web infra gradually... i discovered a lot of changes in the backend of garmin and in cloudflare, they are actively trying to block all python scripts from accessing their API i tell you. I have an working alternative using the JWT tokens... Needs some cleaning up, and yes no oauth keys so code need to change... i cannot get it to work anymore, even investigated the app..