Environment: Ubuntu 24.04, Python 3.12.3, garminconnect 0.3.17,
requests 2.34.2, urllib3 2.8.0, curl_cffi 0.16.3 installed but unused here.
An explicitly initiated manual login at 2026-10-07 19:18 UTC made exactly one
transmission: POST /mobile/api/login on sso.garmin.com. It received HTTP 429.
Retry-After was absent. MFA, DI exchange, and API verification were not reached.
The user reports waiting over 24 hours since the preceding attempt.
Our wrapper intentionally allows only mobile+requests, invokes the installed
_do_mobile_login(), and retains its public GCM_IOS_DARK client ID and fixed
iPhone User-Agent. It disables environment proxies, redirects, retry/fallback
transmissions after a failure, and TLS/browser impersonation strategies.
Connect/read timeout is 10/30 seconds. No token/session was created.
We understand PR #449 clarifies that 429 may concern client fingerprint and that
#444 mainly concerns post-login 403. We are not seeking IP rotation, device
identity changes, challenge bypass, or a fingerprint-impersonation workaround.
Is the existing plain-requests mobile strategy expected to remain usable in
0.3.17, and is there a maintained authorization path for a personal read-only
archive within those constraints? If provider approval is now required, please
identify the appropriate documented route. We can supply only additional
sanitized diagnostics that do not expose account data or cause another login.
Environment: Ubuntu 24.04, Python 3.12.3, garminconnect 0.3.17,
requests 2.34.2, urllib3 2.8.0, curl_cffi 0.16.3 installed but unused here.
An explicitly initiated manual login at 2026-10-07 19:18 UTC made exactly one
transmission: POST /mobile/api/login on sso.garmin.com. It received HTTP 429.
Retry-After was absent. MFA, DI exchange, and API verification were not reached.
The user reports waiting over 24 hours since the preceding attempt.
Our wrapper intentionally allows only mobile+requests, invokes the installed
_do_mobile_login(), and retains its public GCM_IOS_DARK client ID and fixed
iPhone User-Agent. It disables environment proxies, redirects, retry/fallback
transmissions after a failure, and TLS/browser impersonation strategies.
Connect/read timeout is 10/30 seconds. No token/session was created.
We understand PR #449 clarifies that 429 may concern client fingerprint and that
#444 mainly concerns post-login 403. We are not seeking IP rotation, device
identity changes, challenge bypass, or a fingerprint-impersonation workaround.
Is the existing plain-requests mobile strategy expected to remain usable in
0.3.17, and is there a maintained authorization path for a personal read-only
archive within those constraints? If provider approval is now required, please
identify the appropriate documented route. We can supply only additional
sanitized diagnostics that do not expose account data or cause another login.