Our app ID is 708064914; When we transferred an app with Sign in with Apple function, and request the REST API to get transfer_sub, approximately 25% of the requests return error responses such as: {"error":"invalid_request","error_description":"User not found."} or {"error":"invalid_request"} User 001700.6b50fa0cdf564b4f83e3ac6b8dfb9a9b.1205 received the first error; User 000908.523b85e1dd704d808dbfac55425c5a7b.1916 received the second error. Here's the English translation: We want to understand under what circumstances these errors occur. Since we have already transferred once before, this is the second transfer. The "User not found" error might be related to IDs from the original team. However, we don't understand the meaning of the second error type and what circumstances might cause it.

Dear Apple Developer Technical Support, We are currently following the official Apple documentation “TN3159: Migrating Sign in with Apple users for an app transfer” to carry out a Sign in with Apple user migration after successfully transferring several apps to a new developer account. Here is a summary of our situation: Under the original Apple developer account, we had five apps using Sign in with Apple, grouped under a shared primary app using App Grouping. Recently, we transferred three of these apps to our new Apple developer account via App Store Connect. After the transfer, these three apps are no longer associated with the original primary App ID. We reconfigured individual Services IDs for each app in the new account and enabled Sign in with Apple for each. More than 24 hours have passed since the app transfer was completed. Now we are attempting to follow the migration process to restore user access via the user.migration flow. Specifically, we are using the following script to request an Apple access token: url = "https://appleid.apple.com/auth/token" headers = {"Content-Type": "application/x-www-form-urlencoded"} data = { "grant_type": "client_credentials", "scope": "user.migration", "client_id": "com.game.friends.ios.toptop.sea", # New Services ID in the new account "client_secret": "<JWT signed with new p8 key>" } response = requests.post(url, headers=headers, data=data) However, the API response consistently returns: { "error": "invalid_client" } We have verified that the following configurations are correct: The client_secret is generated using the p8 key from the new account, signed with ES256 and correct key_id, team_id, and client_id. The client_id corresponds to the Services ID created in the new account and properly associated with the migrated app. The scope is set to user.migration. The JWT payload contains correct iss, sub, and aud values as per Apple documentation. The app has been fully transferred and reconfigured more than 24 hours ago. Problem Summary & Request for Support: According to Apple’s official documentation: “After an app is transferred, Apple updates the Sign in with Apple configuration in the background. This can take up to 24 hours. During this time, attempts to authenticate users or validate tokens may fail.” However, we are still consistently receiving invalid_client errors after the 24-hour waiting period. We suspect one of the following issues: The transferred apps may still be partially associated with the original App Grouping or primary App ID. Some Sign in with Apple configuration in Apple’s backend may not have been fully updated after the transfer. Or the Services ID is not yet fully operational for the transferred apps in the new account. We kindly request your assistance to: Verify whether the transferred apps have been completely detached from the original App Grouping and primary App ID. Confirm whether the new Services IDs under the new account are fully functional and eligible for Sign in with Apple with user.migration scope. Help identify any remaining configuration or migration issues that may cause the invalid_client error. If necessary, assist in manually ungrouping or clearing any residual App Grouping relationships affecting the new environment. We have also generated and retained the original transfer_sub identifiers and are fully prepared to complete the sub mapping once the user.migration flow becomes functional. Thank you very much for your time and support!

On Wednesday, June 18, 2025, Sign in with Apple was impacted by a configuration issue which affected some developer accounts that created new app or Services ID configurations, or edited existing configurations, resulting in the following errors: invalid_client response error returned by the authentication, token validation/revocation, and user migration requests "Sign Up Not Completed" (or equivalent) error presented from the Authentication Services framework. On Monday, June 23, 2025, this issue was resolved. Please retry the Sign in with Apple flows in your Sign in with Apple enabled apps and websites to confirm your developer account configuration has been fixed. Please let us know if you can still reproduce this issue with your developer account. If so, follow the steps outlined in the post below: Gathering required information for troubleshooting Sign in with Apple authorization and token requests https://developer.apple.com/forums/thread/762831 Finally, reply (not comment) with your Feedback ID on either of the posts below: https://developer.apple.com/forums/thread/789011 https://developer.apple.com/forums/thread/789132 Cheers, Paris X Pinkney |  WWDR | DTS Engineer

On Thursday, June 12, 2025, Sign in with Apple was impacted by an incorrect subdomain defined in its /.well-known/openid-configuration file. The JSON returned incorrectly provided https://account.apple.com instead of the expected https://appleid.apple.com. For Sign in with Apple, the value for the issuer (iss) claim in the user's identity token is https://appleid.apple.com. Additionally, if your clients use the Sign in with Apple REST API, the following endpoints should be used for each request: https://appleid.apple.com/auth/authorize https://appleid.apple.com/auth/token https://appleid.apple.com/auth/revoke https://appleid.apple.com/auth/keys This issue with the /.well-known/openid-configuration file was resolved the same day. Use the URL below to confirm the expected subdomain is provided, as needed: https://appleid.apple.com/.well-known/openid-configuration Cheers, Paris X Pinkney |  WWDR | DTS Engineer

We’re integrating Sign in with Apple using Apple’s official JavaScript SDK: https://appleid.cdn-apple.com/appleauth/static/jsapi/appleid/1/en_US/appleid.auth.js We’ve successfully used this setup with an older Service ID, but when we try to use any newly created Service ID, we get the following error immediately when calling AppleID.auth.signIn(): invalid_client This happens before any request reaches our backend. The same flow, redirect URI, and frontend code works fine with an old Service ID — but fails with new ones. ✅ What We’ve Verified: The Service ID (e.g., com.projectx.web.login) is created under Apple Developer → Identifiers → Service IDs The redirect URI is correct and matches exactly (HTTPS, no trailing slash) No client_secret is passed in the frontend (by design) We’re using usePopup: true ❌ What Doesn’t Work: Any new Service ID we create — even on the same domain and configuration — fails with invalid_client. 🔁 What We’ve Tried: Creating multiple new Service IDs Waiting 48+ hours in case of propagation delays Validating HTTPS and redirect URI setup Comparing all settings with the working (older) Service ID (which we deleted since we thought that was causing a problem) Testing in different environments and browsers ❓ Questions: Why do newly created Service IDs fail with invalid_client while older ones work? Are there undocumented requirements, propagation delays, or steps for new Service IDs to become active? Is this a known limitation or bug in the SDK? 💻 Our Code: import { useEffect } from "react"; import { Button, Box } from "@mui/material"; import api from "../utils/api"; // Axios wrapper import AppleIcon from "@mui/icons-material/Apple"; import MainAuthStyles from "../pages/MainAuthStyles"; import { useUser } from "../../../user-module/src/contexts/UserContext"; import { useNavigate } from "react-router-dom"; // Apple global type declare global { interface Window { AppleID: any; } } type AppleSignInButtonProps = { setApiError: (msg: string) => void; }; const AppleLogInButton = ({ setApiError }: AppleSignInButtonProps) => { const { user, setUser } = useUser(); const navigate = useNavigate(); useEffect(() => { if (!window.AppleID) return; window.AppleID.auth.init({ clientId: import.meta.env.VITE_APPLE_CLIENT_ID, scope: "name email", redirectURI: import.meta.env.VITE_APPLE_REDIRECT_URI, usePopup: true, }); }, []); const handleAppleLogin = async () => { try { const response = await window.AppleID.auth.signIn(); const { id_token, code, user } = response.authorization; const res = await api.post("/auth/apple-login", { idToken: id_token, code, user, rememberMe: true, }); if (res.data.success == true && res.data.user.userDataInitialised == true ) { setUser({ id: res.data.user.id ? res.data.user.id : '', fullName: res.data.user.fullName ? res.data.user.fullName : '', email: res.data.user.email ? res.data.user.email : '', role: res.data.user.role ? res.data.user.role : '', signUpType: res.data.user.signUpType ? res.data.user.signUpType : '', userDataInitialised: res.data.user.userDataInitialised ? res.data.user.userDataInitialised : false, }); localStorage.setItem("accessToken", res.data.accessToken); localStorage.setItem("refreshToken", res.data.refreshToken); navigate("/app") } else { setApiError("Unrecognized login method") return; } } catch (err) { console.error("Apple Sign-In failed", err); setApiError("AppleSignInFailed"); } }; return ( <Box mt={2}> <Button variant="outlined" fullWidth onClick={handleAppleLogin} className="AuthAppleButton" startIcon={<AppleIcon />} > Log in with Apple </Button> </Box> ); }; export default AppleLogInButton; Any help from the Apple team or anyone who's resolved this issue would be appreciated — we’re currently blocked on deploying new environments due to this error. Thanks!

My app was rejected from App Store because of the following reasons: This item has been rejected for the following reasons: 2.1.0 Performance: App Completeness 4.8.0 Design: Login Services I implemented and upgraded the app with these updates. However, the app is working fine on the test side, but it shows an error when I try to upload the app for review again. Please advise my next steps.

Hi, preivously on appleid.apple.com, navigating to this page on safari would show the in-app modal to continue with Apple. Now with account.apple.com, this is not the case. We are not seeing the in-app modal to continue with Apple

Hello Apple Developer Community and Support, Our team is encountering a critical and persistent issue with our backend integration of Sign In with Apple, and we are hoping for some insights or assistance. Problem: We consistently receive an "invalid_client" error (HTTP 400 status) when our backend service attempts to exchange the authorization code for tokens at Apple's https://appleid.apple.com/auth/token endpoint. The error message from Apple's response is simply {"error":"invalid_client"}. Our Setup: Client Application: An iOS native application. Backend Service: A Go backend responsible for server-to-server token exchange and user management. Sign In with Apple Flow: The iOS app initiates the Sign In with Apple flow, obtains an authorization code, and then passes this code to our backend for token exchange. Extensive Troubleshooting Performed (No Success): We have meticulously followed all official Apple documentation (including TN3107: Resolving Sign In with Apple Response Errors) and industry best practices. Here's a summary of our verification steps, all of which currently show correct configurations and parameters: Backend client_secret JWT Construction: We generate a client_secret JWT as required for server-to-server communication. We've confirmed the claims in the generated JWT are correct: iss (Issuer): Our Team ID (e.g., XXXXXXXXXX). sub (Subject): Our Service ID (e.g., com.example.service.backendauth). aud (Audience): https://appleid.apple.com. kid (Key ID): The Key ID associated with our .p8 private key (e.g., YYYYYYYYYY). We have performed rigorous verification of the .p8 private key content itself, ensuring no corruption, extra characters, or formatting issues in the environment variable. Our backend logs confirm it's parsing the correct PEM content. Token Exchange Request Parameters: The client_id parameter sent in the POST request to /auth/token is correctly set to our App Bundle ID (e.g., com.example.app.ios), as this is the identifier for which the code was originally issued. The redirect_uri parameter sent in the POST request to /auth/token is precisely matched to a registered "Return URL" in our Apple Developer Portal (e.g., https://api.example.com:port/api/auth/callback?provider=apple). Apple Developer Portal Configuration (Meticulously Verified): App ID: Enabled for "Sign In with Apple". Service ID: Enabled for "Sign In with Apple". Its "Primary App ID" is correctly linked to our App Bundle ID (e.g., com.example.app.ios). Its "Return URLs" exactly match our backend's redirect_uri (e.g., https://api.example.com:port/api/auth/callback?provider=apple). Key: Our .p8 key has "Sign In with Apple" enabled. Crucially, in its configuration panel, the "Primary App ID" is correctly linked to our App Bundle ID (e.g., com.example.app.ios). We've ensured this key is specifically created for "Sign In with Apple" and not other services like APNs. We have performed multiple full revocations and meticulous re-creations of the App ID, Service ID, and Key in the Apple Developer Portal, ensuring correct linkages and using new identifiers to bypass any potential caching issues. Network & System Health Checks: Network connectivity from our backend server to https://appleid.apple.com (port 443) has been confirmed as fully functional via ping and curl -v. The incoming TLS handshake from our iOS client app to our backend server's callback URL (https://api.example.com:port/...) is successful and verified via openssl s_client -connect. There are no longer any TLS handshake errors (EOF). Our backend server's system clock is accurately synchronized via NTP. Request for Assistance: Given that all our visible configurations, environment variables, and request parameters appear to be correct and align with Apple's documentation, and network connectivity is confirmed, we are at a loss for why the invalid_client error persists. Based on TN3107, this error typically implies an issue with the client secret's signature or its validity for the given client_id. However, our logs confirm correct iss, sub, aud, and kid, and the private key content. Has anyone encountered this persistent invalid_client error when all checks pass? Are there any less common configurations or troubleshooting steps we might be missing? Could this indicate a caching or propagation delay on Apple's servers, even after waiting periods? Any insights or guidance would be greatly appreciated. We are prepared to provide detailed, anonymized logs and screenshots to Apple Developer Support privately if requested. Thank you.

Hi everyone, My web application has two services: myapp.com and account.myapp.com. The first manages all app content, while the latter handles the authentication, with Sign In with Apple included. The tech stack is mainly composed of React, JS, and Express. We'd like to allow users to authenticate inside a dialog on some pages of myapp.com. To avoid replicating stuff from one service to another, we put an iframe inside the dialog to show the authentication standard page from account.myapp.com. Email and Facebook processes work fine, but we have the following issues with Sign in with Apple: On desktop, not Safari, a pop-up window opens when you click on the Apple button, and it works as expected. On desktop Safari, the pop-up window is blocked. We want the native Apple pop-up to show instead of a generic browser new window. On mobile, nothing happens on click Obviously, outside the iframe, everything works as expected. I can't seem to find anything related to an iframe constraint in the Sign in with Apple docs. Is this feasible?

Our iOS app uses Sign in with Apple to authenticate users, and we use Firebase for the backend — for both Auth and Storage. If anyone can provide guidance and/or share experience on how to migrate an iOS app to a different App Store Connect team, particularly with a Firebase backend, that would be fantastic. Below I'll provide info about our situation, and I'll describe what I understand so far about the migration process. About our app: A few months ago, we transferred our iOS app to a different App Store Connect team, and it seemed that everything was fine... but recently we learned that we should have migrated SIWA (Sign in with Apple) users so that Sign in with Apple will continue to work under the new team, but we didn't do that, and as a result of missing the 60-day window, Apple's documentation says that we now need to transfer the app back to the original team... and then we can start preparing to migrate the SIWA users to the new team. Before transferring back to the original team, we started receiving errors during the Sign in with Apple process which say "Sign Up Not Completed" in Apple's UI... but the callback authorizationController(controller:didCompleteWithError:) is NOT called. For reference, here's Apple's documentation on this subject: TN3159: Migrating Sign in with Apple users for an app transfer [https://developer.apple.com/documentation/technotes/tn3159-migrating-sign-in-with-apple-users-for-an-app-transfer][2] Transferring your apps and users to another team [https://developer.apple.com/documentation/signinwithapple/transferring-your-apps-and-users-to-another-team][3] Bringing new apps and users into your team [https://developer.apple.com/documentation/signinwithapple/bringing-new-apps-and-users-into-your-team][4] Note: the first article contains 4 broken links (thanks Apple 🙄) but it's pretty clear that these 2 other links ☝️ are where those broken links should be pointing to. In our situation, it's clear that we need to transfer the app back to the original team. But how to proceed after that? As I understand it, for a given user, Apple provides a sub which is basically a user ID that is specific to that team. After the app is transferred to the new team, the sub returned from Apple will be different... but Firebase doesn't appear to store the sub anywhere, so it's either unimportant OR we need to set up our own Auth instead of using Firebase Auth. Thoughts? When using Sign in with Apple, the user's email address is exposed to our app... but if the user opted to use a private relay email address, that's a problem, because private relay email addresses are ALSO specific to that team. If the user with a private relay email tries to log in under the new team, we won't recognize their "new" email address, but we need a way to associate that user with their "old" account in Firebase. The solution provided by Apple is that we need to request the transfer_sub (also known as a "transfer identifier") for each user, and we need to store the transfer_sub in our backend to be able to allow a user who is logging in under the new team to still have access to their "old" account in Firebase. Even though private email relay addresses and subs will be different under the new App Store Connect team, the transfer_sub is the same for each user across both teams. According to Apple's documentation, the user's sub is needed in order to request the transfer_sub... but if we're not already storing the sub in Firebase, then how do we request the sub for every user, then the transfer_sub for every user, and then store that info in Firebase? Does this need to happen on the iOS side? And what would happen to a user who was using our app for months, then stopped using the app for >60 days while we were doing the migration, and then tried to sign in again? Will that user be permanently be locked out of our app? Is it impossible to keep all users happy and able to log into their accounts in this scenario? TLDR: We're trying to migrate an iOS app with a Firebase backend (Auth and Storage) to a different App Store Connect team... and it's apparently a complicated process because we're using Sign in with Apple. Please help if you can! Thank you! 🙏

I'm currently transferring an iOS app to a new Apple Developer account and following the process outlined in Apple’s documentation: 🔗 TN3159 - Migrating Sign in with Apple users for an app transfer The process for generating transfer_identifiers and migrating existing users is clear, and I don’t expect issues with that part. However, I have a question about preserving the user session after the transfer. My setup: The app uses Sign in with Apple via a backend-based authentication flow. On login, the app retrieves the authorization_code and sends it to the backend. The backend exchanges the code for tokens from Apple, including a refresh_token. That refresh_token is then used on the backend to validate the user’s identity on subsequent requests. My concern: Once I initiate the app transfer, migrate users, and update the backend with new Apple credentials (client ID, team ID, etc.), I assume that the existing tokens issued under the old credentials will become invalid. So my question is: Is there a way to maintain the user’s authenticated session through this transition without requiring them to manually sign in again? I’d like to ensure a seamless experience for users, if possible.

Our app got rejected with below reason Your app offers Sign in with Apple as a login option but does not follow the design and user experience requirements for Sign in with Apple. Specifically: Your app requires users to provide their name and/or email address after using Sign in with Apple. This information is already provided by the Authentication Services framework. These requirements provide the consistent experience users expect when using Sign In with Apple to authenticate or login to an account. We have an option to login to our app with Apple sign in The user must have a valid account with a valid email id, that created from the web and the user must complete all onboarding program In the app once the user sign-in using Apple login, we will check for the email ID is hidden or not, if it is hidden we cant log in because we must have a valid email id. So we show a modal with " We can't log you in because your email is hidden. Please select "Share My Email" to continue or use the regular email login option" If user shares an email, then will check for account exists for that email or not,if yes, it will allow to log-in to the app How can I sort out this problem?

News link: https://developer.apple.com/news/?id=12m75xbj If your app offers Sign in with Apple, you’ll need to use the Sign in with Apple REST API to revoke user tokens when deleting an account. I'm not good English. I'm confused about the above sentence Do I have to use REST API unconditionally or can I just delete to the account data?

In response to inquiries from users, we have confirmed the following phenomenon. If you select "Private email address" in the flow of new user registration with Apple ID, you will not receive the verification code email when performing two-factor authentication. ■User impact If you use your Apple ID to link an external account without making your email address public, you will not receive the authentication code during two-factor authentication and will not be able to proceed. The date and time of the impact is currently unknown. ◎Impact 1: New registration If you select "Private email address" in the flow of registering a new user with Apple ID, the verification code will not be received during two-factor authentication and registration will not be completed. ◎Impact 2: Login of existing account When two-factor authentication is required for an existing account registered with Apple ID set to "Private email address," the verification code is not received and the user cannot log in. →If you have not registered a login method other than Apple ID for the relevant account, there is no other way to log in. ■About workarounds ・I thought that I could avoid this issue by canceling the private setting of my Apple ID, but I was unable to do so. →There is currently no workaround found for existing users who are experiencing this issue. ・However, the scope of influence is limited. ■Cause investigation status Premise: For an Apple ID whose email address is not made public, the two-factor authentication authentication code email follows the following route. ①CDC/GIGYA miraiz-persol.jp (SendGrid) Apple's email server (relay server to hide the user's real email address) User mailbox →Since '1' are working, the problem seems to have occurred after the connection from ② or ③. (At this stage, we cannot determine who is at fault: the user, MIRAIZ, or Apple. We are currently investigating.) ◎Hypothesis ・Is there something wrong with Apple's mail server? ・Is it not delivered because the user's mailbox is full? ■Questions, research, and responses we would like to receive Please check the following two points and reply. 1st point As shown in the attached image, there seems to be no problem with the SPF settings. Is it possible to check to see if any errors have occurred with Apple's mail server? 2nd point Are there any cases where you still can't receive emails even if you deactivate your Apple ID? I would like to know if there are any patterns in which emails are not being delivered in terms of past inquiries or overall specifications

We have 2 developers: Developer A created a Bundle ID and configured Sign in with Apple, but didn't create a corresponding App. This Bundle ID is only used for login on our official website. Developer B created a Bundle ID, configured Sign in with Apple, and has a corresponding App. The issue we're encountering is that because these two Bundle IDs are under different teams, when using the same Apple ID to log into these two applications, different accounts are generated. (We've tested that when creating Service IDs under the same team, logging in with Bundle IDs under the same team generates the same account.) Since Developer A's Bundle ID doesn't have a created app, it cannot be transferred to Developer B. Therefore, we'd like to know if there's any way to make the accounts generated from logging in with the same Apple ID be identical across these two teams?

Hello We would like to proceed with the transfer of ownership of the launched app based on the Cafe24 platform.(Web App) Last month, I inquired about how to transfer the Apple account login function together when transferring ownership and received a related manual. When I asked and inquired about help from several developers regarding that part, they all received different answers. Please review the answers below, and I would really appreciate it if you could guide me on how to proceed. Developer 1: Cafe24-based launch apps require a separate transfer of the login function. It does not affect if you do not delete the existing member data in the database, and you only need to activate the login function to the new developer account. Developer 2: Checking and analyzing existing servers and data - Transfer user data to Apple using Apple's Legacy User Identifier - Synchronize user data - Test and modify It has to proceed to the above four steps, and synchronization work is also required to maintain all of the existing user's data because all of the user's identification values change when the login function is transferred. Developer 3: It appears to be a task that needs to be stored in the server database by migrating from the user identifier created in the existing developer account to the user identifier to be used in the new developer account, which is not what the app is supposed to do, and it is recommended to find other experts. Thank you.

Hello Apple Developer Community, We are experiencing an issue with email delivery when users sign in using "Sign in with Apple" on our platform. We need assistance in understanding and resolving this problem. Issue Description: When users choose to hide their email during the "Sign in with Apple" process, Apple provides a private relay email address (e.g., xxxx@xxx). These private relay email addresses are successfully received and stored in our system via the OIDC protocol implemented on Keycloak. Verification emails are sent from our configured email address to the private relay email addresses. However, users do not receive these emails, and we suspect they are not being forwarded to the user’s actual email address. Steps Taken: Sender Address Configuration: We have verified that our email is properly set up and authorized to send emails. DNS Records: Our DNS records (SPF, DKIM, and DMARC) are configured to comply with email authentication standards. Whitelisting Sender Address: We attempted to whitelist the sender address as per recommendations but have not seen any improvement. Questions: Are there additional DNS configurations or records required for the Apple private relay to forward emails properly? Is there a process to validate our sender address with Apple to ensure email forwarding works? Are there specific guidelines or restrictions for sending emails to privaterelay.appleid.com addresses that we should follow? Is there a way to verify if Apple’s private relay email service is functioning correctly for our domain? Relevant Information: We use Keycloak to implement the OIDC protocol and store the private relay email address during the "Sign in with Apple" process. Our verification emails are sent from our email address. We have referred to the Apple documentation and community posts but could not find a clear resolution. Any guidance or recommendations from the community would be greatly appreciated. Thank you in advance for your support!

I have tried everything to get the user field returned with Sign in flow and it never does, not for new users, not even if i create a new app! Working with Apple is so frustrating and you have to pay for it!! Referencing this page, I am using scope=name email. I have tried using + and %20 as the spacer and neither makes a difference. I have also tried setting response_type = code and code id_token (again with + and %20 as the spacer) which also doesn't make a difference. Always the id_token is returned and always the email, but never the user. https://developer.apple.com/documentation/sign_in_with_apple/sign_in_with_apple_js/incorporating_sign_in_with_apple_into_other_platforms#3332115 AUTHORIZE REQUEST https://appleid.apple.com/auth/authorize? { "response_type": "code", "client_id": "com.example.service", "scope": "name email", "state": "77264297-813c-4738-83ef-f1b77daea04c", "redirect_uri": "https://example.com/auth/apple/callback", "code_challenge_method": "S256", "code_challenge": "2SJCneEpjKcN.....xIIHnpqcvjK_Y0s", "access_type": "offline", "nonce": "1734523662", "response_mode": "form_post" } TOKEN REQUEST https://appleid.apple.com/auth/token? { "grant_type": "authorization_code", "code": "c870aaec987a14.....dqakaGP4Yn1nH3dnPgww", "client_id": "com.hikesync.service", "client_secret": "eyJhbGciOiJFUzI....3izij6dojYfdV6JMdbQPx3sOA", "redirect_uri": "https://hikesync.com/auth/apple/callback", "code_verifier": "38hHUC....mYuE0zfYVNTycg" } RESPONSE { "access_token": "a2b70e12d38b446....4hA7-RLNj0ifU5Q", "token_type": "Bearer", "expires_in": 3600, "refresh_token": "rb4ed9be2b4024......w5RWjVFUQ", "id_token": "eyJraWQiOiJyQlJmV.......0Df0ihEJiA" } JWT { "iss": "https://appleid.apple.com", "aud": "SERVICE_ID", "exp": 1734606699, "iat": 1734520299, "sub": "000000.f7f7c0ac.....db9fad7e19.1111", "nonce": "NONCE", "at_hash": "NAfjmciTi2NtmPYIMAgjig", "email": "abc123@privaterelay.appleid.com", "email_verified": true, "is_private_email": true, "auth_time": 1734520297, "nonce_supported": true }

Hello Developers, I have ran into a problem while sending mail to apple private relay email. We have built a mobile application where user can sign up through apple and they can sign up using hide-my-email feature. Which provides private relay address for us. Now we want to communicate with them using private relay mail address. The technology we are using to send emails are amazon SES, have done SPF, DMIK, DMARC and added domains in apple identity services for mail communication, passed an SPF check as well. But still mail is not getting delivered what am i doing wrong or apple doesn't support third party apps for sending emails to private relay? Is there any other way to achieve this please let me know Using the same body as attached in image is working fine for rest emails.