Hello Everyone I'm encountering a problem with the Apple Mail Private. I created a website with the possibility to log in with apple account and apple gives the possibility to privatize the mail address with xxxxx@privaterelay. appleid.com but also blocked the mail come from my server. In the log I get the error: relay=smtp3.privaterelay. appleid.com[17.56.9.14]:25, delay=2.4, delays=0.11/0/1.8/0.48, dsn=5.1.1, status=bounced (host smtp3.privaterelay. appleid.com[17.56.9.14] said: 550 5.1.1 mymail@mail. com: unauthorized sender (in reply to RCPT TO command)) How can I fix it ?

Hello, We are preparing to transfer an App Store app from one Apple Developer account/team to another. Our iOS app uses Sign in with Apple. However, in our legacy implementation, we did not store the Apple user subject identifier (sub) for many existing Apple login users. Our service primarily matched users by email. After reviewing Apple’s app transfer and Sign in with Apple migration documentation, we understood that we should generate a transfer identifier for each Sign in with Apple user before transferring the app. We have now started collecting and storing the sub value, but many legacy Apple login users still do not have their original sub value stored in our database. We are concerned about two main cases: Legacy users whose original Apple sub value was never stored For these users, we may not be able to generate the required transfer identifier before the app transfer. If the user uses Private Relay, we are also concerned that the email address we receive after the transfer may not match the email address we previously stored. In that case, our backend may not be able to match the post-transfer Sign in with Apple login to the user’s existing account, and the user may be treated as a new account. Users whose sub value is stored, but who do not sign in during the migration period For some users, we do have the Apple sub value and may be able to generate the transfer identifier before the app transfer. However, we are not sure what happens if those users do not sign in during the available Sign in with Apple migration period after the app transfer. If they sign in only after that period has ended, will the post-transfer Sign in with Apple user still be reliably mapped to the original pre-transfer user? The scenario we are worried about is: A user originally signed in with Apple before the app transfer. The app is transferred to another Apple Developer account/team. The user does not sign in during the Sign in with Apple migration period. After the migration period has ended, the same user signs in with Apple again. Our backend receives a new Apple user identifier and/or a different Private Relay email address. Our backend cannot correlate that login with the user’s original service account. The user may be treated as a new user and may lose access to their existing profile, activity history, chats, purchases, or other account data. Could someone confirm the expected behavior? Questions: If we have a legacy sub value and generate the transfer identifier before the app transfer, can the user still be mapped to the original account if they do not sign in during the Sign in with Apple migration period? After the migration period has ended, does Apple provide any identifier, token claim, API response, or other mechanism that allows us to correlate the post-transfer Sign in with Apple user with the pre-transfer user? For legacy users whose original sub value was never stored, is there any Apple-provided way to recover or map those users after the app transfer? Can a Private Relay email address change as part of or after an App Store app transfer? Should we avoid using email as a stable identifier for this migration? Should we delay the app transfer until we implement our own account recovery and account re-linking flow for all Sign in with Apple users? Environment: Platform: iOS Development environment: Xcode Runtime: iOS Framework: AuthenticationServices Feature: Sign in with Apple Context: App Store Connect app transfer between Apple Developer teams/accounts This issue does not appear to be specific to a particular iOS or Xcode version. We expect the development and runtime environments to be using the latest available versions of Xcode, macOS, and iOS at the time of submission. Any guidance on the correct migration behavior and the recommended implementation approach would be greatly appreciated.

Hello everyone, We are currently preparing for an App Transfer to a new Apple Developer account due to a corporate merger. We are trying to figure out the best way to handle Apple Sign-In user migration and would love to get some advice on our proposed fallback plan. 📌 Current Situation We need to transfer our app's ownership to a new corporate entity. The app heavily relies on Apple Sign-In. The Issue: We did not collect the transfer_sub values during our initial development phase. Although we started collecting them recently, we will not have them for all existing users by the time the transfer happens. 🚨 The Risk (The 60-Day Rule) Based on Apple's documentation, even if we provide the transfer_sub, users must log into the app within 60 days of the transfer to successfully migrate their accounts. This means that users who log in after 60 days, or those whose transfer_sub is missing, will fail the Apple migration process. They will be treated as "new users" and will lose access to their existing account data. 💡 Our Proposed Custom Recovery Flow Since we cannot rely entirely on Apple's automated migration, we are planning to build a custom internal account recovery process to prevent user drop-off: A user (who failed the migration or logged in after 60 days) attempts to use Apple Sign-In on the transferred app. Since the existing account isn't linked, Apple generates a new identifier (sub), and the user enters the new sign-up flow. During the sign-up process, we enforce a mandatory identity verification step (e.g., SMS phone number verification). We query our existing user database using this verified information. If a matching existing user is found: We interrupt the sign-up process and display a prompt: "An existing account was found. We will link your account." We then update our database by mapping the new Apple sub value to their existing account record, allowing them to log in seamlessly. ❓ My Questions App Review Risk: Could this manual mapping approach—overwriting the Apple sub on an existing account based on internal identity verification—violate any Apple guidelines or result in an App Store rejection? Shared Experiences: Has anyone dealt with missing transfer_sub values or the 60-day migration limit during an App Transfer? How did you mitigate user loss? Best Practices: Are there any alternative, safer, or more recommended workarounds for this scenario?

Hello everyone, I’m trying to better understand the expected behavior of Sign in with Apple after an app is transferred to another Apple Developer Team. Specifically, my question is about users who do not open or sign in to the app during the 60-day migration period after the app transfer. Here is the scenario we are concerned about: An existing user created an account using Sign in with Apple. The user is using a private relay email address. The app is transferred to another Apple Developer Team. The user does not sign in during the 60-day migration period. The user signs in again only after the 60-day period has ended. In this situation, is there any possibility that Apple may provide different user-related values compared to the values before the app transfer? For example, I am referring to values such as: sub private relay email address ID token claims any other API response value that may be used to identify the user The reason I’m asking is that if any of these values change after the transfer, our backend may not be able to match the user to the existing account in our database. In that case, the user could incorrectly be treated as a new user. My understanding is that the purpose of the Sign in with Apple migration process after an app transfer is to associate the user identifier from the original Team with the user identifier for the new Team. However, I would like to confirm what happens if the user was not processed during the 60-day migration period and signs in later. Do the values provided by Apple remain consistent in this case, or can they change after the migration period ends? If they can change, should we prepare our own account recovery or re-linking flow to handle these users? I would appreciate any clarification on Apple’s expected behavior and the recommended approach for this case. Thank you.

I've been struggling with "Sign in with Apple" for days. Firebase Authentication returns "configuration not found". I've tried everything. My configuration (all verified correct): App ID: com.pome.ai Services ID: come.pome.ai Key ID: 8UXM48JT9D (newly created) Apple Team ID: KDAMDMPNAW Domain: pome-ai.firebaseapp.com Return URL: https://pome-ai.firebaseapp.com/__/auth/handler What works: Android version (Google Sign-In) works perfectly Anonymous sign-in works What I tried: Created new Service ID and Key multiple times Verified Return URL has double underscore (__) Added authorized domains in Firebase Cleared iPhone cache, reinstalled app, restarted device Tested on different networks The error occurs only on iOS when tapping "Sign in with Apple". Firebase returns "configuration not found". Any help would be greatly appreciated.

Hi everyone, I'm experiencing a persistent issue with Sign in with Apple on my iOS app that I cannot resolve from my side. I've already opened a support case (ID: 20000115382721) and received a reply directing me back to the Developer Forum, so I'm posting here in hopes someone has encountered the same issue or can offer guidance. Error message: FirebaseAuthException: [firebase_auth/invalid-credential] Invalid OAuth response from apple.com Critical observation: The Apple authentication screen never appears. When the user taps "Continue with Apple", the error is returned immediately. This suggests the request is being rejected before reaching Apple's authentication servers — pointing to a backend configuration issue on Apple's side for my Team ID. My setup: Team ID: DHKU23JL7H Bundle ID: com.expensespy.app Framework: Flutter with sign_in_with_apple package v7.0.1 Backend: Firebase Authentication Other auth methods (Google Sign-In, Email/Password): working correctly Verified configuration (all done correctly): App ID (com.expensespy.app): Sign In with Apple capability is enabled Configured as a primary App ID Not grouped with any other App ID Service ID (com.expensespy.app.auth): Created and linked to the primary App ID Domain: expensespy-e11ab.firebaseapp.com Return URL: https://expensespy-e11ab.firebaseapp.com/__/auth/handler All other redundant Service IDs have been removed Sign In with Apple Key: Created with Key ID X8T9NLBT4Y Linked to the primary App ID .p8 file is available Firebase Apple provider: Tested with OAuth code flow fields populated (Services ID, Team ID, Key ID, Private Key) — same error Tested with OAuth code flow fields empty (recommended for iOS-only) — same error Client-side implementation: Proper nonce generation with SHA256 hashing OAuthProvider('apple.com').credential() with idToken and rawNonce Tested across 3 different builds (Build 12, 13, 14) Tested on multiple iOS devices (iOS 18+) What I've ruled out: Client-side code (tested 3 different implementations) Firebase configuration (tested both populated and empty) Multiple Service IDs (cleaned up to just one) App ID configuration (verified primary status) Context: During my Apple Developer Program enrollment, I experienced an error that was not fully resolved. I suspect this may have left my account in a state where Sign in with Apple is not fully activated on the Apple backend for my Team ID. Question: Has anyone encountered this where the Apple auth screen never appears at all? Is there a way to verify that Sign in with Apple is properly provisioned for a specific Team ID on Apple's backend? My App Store submission is blocked by this since Sign in with Apple is required when offering third-party authentication. Any guidance from Apple engineers or developers who solved a similar issue would be deeply appreciated. Thanks!

When i request 'https://appleid.apple.com/auth/keys' via my browser I do get 3 keys, But requesting from several cloud providers i get only a bogus reply: { "url": "https://appleid.apple.com/auth/keys" } Why is that? I'm using a very bare bones node request: fetch('https://appleid.apple.com/auth/keys');

Hello, I’m trying to remove the “Sign in with Apple” for my app via the iOS settings (also tried on a Mac, and on the web via account.apple.com). When I tap “Stop Using”, nothing happens, the dialog disappear but the app remains listed. Someone said on a forum that the issue is linked with the ServiceId that doesn't exist anymore. But how to recover it ? And anyway this behavior is unintended and creates a gap in the process. Has anyone experienced this before? Is there a known fix, or should I contact Apple Support directly for server-side revocation? Thank you!

We are experiencing an issue with Apple’s Private Email Relay service for Sign in with Apple users. Our setup details are as follows: • Domain: joinalyke.com • Domain successfully added under “Sign in with Apple for Email Communication” • SPF verified • DKIM enabled (2048-bit Easy DKIM via AWS SES) • Emails are being sent from S***@joinalyke.com Amazon SES confirms that emails sent to users’ @privaterelay.appleid.com addresses are successfully delivered (Delivery events recorded in SES and no bounce reported). However, users are not receiving the forwarded emails in their actual inboxes. Since: SES shows successful delivery, SPF and DKIM are properly configured, Domain is registered in the Apple Developer portal, we suspect that the Private Email Relay service may be blocking or not forwarding these emails. Could you please investigate whether: Our domain or IP reputation is being blocked or filtered, There are additional configuration requirements, The relay service is rejecting emails after acceptance, There are content-related filtering policies we should review. We are happy to provide message IDs, timestamps, and sample relay email addresses if required.

PLATFORM AND VERSION iOS Development environment: Xcode 26.2, macOS x Run-time configuration: iOS The issue does not seem to be limited to a specific version. DESCRIPTION OF PROBLEM We are reaching out to request in-depth technical assistance regarding an intermittent issue with Sign in with Apple implementation in our application. [Technical Status] We have confirmed that our technical implementation is correct. All necessary code and Xcode Capabilities are properly configured, and the service is working perfectly for the vast majority of our users. However, a small subset of users is consistently encountering "Unknown" Error (Error Code 1000), which prevents them from logging in entirely. [Identified Scenario] Currently, the only reproducible case we have found involves Child Accounts (protected accounts) under Family Sharing, specifically when the user's age is set below the regional requirement for a standalone Apple ID. However, we are receiving reports from other users who do not seem to fall into this category. [Requests for Clarification] To resolve this issue and support our users, we would like to obtain clear answers to the following questions: Root Cause: Why does Error 1000 occur specifically for a small number of users while the service works for most others? Other Scenarios: Are there any known cases or conditions other than the "Child Account" age restriction that trigger this specific error? Account-side Issues: If our code and configurations are verified to be correct, should we conclude that this is an issue specific to the individual's Apple ID/Account status? If so, could you provide a troubleshooting guide or official recommendation that we can share with these users to help them resolve their account-related issues? We are committed to providing a seamless authentication experience and would appreciate your expert insight into these edge cases. Thank you for your support. - (void) quickLogin:(uint)requestId withNonce:(NSString *)nonce andState:(NSString *)state { #if AUTHENTICATION_SERVICES_AVAILABLE if (@available(iOS 13.0, tvOS 13.0, macOS 10.15, *)) { ASAuthorizationAppleIDRequest *appleIDRequest = [[self appleIdProvider] createRequest]; [appleIDRequest setNonce:nonce]; [appleIDRequest setState:state]; ASAuthorizationPasswordRequest *keychainRequest = [[self passwordProvider] createRequest]; ASAuthorizationController *authorizationController = [[ASAuthorizationController alloc] initWithAuthorizationRequests:@[appleIDRequest, keychainRequest]]; [self performAuthorizationRequestsForController:authorizationController withRequestId:requestId]; } else { [self sendsLoginResponseInternalErrorWithCode:-100 andMessage:@"Native AppleAuth is only available from iOS 13.0" forRequestWithId:requestId]; } #else [self sendsLoginResponseInternalErrorWithCode:-100 andMessage:@"Native AppleAuth is only available from iOS 13.0" forRequestWithId:requestId]; #endif } - (void) loginWithAppleId:(uint)requestId withOptions:(AppleAuthManagerLoginOptions)options nonce:(NSString *)nonce andState:(NSString *)state { #if AUTHENTICATION_SERVICES_AVAILABLE if (@available(iOS 13.0, tvOS 13.0, macOS 10.15, *)) { ASAuthorizationAppleIDRequest *request = [[self appleIdProvider] createRequest]; NSMutableArray *scopes = [NSMutableArray array]; if (options & AppleAuthManagerIncludeName) [scopes addObject:ASAuthorizationScopeFullName]; if (options & AppleAuthManagerIncludeEmail) [scopes addObject:ASAuthorizationScopeEmail]; [request setRequestedScopes:[scopes copy]]; [request setNonce:nonce]; [request setState:state]; ASAuthorizationController *authorizationController = [[ASAuthorizationController alloc] initWithAuthorizationRequests:@[request]]; [self performAuthorizationRequestsForController:authorizationController withRequestId:requestId]; } else { [self sendsLoginResponseInternalErrorWithCode:-100 andMessage:@"Native AppleAuth is only available from iOS 13.0" forRequestWithId:requestId]; } #else [self sendsLoginResponseInternalErrorWithCode:-100 andMessage:@"Native AppleAuth is only available from iOS 13.0" forRequestWithId:requestId]; #endif } - (void) getCredentialStateForUser:(NSString *)userId withRequestId:(uint)requestId { #if AUTHENTICATION_SERVICES_AVAILABLE if (@available(iOS 13.0, tvOS 13.0, macOS 10.15, *)) { [[self appleIdProvider] getCredentialStateForUserID:userId completion:^(ASAuthorizationAppleIDProviderCredentialState credentialState, NSError * _Nullable error) { NSNumber *credentialStateNumber = nil; NSDictionary *errorDictionary = nil; if (error) errorDictionary = [AppleAuthSerializer dictionaryForNSError:error]; else credentialStateNumber = @(credentialState); NSDictionary *responseDictionary = [AppleAuthSerializer credentialResponseDictionaryForCredentialState:credentialStateNumber errorDictionary:errorDictionary]; [self sendNativeMessageForDictionary:responseDictionary forRequestId:requestId]; }]; } else { [self sendsCredentialStatusInternalErrorWithCode:-100 andMessage:@"Native AppleAuth is only available from iOS 13.0" forRequestWithId:requestId]; } #else [self sendsCredentialStatusInternalErrorWithCode:-100 andMessage:@"Native AppleAuth is only available from iOS 13.0" forRequestWithId:requestId]; #endif }

Could you tell me about account security and passkeys? Our service is considering implementing passkeys, and these questions are to understand how Apple protects accounts from third parties. ① Apple website states that two-factor authentication is mandatory for newly created Apple Accounts. When did this requirement come into effect? What are the conditions for users who do not have two-factor authentication enabled? ② Apple website mentions that a verification code may be required when signing into an Apple Account from a new device or browser. Is my understanding of the situations where a verification code is requested accurate, as listed below? Are there any other situations? Completely signing out of the Apple Account on that device. Erasing the device. Needing to change the password for security reasons. ③ If a user is already using a passkey on an Apple device, and then upgrades to a new device, will additional authentication, such as entering a PIN code, be required to use the passkey on the new device?

Hello, We are building a new app that would be kinda extension of the other and we want to let our community share the same account in between. We use Apple Sign in and we want Appel sign in system to give the same identity when people use apple relay. One of our app is alreadey released, can we still do it to share the same Apple login?

a I am submitting this appeal because we believe our app was misunderstood and the review outcome and follow-up communication have been unfair and mechanically handled. 1) What happened / Outcome we disagree with Our submission was rejected under Guideline 4.8 – Design – Login Services, with the reviewer stating that our app uses a third-party login service but does not provide an equivalent login option that meets Apple’s requirements (limited data collection, private email option, no advertising tracking without consent). However, our game does not require or force any third-party login. The feature being treated as “login” is not a login service at all—it is Mainland China real-name / anti-addiction compliance verification. 2) Why we believe we comply with the App Review Guidelines A. The feature in question is compliance verification, not login Players do not need to create or log into any in-game account to play. The flow exists solely to satisfy Mainland China real-name/anti-addiction compliance requirements. Verification can be completed by either: Using TapTap only as a real-name verification authorization option, or Manually entering a Chinese ID number + legal name to pass verification and play. Because this is verification, not an account login, Guideline 4.8 “Login Services” should not apply in the way the rejection message assumes. B. There is no “playable account” to provide After we clarified the above, we continued to receive repeated, template-like requests to provide a “playable account.” This request does not match our product design: there is no account system required for gameplay, so there is no “review account” to provide. We have already provided the information needed to complete the verification path (ID + name for the compliance flow), yet the responses remained repetitive and did not reflect that the reviewer checked our explanation. 3) Why we believe the handling was unfair Even after clearly explaining that this is not a login system, the review communication continued with mechanical responses that did not address the clarification. This caused significant delays to our release timeline and appears to be unfair treatment compared with many existing App Store apps that use similar compliance verification flows. 4) What we are requesting from the Appeals Team Please investigate and correct the misclassification of our real-name compliance verification as a “login service” under Guideline 4.8. If the team still believes Guideline 4.8 applies, please provide: The specific guideline rationale, and The exact screen/step in our app that is being interpreted as “login.” Please advise what specific materials you need to proceed efficiently (e.g., screen recording of the verification flow, step-by-step review instructions, configuration notes). We are ready to provide them immediately.

We need to transfer an App to other developer account, both the account are belong to our company. As we know, our app is using the Sign in with Apple function that we need to do some transfer job and we refer to this document: https://developer.apple.com/documentation/technotes/tn3159-migrating-sign-in-with-apple-users-for-an-app-transfer. There is a lot of users using the Sign in with Apple in our app, totally serval millions. To avoid risks as much as possible that we have to make the work flow very clearly, so we're seeking help here. I have serval questions, some I've got the answers from Google gemini and this Forums, I will list them below, please take a look what I understanding is correct or not, thanks. A. From the document above, can I performed the Steps 1&2 before the app transfer? if so, is there a maximum lead time for these transfer_subs? B. Regarding Step 5(Team B exchanging transfer identifiers via https://appleid.apple.com/auth/usermigrationinfo) are there specific rate limits (requests per second/minute) for this endpoint? Cause we have a huge number of user whose using the Sign in with Apple, we have to transfer the sub values as soon as possible. C. Cause we have a huge number of user whose using the Sign in with Apple again, This transfer job involves huge risks. So, is there any way to simulate these whole operations? Answer by my self: NO.

Our organization operates a web platform that hosts numerous newspaper properties. We recently acquired a new newspaper and are in the process of integrating it into our platform. As part of this transition, we’ve successfully transferred the App and App ID for the acquired newspaper into our Apple Developer portal. However, no Service ID associated with Sign in with Apple was included in the transfer. Our current implementation uses a single, unified Service ID for all existing newspaper properties. This Service ID facilitates OAuth via a centralized Identity Server. The organization we acquired provided a CSV file containing a list of transport_ids, and based on our understanding, we’re expected to use the Apple endpoint: https://appleid.apple.com/auth/usermigrationinfo to initiate a registration process by submitting our Service ID (client_id) along with each transport ID. This step is required before users can sign in, and it should return the existing relay email address. We have a few key concerns: Service ID Compatibility It appears that users cannot be transferred between Service IDs. In our case, there are now two: a.) Our existing Service ID (used across all current newspaper properties) b.) A separate Service ID previously associated with the acquired newspaper 3.) Due to architectural constraints, our platform cannot dynamically toggle between multiple Apple Service IDs. All properties authenticate through our unified Identity Server bound to our existing Service ID. 4.) Is it possible to call /usermigrationinfo using our existing Service ID rather than the one originally used by the acquired property? 5.) Relay Email and Apple ID Consistency 6.) We’re seeing conflicting information about whether the Apple relay email address (@privaterelay.appleid.com) and the Apple user ID are preserved during this migration. Some sources suggest that the relay email and Apple ID are tightly coupled to both the Service ID and Team ID. 7.) If we call /usermigrationinfo with our existing Service ID, will the same relay email be returned, or will Apple issue a new one?

Hello, I am currently process of migrating an app from Team A to Team B and attempting to generate transfer identifiers using the migration endpoint: POST https://appleid.apple.com/auth/usermigrationinfo. Content-Type: application/x-www-form-urlencoded However, I am consistently receiving an { "error": "access_denied" } response. [Current Configuration] Team A (Source): Primary App ID: com.example.primary Grouped App IDs: com.example.service (Services ID for Web) com.example.app (App ID for iOS - The one being transferred) All identifiers are under the same App Group. Team B (Destination): New App ID and Key created. [Steps Taken] Created a Client Secret (JWT) using Team A's Key ID and Team ID. The sub (subject) in the JWT is set to the Primary App ID of Team A. Requesting with client_id (Primary App ID), client_secret (JWT), and user_token. [Questions] 1. App Group Impact: Does the fact that the App being transferred is a Grouped App ID (not the Primary) affect the usermigrationinfo request? Should I use the Primary App ID or the specific Grouped App ID as the client_id? 2. Ungrouping Safety: If I need to ungroup the App ID from the Primary App ID to resolve this: Will existing users still be able to sign in without issues? Is there any risk of changing the sub (user identifier) that the app receives from Apple? Will this cause any immediate service interruption for the live app? Any insights on why access_denied occurs in this Primary-Grouped configuration would be greatly appreciated.

I have a user (myself, during development) who originally signed in with Apple successfully. I attempted to revoke access via Settings > Apple ID > Sign-In & Security > Sign in with Apple, but the app appears stuck in the list and cannot be fully removed. Now when attempting to sign in again, the identity token contains the correct sub but email is undefined. According to Apple's documentation, "Apple provides the user's email address in the identity token on all subsequent API responses." I've tried programmatically revoking via the /auth/revoke endpoint (received 200 OK), and I've implemented the server-to-server notification endpoint to handle consent-revoked events, but subsequent sign-in attempts still return no email. The same Apple ID works fine with other apps. Is there a way to fully reset the credential state for a specific app, or is this a known issue with partially-revoked authorizations?

I have a user (myself, during development) who originally signed in with Apple successfully. I attempted to revoke access via Settings > Apple ID > Sign-In & Security > Sign in with Apple, but the app appears stuck in the list and cannot be fully removed. Now when attempting to sign in again, the identity token contains the correct sub but email is undefined. According to Apple's documentation, "Apple provides the user's email address in the identity token on all subsequent API responses." I've tried programmatically revoking via the /auth/revoke endpoint (received 200 OK), and I've implemented the server-to-server notification endpoint to handle consent-revoked events, but subsequent sign-in attempts still return no email. The same Apple ID works fine with other apps. Is there a way to fully reset the credential state for a specific app, or is this a known issue with partially-revoked authorizations?

Hello, We are experiencing an issue related to Sign in with Apple Server-to-Server (S2S) notifications, specifically involving repeated delivery of the account-deleted event, and would like to ask whether this behavior is expected or known. Background We have configured an S2S notification endpoint for Sign in with Apple in accordance with Apple’s requirements for account status change notifications. Our endpoint: Is reachable over HTTPS Consistently returns HTTP 200 OK Successfully receives other S2S events, including: email-enabled email-disabled consent-revoked Issue: Repeated 'account-deleted' events for the same Apple ID For most users, the account-deleted event is delivered only once, as expected. However, for a specific Apple ID used with Sign in with Apple, we are observing repeated deliveries of the same account-deleted event, arriving at regular intervals (approximately every 5 minutes). The payload contents are identical between deliveries and include the same user identifier (sub) and event timestamp. Notably: The Apple ID deletion itself completed successfully The payload does not change between deliveries Our endpoint continues to return HTTP 200 OK for every request Questions We would appreciate clarification on the following points: Is repeated delivery of the same account-deleted event expected behavior in any scenario? Is there a retry or redelivery mechanism for this event type, even when HTTP 200 is returned? Could repeated deliveries indicate that the deletion process is still considered “in progress” on Apple’s side? Are developers expected to treat account-deleted events as at-least-once delivery and handle them idempotently? Additional context While researching this issue, we found a forum thread describing a very similar case: https://developer.apple.com/forums/thread/735674 In that discussion, Apple staff advised submitting the issue via Feedback Assistant, which suggests that this behavior may already be understood internally. We have also submitted a Feedback Assistant report with detailed logs and timestamps. Any clarification on the expected behavior or recommended handling for this scenario would be greatly appreciated. Thank you for your time and support.

Hi I am experiencing a persistent 'invalid_client' error when attempting to exchange the authorization code for an access token using Sign in with Apple for my website (https://www.vitamarinaweb.com). Current Setup & Steps Taken: Identifier: I am using the Service ID com.vitamarinaweb.web1, which is correctly linked to the Primary App ID com.vitamarinaweb.web. Client Secret: I have generated a fresh Client Secret (JWT) using a valid Key (.p8) and confirmed the Team ID (29J763Q88J) and Key ID (RRW6536D27) are correct. Redirect URIs: My Return URL is set to https://www.vitamarinaweb.com/login.php and I have verified there are no trailing spaces or mismatches. Manual Test (CURL): When I perform a manual POST request via CURL using the generated Client Secret, I receive an 'invalid_grant' response (meaning the Client Secret and Client ID are accepted, and only the temporary code is rejected as expected). The Issue: Despite the CURL success, every request initiated through the web browser/PHP application returns {"error":"invalid_client"}. Verification Requested: Could you please verify if there is a synchronization delay or a specific block on Service ID com.vitamarinaweb.web1? Is there any internal mismatch between the Key ID RRW6536D27 and its association with the newly created Service ID? I have already cleared browser caches and tried multiple devices (different IP addresses) with the same result. Thank you for your assistance."