Sign in with Apple: "Sign Up Not Completed" for every App ID in our team — framework returns canceled (1001) with empty userInfo

I'm having the same issue. I even coded a test app specifically with no other features because I've had the issue a couple times in a row. Same issue occurred with minimal code. Appears to be a token issue (apple not issuing sign-in token from server), specifically on Apples side.

I should add, this appears to only be occurring with new apps created around the time the first post in this thread was posted.

Update with Accounts/AuthKit sysdiagnose evidence from TestFlight 1.0.0 (5): LAYR now has the exact failure signature reported by other affected teams. On 2026-08-22 at 01:49:49 and 01:57:20 +0800, akd derived the correct identifiers from the signed app: clientID: cc.brue.layr
 teamID: 5RCJW4N328
 It then logged: Fetching developer team for client with ID: cc.brue.layr
AKSQLError Code=-6003
No applications were found with the provided Client ID: cc.brue.layr The Apple network request itself completed successfully with HTTP 200, but Apple’s AuthKit response was: ec = -24000
 em = Invalid client.
 ptxid ab797933-b4db-443c-ba9e-9667d10db920
 ptxid 43bf2953-2933-4cef-b3ff-3131131f8bc2
 For the second capture, biometric authentication completed successfully immediately before this response. AuthKit then returned authorization (null); no Apple credential or identity token reached LAYR. We also removed and re-added the Sign in with Apple capability, deleted the old distribution profile, generated a fresh App Store profile, rebuilt, and uploaded build 5. The signed binary still contains application-identifier = 5RCJW4N328.cc.brue.layr and com.apple.developer.applesignin = [Default]. The fresh build fails identically. This rules out the app backend, JWT/client-secret generation, and stale provisioning as the failure point. @Paris X Pinkney, could Apple please repair/re-provision the server-side Sign in with Apple registration lookup for Team 5RCJW4N328, App ID 3F7B7MNFHY, bundle cc.brue.layr? A fresh sysdiagnose is available.

Same issue for our team — and the flow has never once succeeded, starting from our very first attempt.

Team ID: AJ36Q485L4 (Individual, enrolled August 2026). Client ID / bundle: com.tcndtht.outpawtient (the team's only App ID, APPLE_ID_AUTH enabled as primary App ID).

The signature matches this thread exactly: the sheet renders fully, Face ID succeeds, then "Sign-Up not completed"; zero requests reach our backend. Two different personal Apple Accounts (2FA) on two different iPhones; Sign in with Apple works in other apps on the same devices at the same minute. Entitlement verified in the signed binary and embedded profile; agreements accepted; removing and re-adding the capability on 23 Aug 2026 (profile reissued) changed nothing. The public authorize endpoint returns a bare 403 Forbidden for our client_id — identical to a nonexistent client — while a known-good client id from the same network renders the normal sign-in page.

Filed as FB24490686. We would appreciate the same server-side registration fix being applied to our team.

We are hitting the same issue. Team ID 7XWPRV3856, App IDs com.fixli.user.me and com.fixli.me, both registered 2026-08-18. Native sheet authenticates with Face ID, then "Sign Up Not Completed" / ASAuthorizationError.canceled (1001) with empty userInfo, on TestFlight builds on physical devices.

Entitlement com.apple.developer.applesignin verified present in the signed binaries and embedded provisioning profiles; PRIMARY_APP_CONSENT confirmed via the App Store Connect API; capability re-registered and both App Store profiles regenerated on 2026-08-25 with no change. Fails identically with Share My Email and Hide My Email.

Filed as FB24504006 (screen recording attached; sysdiagnose with the Accounts/AuthKit profile to follow — the affected devices are with remote testers).

Requesting the same server-side registration repair applied to the other teams in this thread.

Same issue, same signature — Team ID F3THR995U3, bundle ID com.todaywe.app (App Store Connect app 6801750747), App ID created 2026-08-15.

Native sheet renders, user authenticates and gets through the name / Hide My Email step, then "Sign Up Not Completed"; ASAuthorizationError 1000/1001 with empty userInfo; zero requests reach our backend. Reproduced by App Review on iOS 26.6 / 26.6.1 / iPadOS 26.6 across three builds; rejected four times under 2.1(a). Capability (APPLE_ID_AUTH, PRIMARY_APP_CONSENT) and the applesignin entitlement in both the embedded profile and the code signature of the submitted binary are verified; all agreements active; removing and re-adding the capability did not help.

Feedback ID: FB24504521. Requesting the same server-side team registration fix that resolved GW7XA5CX69 and FRL3DTJQ62. Thank you.

Same issue, same signature - Team ID 8U9TDRFRQL, bundle ID org.bldsf.community (App Store Connect app 6804963217), Sign in with Apple capability enabled on the App ID 2026-08-25.

Native sheet renders, Face ID authenticates, then "Sign Up Not Completed"; zero requests reach our backend (our /auth/apple endpoint logs nothing, and an unrelated empty POST to it still answers its normal 401, so the route is up and reachable).

akd on device, 2026-08-25 20:45:57 -0700, TestFlight build 1.0.0 (6), iPhone 14 Pro on iOS 26.6:

akd Client has default access level in SiwA entitlement akd Fetching developer team for client with ID: <private> akd Encountered error while fetching developer team: Error Domain=AKSQLError Code=-6003 akd No applications were found with the provided Client ID: <private>

Note the entitlement is read correctly on-device immediately before the team lookup fails.

Verified on our side: com.apple.developer.applesignin = [Default] is present both in the code signature of the submitted binary (codesign -d --entitlements) and in the embedded provisioning profile; the identifier is configured as "Enable as a primary App ID", not grouped under another primary and not a wildcard; the bundle contains no app extensions that could be missing the entitlement; the bundle ID matches the aud we validate.

This App ID is new - the capability was enabled the day before the failure - which matches the pattern others have reported here.

Requesting the same server-side team registration fix that resolved GW7XA5CX69 and FRL3DTJQ62. Happy to supply a sysdiagnose or a GSA ptxid if that helps locate the server logs. Thank you.

Adding another affected team: T84UX6J624 (Cilantro & Co., LLC), App ID com.cilantroco.hipiconica.

Same signature as the rest of the thread. The system sheet renders, the user authenticates with Face ID, the sheet then shows "Sign Up Not Completed", and no credential is returned — ASAuthorizationError .canceled (1001) with an empty userInfo. Zero requests reach our backend; our server logs show no failed authentication attempts at all. Reproduced on two physical devices with two different standard (non-managed) Apple Accounts.

Ruled out on the client side:

• APPLE_ID_AUTH with PRIMARY_APP_CONSENT on the App ID, read back from the App Store Connect API. Explicit primary App ID; no wildcard and no grouped identifiers.
• com.apple.developer.applesignin = ["Default"] verified inside the signed binary with codesign -d --entitlements, not just in the portal.
• We diffed a build from 20 August that authenticated successfully against a build from 25 August that fails: identical embedded provisioning profile (same UUID, same creation date), identical signing certificate, identical entitlements, identical linked frameworks. The only delta between them is unrelated JavaScript.
• Agreements active, membership in good standing; Apple System Status shows Sign in with Apple as available.

So a binary that signed in successfully on 23 August now fails, with nothing changed in our Sign in with Apple configuration or signing chain.

A device-free reproduction, with controls. Following DanCue's note about the public authorize endpoint, this can be checked with a plain HTTP request — no device, no logging profile, no build. Captured 2026-08-26 06:49 UTC against appleid.apple.com/auth/authorize, varying only client_id and holding every other parameter fixed:

• com.cilantroco.hipiconica (ours) — invalid_client, "Invalid client."
• host.exp.Exponent — invalid_request, "Invalid client id or web redirect url."
• com.burbn.instagram — invalid_request, "Invalid client id or web redirect url."
• com.cilantroco.definitely-not-real-abc123 (never registered) — invalid_client, "Invalid client."

Known-good Sign in with Apple clients get past client validation and are rejected on the redirect URL instead. Our registered App ID is rejected at the same stage, with the same wording, as a bundle identifier that has never existed — which is the em = "Invalid client." that Ozvern, moty66 and nazacheres captured in the GSA response on device, reachable without one. Offering it in case it is a useful triage shortcut for others here; DanCue reported this flipping the moment their team was re-provisioned.

This is also blocking us in App Review: our 1.0.10 submission was rejected under Guideline 2.1(a), "An error appeared when attempting to log in with Apple", because the reviewer hit this same failure. We have had to disable Sign in with Apple in production so that users can sign in at all — and Google with it, per 4.8.

Developer Support case: 20000147837597.

@Paris X Pinkney — could the same server-side team registration fix applied to GW7XA5CX69 and FRL3DTJQ62 be applied to T84UX6J624? Happy to verify and confirm immediately, and to attach a sysdiagnose with the Accounts/AuthKit profile if that would help.

Same issue here. New app, first sign-up always ends with "Sign-Up not completed" / ASAuthorizationError 1001 with empty userInfo. Entitlement verified in the signed binary and embedded profile, APPLE_ID_AUTH with PRIMARY_APP_CONSENT, capability re-created, fresh distribution profile - no change, exactly as described in this thread.

Team ID: 6228UNL5HZ Bundle ID: com.axperts.arkanum Feedback: FB24533304

Adding our team to this incident — same server-side signature.

Team ID: V27S6U8U5M Bundle ID: com.yogen.listentome.ios (native iOS app, Sign in with Apple via ASAuthorizationController) Feedback: FB24533367

Symptom: native Sign in with Apple fails on a physical device with Apple's "Sign Up Not Completed" sheet, before any credential is returned to the app. First observed 2026-08-26 (US Eastern) and still reproducing.

Exact error chain from akd on device:

• AKAuthenticationError Code=-7026, AKClientBundleID=com.yogen.listentome.ios
• underlying AKSQLError -6003 "No applications were found with the provided Client ID"
• surfaced to the app as com.apple.AuthenticationServices.AuthorizationError Code=1000

Configuration is verified correct on our side:

• Sign in with Apple capability enabled on the explicit (non-wildcard) App ID with primary app consent
• com.apple.developer.applesignin = [Default] present in BOTH the signed binary and the embedded App Store provisioning profile
• Reproduced with a normal personal Apple ID that has two-factor authentication enabled (not a managed or child account)
• Simulator excluded (no device attestation); this is a physical-device failure

This matches the pattern described in this thread exactly — a correct, unchanged build that Apple's ID servers reject with the "No applications were found with the provided Client ID" signature.

Could DTS please associate Team ID V27S6U8U5M / bundle ID com.yogen.listentome.ios with the server-side Sign in with Apple registration repair? This is currently blocking our App Store submission under Guideline 4.8. Feedback FB24533367 has the full details. Thank you.

Same signature here. Team 9MZTYK3NV9, bundle com.myboxmp.donopalier (App ID registered 2026-08-22, Sign in with Apple enabled 2026-08-25).

Native sheet shows "Sign Up Not Completed", the app receives ASAuthorizationError.canceled (1001), no credential is issued, backend is never reached. Reproduced on two iPhones with two independent Apple Accounts that had never signed in to this app; both accounts work with Sign in with Apple in other teams' apps on the same devices.

Verified: entitlement present in both the profile and the signed binary (read from the distributed IPA), PRIMARY_APP_CONSENT via the API, single ACTIVE profile, agreements accepted, four TestFlight builds fail identically with no code changes.

Filed FB24538045. Requesting the same server-side check that resolved GW7XA5CX69 and FRL3DTJQ62.

Still affected as of 27 August 2026 — could Apple apply the same server-side team-registration fix here?

Team ID: A7L782V843 Bundle ID: com.perfectlyhuman.chezmoi TestFlight: 1.0.1 (9) Device: iPhone, iOS 26.0 (23F84)

The native Sign in with Apple sheet opens and authentication completes, but the sheet then shows “Sign Up Not Completed.” The app receives AuthenticationServicesCore.AuthorizationError Code=2 / a cancellation-style result and no identity token, so no request reaches Supabase or our backend.

The App ID has APPLE_ID_AUTH enabled as a primary App ID, and the signed binary and embedded provisioning profile include com.apple.developer.applesignin = [Default]. We have a sysdiagnose captured immediately after reproducing the failure and can provide it privately on request.

This matches the resolved reports in this thread; no app-side configuration change has resolved it for us.

Team H5FEGHMVQ5, bundle com.briandaneshgar.dot. Sign in with Apple fails every time on device, on both ad-hoc and TestFlight builds. The sheet renders, authentication succeeds, then "Sign Up Not Completed" and the framework returns AuthorizationError 1000 with no underlying error. Client side is verified: the applesignin entitlement is in the signed binary, the App ID has the capability as a primary App ID, both profiles were regenerated after enabling it, and the capability has been deleted and re-created. No Dot entry exists under the Apple ID's Sign in with Apple list. This matches forum thread 837986, where affected teams were fixed by a server side re-provisioning of the Sign in with Apple registration. Please do the same for this team.

Adding another affected team to this thread.

Team ID: 6W53S3F2XM Bundle ID: ph.richtek.adamm App: ADAMM (HRIS ESS mobile app)

Sign In with Apple capability is enabled and confirmed "Enable as a primary App ID" (non-wildcard). Entitlement verified present in the actual signed/uploaded TestFlight binary (com.apple.developer.applesignin = ["Default"]).

Every attempt fails with "Sign Up Not Completed" after Face ID/password confirmation succeeds — reproduced on two physical devices and two different Apple IDs, both with 2FA enabled, neither Apple ID shows any existing entry under "Apps Using Apple ID" for this app. Google Sign-In and password login both work normally on the same builds, so this is isolated to Sign in with Apple specifically.

Would appreciate the same server-side team registration check that resolved this for the teams above. Happy to provide sysdiagnose/ptxid if needed.

Hello,

I just want to inform that i will be closing FB24150280 since it is now working (with no changes on my side)

Thank you

Adding another affected team with the same web-flow signature.

Team ID: PPQ8HG3N23 Primary App ID: com.hikond.atune Services ID: com.hikond.atune.web

From atune.hikond.com, Apple’s authorization sheet appears and Touch ID completes, then “Sign Up Not Completed”. Supabase logs the /authorize 302 redirect to Apple, but Apple never POSTs to the registered callback, so no credential or session reaches the backend.

Verified: the Services ID is linked to the primary App ID; the exact domain and return URL are saved; both client IDs are configured with the web Services ID first; and Apple client authentication is accepted. Native Sign in with Apple for the same account already works.

Filed as FB24551300. Could Apple please apply the same server-side Sign in with Apple registration repair/re-provisioning that resolved other affected teams in this thread? Thank you.

Same issue, same signature, another affected team.

Team ID: 5M99CP7ZXJ · Bundle IDs: com.speechscan.app and com.speechscan.app.siwatest · Individual membership activated 2026-08-28 by upgrading the existing Personal Team under the same Team ID. Device: iPhone 17 Pro, iOS 27.0, Xcode 26.6, development build.

Native sheet renders, Face ID completes, then "Sign Up Not Completed" — ASAuthorizationError 1001, no credential returned, and zero requests reach our identity provider. Device logs show "M2 missing (bad password)" → SRP authentication failure → AKAuthenticationServerError -24000. The public authorize endpoint returns "Invalid client" for both App IDs.

Ruled out client-side: com.apple.developer.applesignin = ["Default"] verified in the signed binary and embedded provisioning profile; Sign in with Apple enabled as a primary App ID; capability off/on toggle and regenerated profiles changed nothing. A brand-new explicit App ID and a minimal request with no scopes or nonce fail identically. The same Apple Account completed a first-time Sign in with Apple authorization in another team's app on the same device minutes later.

Note on logs: we could not install the Accounts/AuthKit profile — developer.apple.com answers "Your account can't access this page" for the profiles-and-logs page on this paid account, which also disables the on-device sysdiagnose shortcut, and xcrun devicectl device sysdiagnose fails with CoreDeviceCLISupport.DiagnoseError error 0. FB24551524 therefore carries a filtered log collect excerpt instead. Happy to capture it another way if that blocks triage.

Feedback Assistant: FB24551524

Sign in with Apple: invalid_client at /auth/authorize

Please investigate the Sign in with Apple registration on Apple's authentication backend for the identifiers below. The Developer portal configuration appears correct, but public authorization requests are rejected before the user can sign in.

Identifiers and verified configuration

• Developer Team ID: WW9948F28Q
• Primary App ID / bundle identifier: com.doorsfps.mobile
• App ID resource identifier: K3248JASVU
• Services ID: com.doorsfps.mobile-service
• Services ID resource identifier: GCF5G4KPN4
• Primary App ID has Sign In with Apple enabled with "Enable as a primary App ID".
• Services ID has Sign In with Apple enabled and is associated with the DoorsFPS primary App ID.
• Website domain: clerk.doorsfps.com
• Return URL: https://clerk.doorsfps.com/v1/oauth_callback
• After leaving and reopening the service configuration, both URLs are present. Apple's confirmation page reports "2 Website URLs".
• Clerk production Apple Services ID and Return URL match the values above.

Reproduction independent of Clerk

This public request sends no private key, client secret, cookies, Apple account credentials, or authorization code. The state below is a diagnostic placeholder, not a live Clerk sign-in state. Do not complete an Apple sign-in using this diagnostic request; restart sign-in from the application for an actual login.

curl --get 'https://appleid.apple.com/auth/authorize' \
  --data-urlencode 'client_id=com.doorsfps.mobile-service' \
  --data-urlencode 'redirect_uri=https://clerk.doorsfps.com/v1/oauth_callback' \
  --data-urlencode 'response_type=code' \
  --data-urlencode 'response_mode=form_post' \
  --data-urlencode 'scope=name email' \
  --data-urlencode 'state=doors-apple-diagnostic'

Expected: Apple accepts the registered client and presents the sign-in flow.

Actual: Apple returns an HTML error page containing invalid_client and Invalid client. The HTTP transport status is 200; Apple's response headers carry the following error information:

An additional diagnostic request with client_id=com.doorsfps.mobile and the same remaining parameters also returned invalid_client:

The App ID request is supplementary diagnostic evidence; the production Clerk web flow remains configured with the Services ID. No token-exchange or native-app sign-in test was performed.

Request

Please check whether the primary App ID and Services ID are correctly registered and available to the Sign in with Apple authentication servers, including any team or identifier provisioning issue. We cannot confirm the backend cause from the client side.

Apple's TN3107 describes authorization-stage invalid_client as an inability to find the primary app or web service for the supplied client ID. Recent reports in the following Apple Developer thread describe related client lookup failures; Apple staff responded to affected developers, and developers reported resolution without client changes. These reports are supporting context, not proof that this account has the same cause.

• https://developer.apple.com/documentation/technotes/tn3107-resolving-sign-in-with-apple-response-errors
• https://developer.apple.com/forums/thread/837986

This note intentionally excludes private keys, cookies, session identifiers, and live OAuth state values. No configuration was changed or credentials rotated during these checks, and this report has not been submitted to Apple.

Same issue for our team. Team ID R38MU4M743, bundle ID com.happeninlabs.there, App ID created August 2026. Native sheet shows "Sign Up Not Completed", ASAuthorizationError.canceled (1001) with empty userInfo, no credential issued. Entitlement, PRIMARY_APP_CONSENT capability, explicit profile, and agreements all verified; same Apple ID works with Sign in with Apple in other apps on the same device. Filed FB[your new FB number] with sysdiagnose (Accounts profile installed) captured during a failing attempt. Could you apply the same server-side fix that resolved GW7XA5CX69 and FRL3DTJQ62?

Adding another affected team: FMC5MLL736 (Bridgefy Inc.), App ID com.bridgefy.reach

Same signature as the rest of the thread. The system sheet renders, the user authenticates with Face ID, the sheet then shows "Sign Up Not Completed", and no credential is returned — ASAuthorizationError .canceled (1001) with an empty userInfo. Reproduced on two physical devices with two different Apple Accounts

Same signature here, filed as FB24555833 (2026-08-28). Team D378298BB5, primary App IDs com.dozeling.babymonitor (App Store Connect app 6806311606, TestFlight 2.19.1 (33)) and app.pestka (capability enabled 2026-08-23) — both fail identically on iPad (10th gen) iPadOS 26.6 and iPhone 12 Pro Max iOS 26.6 with the native sheet showing "Sign-Up not completed" right after successful Face ID/Touch ID consent; the app receives neither a credential nor an ASAuthorizationError.

akd trace: AKAuthorizationStore lookup (AKSQLError -6003, first sign-up, local) → sheet → biometric OK → No password, but CK is available → SRP → AppleIDAuthSupport: setError: 2:M2 missing (bad password) → SRP authentication with server failed Code=2 → AKAuthenticationError -7003.

Ruled out: entitlement com.apple.developer.applesignin = [Default] in the signed binary and both profiles, PRIMARY_APP_CONSENT via API and portal, regenerated profiles, no Services IDs / wildcard overlap, agreements active, System Status clean, Apple ID signed out/in on device.

Control: the same Apple ID completes Sign in with Apple in another team's app (LEGO Builder) on the same iPad — so the account and device are fine and the failure is specific to this team's apps.

Traces attached to the FB. Happy to provide sysdiagnose with the Accounts/AuthKit profile if needed.

Same signature, new team - Sign in with Apple has never once succeeded for our App ID.

Team ID: 9KN225R3Z2 Bundle ID: me.foodsaver.kcalsnap (App ID created 2026-08-24)

The sheet renders with the correct app name and Apple Account, authenticates with Face ID, then shows "Sign-Up Not Completed"; the framework returns ASAuthorizationError 1001 with empty userInfo. No identity token is ever issued, so nothing server-side of ours is involved.

Reproduced with two independent Apple IDs on two devices: our own iPhone on iOS 26.6, and an App Review device (iPad Air 11-inch M3, iPadOS 26.6.1, Touch ID) during review of our submission. The same Apple ID signs in with Sign in with Apple in other developers' apps on the same device.

Verified on our side:

• APPLE_ID_AUTH capability enabled with APPLE_ID_AUTH_APP_CONSENT = PRIMARY_APP_CONSENT (checked over the App Store Connect API, not just the portal UI).
• com.apple.developer.applesignin = ["Default"] present in the signed binary, verified with codesign -d --entitlements on the exact .ipa that was uploaded for review.
• isAvailableAsync() returns true and the sheet displays our app name, so the client reaches ASAuthorizationAppleIDProvider normally.
• On 2026-08-29 we deleted and re-created the APPLE_ID_AUTH capability and regenerated the App Store provisioning profile. Retested on a fresh TestFlight build on 2026-08-30: identical failure.

Impact: our 1.0 submission was rejected under guideline 2.1 because the reviewer could not complete Sign in with Apple. We have had to remove both Sign in with Apple and Google Sign-In to resubmit, since guideline 4.8 does not allow Google Sign-In without a working Sign in with Apple.

Requesting the same server-side re-provisioning that resolved this for GW7XA5CX69 and FRL3DTJQ62. Filing a Feedback Assistant report and will post the FB number here.

Feedback filed: FB24574712 (team 9KN225R3Z2, bundle ID me.foodsaver.kcalsnap, App ID created 2026-08-24). Happy to attach a sysdiagnose with the Accounts logging profile if that helps correlate the transaction on your side.

Same issue and the same server-side signature on a new, unreleased App ID.

App ID resource ID: GUYR4794T9 (The app name and bundle identifier are intentionally omitted from this public post. I can provide them privately to Apple.)

The native Sign in with Apple sheet appears normally and Face ID succeeds, but it then shows “Sign Up Not Completed.” No credential is returned, and no request reaches our backend.

A device sysdiagnose shows AKSQLError -6003 (“No applications were found with the provided Client ID”), followed by AppleIDAuthSupport Code 2 (“M2 missing”) and AKAuthenticationServerError -24000.

The App Store Connect API reports APPLE_ID_AUTH with PRIMARY_APP_CONSENT. The signed TestFlight binary and embedded provisioning profile both contain com.apple.developer.applesignin = ["Default"].

Could an Apple DTS engineer please inspect and re-provision the server-side Sign in with Apple registration for App ID resource ID GUYR4794T9? I can provide the Team ID, full sysdiagnose, and exact reproduction timestamps privately.

Same failure signature here. Adding our team to the list.

Team ID: S9S87W59A8 Bundle ID: com.agora.fr App ID resource: TP9N3B3CWR

Symptom: the native ASAuthorizationAppleIDProvider sheet renders, names the app, offers name and email, then shows "Sign Up Not Completed". The delegate returns ASAuthorizationError.canceled with an empty userInfo and no NSUnderlyingError, so nothing diagnosable reaches the app. Device logs show AKAuthenticationServerError -24000 "Invalid client." with HTTP status 200.

Native only. No Services ID, no web flow, no grouping. Explicit primary App ID. APPLE_ID_AUTH is enabled with APPLE_ID_AUTH_APP_CONSENT / PRIMARY_APP_CONSENT, enabled on 2026-08-29, which puts us in the same window as the other reports here. Failure appeared immediately and has been continuous since.

Verified on our side, all of it measured rather than assumed:

• com.apple.developer.applesignin = ["Default"] present in the signed binary and in the embedded provisioning profile (S9S87W59A8.com.agora.fr)
• capability read back through the App Store Connect API, settings intact
• developer agreements: there was one pending, it has been accepted, no change
• capability removed and re-added through the App Store Connect API, with the provisioning profile regenerated afterwards (xcodebuild -allowProvisioningUpdates), no change
• eas credentials capability sync reports "Synced capabilities: No updates", a third independent confirmation that the configuration matches Apple's records
• tested with and without a nonce, and with both shared and hidden email, all identical
• Apple system status shows no incident on Sign in with Apple, Apple Account or Certificates, Identifiers & Profiles

Data point that may help narrow it: Sign in with Apple completes normally in OTHER apps on the same device with the same Apple ID. Only this App ID fails, which matches the client ID lookup failure described earlier in this thread.

Could Apple please apply the same server-side Sign in with Apple registration repair that resolved GW7XA5CX69 and FRL3DTJQ62 to Team ID S9S87W59A8?