Hi, we are experiencing a specific issue with the Private Email Relay service. Our domain e.glassesdirect.co.uk consistently fails SPF verification while our other domains pass. The Pattern: We've noticed that domains with SPF records fitting in 1-2 TXT strings pass, but this specific domain (~750 chars, 3 TXT strings) fails. Technical Details: Team ID: SM2J7LWD33 Domain: e.glassesdirect.co.uk SPF Record length: ~750 characters Third-party tools (MxToolbox) confirm the record is valid. We suspect Apple's verification parser might be failing to handle concatenated TXT strings or hitting a size limit. Could any Apple engineers confirm if there is a character limit or a bug in handling multi-part TXT records?

I set up "Sign in with Apple" via REST API according to the documentation. I can log in on my website and everything looks fine for the user. But I receive an email, that my "Sign in with Apple" account has been rejected by my own website. It states, I will have to re-submit my name and email address the next time I log in to this website. I don't see any error messages, no log entries, no HTTP errors anywhere. I also can't find anything in the docs, the emails seem to not be mentioned there, searching for anything with "rejected" in the forum did not yield any helpful result, because they are always about App entries being rejected etc. Did someone experience something similar yet? What's the reason, I'm getting these emails? I get them every time I go through the "Sign in with Apple" flow on my website again.

Problem Summary I'm experiencing a persistent invalid-credential error with Apple Sign-In on iOS despite having verified every aspect of the configuration over the past 6 months. The error occurs at the Firebase Authentication level after successfully receiving credentials from Apple. Error Message: Firebase auth error: invalid-credential - Invalid OAuth response from apple.com. Environment Platform: iOS (Flutter app) Firebase Auth: v5.7.0 Sign in with Apple: v6.1.2 Xcode: Latest version with capability enabled iOS Target: 13.0+ Bundle ID: com.harmonics.orakl What Actually Happens ✅ Apple Sign-In popup appears ✅ User can authenticate with Apple ID ✅ Apple returns credentials with identityToken ❌ Firebase rejects with invalid-credential error The error occurs at Firebase level, not Apple level. What I've Tried Created a brand new Apple Key (previous key was 6 months old) Tested with both App ID and Service ID in Firebase Completely reinstalled CocoaPods dependencies Verified nonce handling is correct (hashed to Apple, raw to Firebase) Activated Firebase Hosting and attempted to deploy .well-known file Checked Cloud Logging (no detailed error messages found) Disabled and re-enabled Apple Sign-In provider in Firebase Verified Return URL matches exactly Waited and retried multiple times over 6 months Questions Is the .well-known/apple-developer-domain-association.txt file required? If yes, how should it be generated? Firebase Hosting doesn't auto-generate it. Could there be a server-side caching/blacklist issue with my domain or Service ID after multiple failed attempts? Should the Apple Key be linked to the Service ID instead of the App ID? The key shows as linked to Z3NNDZVWMZ.com.harmonics.orakl (the App ID). Is there any way to get more detailed error logs from Firebase about why it's rejecting the Apple OAuth response? Could using a custom domain instead of .firebaseapp.com resolve the issue? Additional Context Google Sign-In works perfectly on the same app The configuration has been reviewed by multiple developers Error persists across different devices and iOS versions No errors in Xcode console except the Firebase rejection Any help would be greatly appreciated. I've exhausted all standard troubleshooting steps and documentation. Project Details: Bundle ID: com.harmonics.orakl Firebase Project: harmonics-app Team ID: Z3N....... code : // 1. Generate raw nonce final String rawNonce = _generateRandomNonce(); // 2. Hash with SHA-256 final String hashedNonce = _sha256Hash(rawNonce); // 3. Send HASHED nonce to Apple ✅ final appleCredential = await SignInWithApple.getAppleIDCredential( scopes: [AppleIDAuthorizationScopes.email, AppleIDAuthorizationScopes.fullName], nonce: hashedNonce, // Correct: hashed nonce to Apple ); // 4. Create Firebase credential with RAW nonce ✅ final oauthCredential = OAuthProvider("apple.com").credential( idToken: appleCredential.identityToken!, rawNonce: rawNonce, // Correct: raw nonce to Firebase ); // 5. Sign in with Firebase - ERROR OCCURS HERE ❌ await FirebaseAuth.instance.signInWithCredential(oauthCredential);

We use Sign in with Apple. Emails to @privaterelay.appleid.com bounce with "550 5.1.1 ...@send-subdomain: unauthorized sender" for 4+ days. Setup: Sending via Resend (Amazon SES, eu-west-1) From: siparis @ truefriends.com.tr, envelope: send.truefriends.com.tr All four Email Sources show green SPF in Certificates, IDs & Profiles: truefriends.com.tr (Domain) send.truefriends.com.tr (Domain) siparis @ truefriends.com.tr (Email) *@send.truefriends.com.tr (Email wildcard) — added today, no effect Test mail to non-Apple inbox: spf=pass, dkim=pass (d=truefriends.com.tr matches From), dmarc=pass. So full authentication is verified. Filed Feedback Assistant + Developer Support case 102902232938 — Tier 1 deflected to Feedback. Waiting for engineering response. Has anyone resolved a case where portal shows green ✓ but Relay still rejects as unauthorized? Internal sync issue?

Hi, it's very urgency! https://developer.apple.com/forums/thread/818346 After long time preparation, We finally execute this transfer operation today. Works fine at preliminary stage, lots of users had been transferred successfully. However, about 25% users transferred failed at the end, 'invalid_request' response from https://appleid.apple.com/auth/usermigrationinfo. No matter how many times we retry, it does work. Please help! 700,000 users are waiting us!

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?