Transferring your apps and users to another team

Dear Apple:

Due to the change of company information, we need to migrate the online App from the developer account to the developer account of the new company. We have some questions about the migration process. Please help us answer them.

  1. After the new developer account accepts the transferred App, when the online old version of the App uses Apple login authorization, does the unique identifier obtained correspond to the old developer account, or will it become a new identifier corresponding to the new developer account?
  2. Does the Apple login user migration API (userMigrationInfo endpoint) provided by Apple have some restrictions on the call volume and call frequency (currently our Apple authorized user level is about 5 million)

Thank you

Answered by DTS Engineer in 799199022

Hi @doraemon811,

You wrote:

  1. After the new developer account accepts the transferred App, when the online old version of the App uses Apple login authorization, does the unique identifier obtained correspond to the old developer account, or will it become a new identifier corresponding to the new developer account?

By default, the Services ID (which associates the website to the primary app) is also transferred to the recipient team (Team B). Any authorizations occurring after the app transfer will authorize the app with the data approved by the user for Team B.

To learn more, see the 'Apps using Sign in with Apple' section of Overview of app transfer:

The Services ID associated with an app that has configured Sign in with Apple will also be transferred. If you don’t want the Service ID to be transferred, remove its association before initiating the transfer.

Then, you wrote:

  1. Does the Apple login user migration API (userMigrationInfo endpoint) provided by Apple have some restrictions on the call volume and call frequency (currently our Apple authorized user level is about 5 million)

There is no rate limiting for the /auth/usermigrationinfo endpoint. However, it is advised to use the team-scoped access token to handle user migration in large batches instead of individual requests as each user refreshes their session for the transferred app.

Cheers,

Paris X Pinkney |  WWDR | DTS Engineer

Accepted Answer

Hi @doraemon811,

You wrote:

  1. After the new developer account accepts the transferred App, when the online old version of the App uses Apple login authorization, does the unique identifier obtained correspond to the old developer account, or will it become a new identifier corresponding to the new developer account?

By default, the Services ID (which associates the website to the primary app) is also transferred to the recipient team (Team B). Any authorizations occurring after the app transfer will authorize the app with the data approved by the user for Team B.

To learn more, see the 'Apps using Sign in with Apple' section of Overview of app transfer:

The Services ID associated with an app that has configured Sign in with Apple will also be transferred. If you don’t want the Service ID to be transferred, remove its association before initiating the transfer.

Then, you wrote:

  1. Does the Apple login user migration API (userMigrationInfo endpoint) provided by Apple have some restrictions on the call volume and call frequency (currently our Apple authorized user level is about 5 million)

There is no rate limiting for the /auth/usermigrationinfo endpoint. However, it is advised to use the team-scoped access token to handle user migration in large batches instead of individual requests as each user refreshes their session for the transferred app.

Cheers,

Paris X Pinkney |  WWDR | DTS Engineer

Hi @DTS Engineer

I have a question that I would like to ask for help:

According to the provided API (https://developer.apple.com/documentation/sign_in_with_apple/transferring_your_apps_and_users_to_another_team/), the transfer identifier of the old subject has been obtained. However, when obtaining the user identifier of the new subject, according to the API (https://developer.apple.com/documentation/sign_in_with_apple/bringing_new_apps_and_users_into_your_team), it is found that there are a large number of transfer identifiers that cannot obtain user identifiers. The error information returned by the interface is as follows: {"error":"invalid_request","error_description":"User not found."} and {"error":"invalid_request"}

We have two apps under our account, Buyer and Seller. We have transferred the Seller app, the user sign in with Apple is the Buyer’s.

The following is the relevant information used in the process of transferring APP

The client_id for the transferring app is com.dhgate.DHgateBuyer, the teamId for the transferring team is 6PG7H3L6MA The client_id for the transferred app is com.dhgate.DHgateSeller, the teamId for the recipient team is Y2GSG84XX2

Hi @doraemon811,

You wrote:

[...] it is found that there are a large number of transfer identifiers that cannot obtain user identifiers. The error information returned by the interface is as follows: {"error":"invalid_request","error_description":"User not found."} and {"error":"invalid_request"} [...]

If a user decides to revoke access to their information for your client between the moment you performed the app transfer and the moment you attempt the user migration, you cannot receive their user data—thus, the migration request is invalid. In these scenarios where there is no active user session for the client, the invalid_request error response is expected.

Please see TN3159: Migrating Sign in with Apple users for an app transfer for more information on the expected end-to-end app transfer and user migration flow.

Additionally, if you'd like for the iCloud engineering team to confirm if the errors are related to a revoked authorization to previous users accounts, please submit a report via Feedback Assistant and include the following information:

Gathering required information for troubleshooting Sign in with Apple user migration

To prevent sending sensitive JSON Web Tokens (JWTs) in plain text, you should create a report in Feedback Assistant to share the details requested below. Additionally, if I determine the error is caused by an internal issue in the operating system or Apple ID servers, the appropriate engineering teams have access to the same information and can communicate with you directly for more information, if needed. Please follow the instructions below to submit your feedback.

For issues occurring with your user migration, ensure your feedback contains the following information:

  • the primary App ID and Services ID
  • the client secret for the transferring team (Team A) and the recipient team (Team B)
  • the failing request(s), including all parameter values, and error responses (if applicable)
  • the timestamp of when the issue was reproduced (optional)
  • screenshots or videos of errors and unexpected behaviors (optional)

Important: If providing a web service request, please ensure the client secret (JWT) has an extended expiration time (exp) of at least ten business (10) days, so I have enough time to diagnose the issue. Additionally, if your request requires access token or refresh tokens, please provide refresh tokens as they do not have a time-based expiration time; most access tokens have a maximum lifetime of one (1) hour, and will expire before I have a chance to look at the issue.

Submitting your feedback Before you submit via Feedback Assistant, please confirm the requested information above (for your native app or web service) is included in your feedback. Failure to provide the requested information will only delay my investigation into the reported issue within your Sign in with Apple client.

After your submission to Feedback Assistant is complete, please reply here with the Feedback ID. Once received, I can begin my investigation and determine if this issue is caused by an error within your client, a configuration issue within your developer account, or an underlying system bug.

Cheers,

Paris X Pinkney |  WWDR | DTS Engineer

Transferring your apps and users to another team
 
 
Q