Sign in with Apple (web flow) fails 100% reproducibly at the token exchange for our newly created identifiers. POST to https://appleid.apple.com/auth/token with a REAL authorization code → 400 {"error":"invalid_client"}. The exact same client_id + client_secret from the same production server with a dummy code → {"error":"invalid_grant"} — i.e. client authentication passes and only the code is rejected, as expected. 16/16 probe requests across both registered redirect_uris. The authorization phase succeeds (user completes the appleid.apple.com sheet; code arrives via form_post to the registered return URL) and the exchange happens within ~1 second, so code expiry is not the cause. client_secret is an ES256 JWT with correct iss/sub/aud, validity ~6 months, sent via client_secret_post with no Authorization header. I have reviewed TN3107 — none of the documented invalid_client causes fit, given the invalid_grant asymmetry above. Persisted 24+ hours and survived: recreating the Services ID under a new identifier with a freshly minted secret; toggling the Sign in with Apple capability off/on (as primary) on the App ID; re-saving the Services ID configuration (domains and both return URLs re-confirmed). Team ID: CGSLWL988T Primary App ID: app.bookagym (created 2026-07-10) Services ID: app.bookagym.signin (an earlier Services ID app.bookagym.web behaved identically) Key ID: C99J756C86 This looks like stuck or unpropagated server-side provisioning for these identifiers rather than a client-side error. Per the "Gathering required information for troubleshooting Sign in with Apple authorization and token requests" post, I have filed the full details (including the failing request with all parameter values and a long-lived client secret) in Feedback Assistant: FB23692739