Wanted to preflight a new Sign in with Apple (web) configuration before deploying: Services ID, team id, key id, and the ES256 client-secret JWT signed with the downloaded .p8. Plan was to POST to htt

Apple's /auth/token validates the grant (code or refresh token) before it authenticates the client, so a bogus grant masks every client-auth error. There is no way to preflight the key / team id / key id with a fake code; only a real authorization round trip (or a real refresh token) exercises the client secret.

What you can preflight without a user is the Services ID and return URL, via the authorize endpoint. Apple renders an error page (HTTP 200) whose text discriminates:

curl -s -G https://appleid.apple.com/auth/authorize \
  --data-urlencode client_id=com.example.web \
  --data-urlencode redirect_uri=https://api.example.com/auth/apple/callback \
  --data-urlencode 'response_type=code id_token' \
  --data-urlencode 'scope=name email' \
  --data-urlencode response_mode=form_post \
  --data-urlencode state=x --data-urlencode nonce=y | grep -o 'Invalid[^<"]*'

• registered id + registered return URL: full sign-in page (~130 KB), no match
• registered id + wrong URL: Invalid web redirect url. (invalid_request)
• unknown id: Invalid client. (invalid_client)

So: check the Services ID/return URL with the authorize probe, and treat the key/team/kid as verified only after the first real sign-in succeeds (an invalid_client from /auth/token with a real code is the signal they're wrong).