GSA authentication consistently returns HTTP 503 with FindMy.py 0.10.1

[Medicus91]

Hi,
I'm trying to use FindMy.py through the hass-FindMy Home Assistant integration, but authentication consistently fails during the initial GSA authentication with HTTP 503.
The error occurs before reaching 2FA.
Error:

findmy.errors.UnhandledProtocolError: Error response for GSA request: 503

The traceback points to:

AsyncAppleAccount.login()
→ _gsa_authenticate()
→ _gsa_request()

Environment 1 – Home Assistant

• Home Assistant Core: 2026.9.1
• Home Assistant OS
• Raspberry Pi 4B
• Architecture: aarch64
• Python: 3.14.6
• hass-FindMy: current main (993b2f2)
• FindMy.py: 0.10.1
  I tested both:
• Local Anisette
• Remote Anisette (https://ani.sidestore.io)
  Both result in the same GSA HTTP 503 response.

Environment 2 – independent WSL test
To rule out Home Assistant and the Raspberry Pi, I installed FindMy.py 0.10.1 in a clean Python virtual environment under Ubuntu/WSL:

• WSL / Ubuntu
• x86_64
• Python 3.14.1
• FindMy.py 0.10.1
• LocalAnisetteProvider
  I tested authentication directly using AsyncAppleAccount and get exactly the same result:

UnhandledProtocolError: Error response for GSA request: 503

Therefore the issue seems reproducible independently of Home Assistant, CPU architecture and operating environment.
The Apple account itself works normally on Apple devices and the iCloud website.
Is this a currently known issue with Apple's GSA endpoint, or is there anything account-specific I can check or provide for further debugging?
Thanks!

[parawanderer]

For anyone landing here on the HTTP 503 sign-in failures: the cause is known and fixed.

Apple's edge refuses any Grand Slam request whose X-MMe-Client-Info names com.apple.dt.Xcode, before any credential is examined — it returns a small HTML error page rather than a GSA plist, which reaches clients as HTTP 503 and looks like an Apple outage. Reporting the client as com.apple.akd, the daemon that actually makes this call on macOS, is answered normally.

Nothing to do with any particular account, password, network or machine. It broke every client that hardcoded the Xcode identifier, at once.

Found and isolated by AltStore: altstoreio/AltStore#1790 (shipped in AltServer 1.7.6). They established that only the app token matters — the version, the user agent and the hardware portion of the header make no difference.

Fixes per project:

• AltStore / AltServer — 1.7.6 and later
• FindMy.py — fix: report the client as akd, not Xcode, to stop Apple refusing sign-in with 503 #271
• anisette-v3-server — change auth client type from xcode to authkitd to fix 503s Dadoum/anisette-v3-server#60 (merged)

Reproducible without an account, if you want to confirm it yourself:

curl -so /dev/null -w '%{http_code}\n' -X POST --data-binary t \
  -H 'X-MMe-Client-Info: <Mac14,2> <macOS;15.7.5;24G624> <com.apple.AuthKit/1 (com.apple.dt.Xcode/3594.4.19)>' \
  https://gsa.apple.com/grandslam/GsService2      # 503

curl -so /dev/null -w '%{http_code}\n' -X POST --data-binary t \
  -H 'X-MMe-Client-Info: <Mac14,2> <macOS;15.7.5;24G624> <com.apple.AuthKit/1 (com.apple.akd/1.0)>' \
  https://gsa.apple.com/grandslam/GsService2      # 401 — it reached the service

Interactively co-authored by Claude Code and @parawanderer