Hi everyone,
We just completed an App Store Connect app transfer between two developer teams and ran into what seems like an inconsistency with TN3159 (Migrating Sign in with Apple users for an app transfer).
According to the technote, both the source and destination teams should be able to call /auth/usermigrationinfo for 60 days after the transfer, even if the migration wasn’t run beforehand. However, right after the transfer completed, the source team (Team A) started receiving:
{"error":"invalid_client"}
on all /auth/usermigrationinfo requests, even though /auth/token with scope=user.migration still works fine.
What we verified before transfer:
Team A’s Sign in with Apple key (ES256) was linked to the app and Services ID.
OAuth flow for com.org.appname.web returned valid tokens, and the decoded ID token showed aud=com.org.appname.web with a valid private relay email, confirming the key was trusted.
What happens after transfer:
The key now shows “Enabled Services: —” and the App/Services IDs are no longer selectable in the Developer portal.
/auth/usermigrationinfo immediately returns invalid_client for Team A, even within the same day of the transfer.
This effectively makes Team A unable to generate transfer_sub values, blocking the migration flow TN3159 describes.
Questions:
Is Team A supposed to retain authorization to call /auth/usermigrationinfo for 60 days post-transfer?
If yes, is there any known workaround to re-authorize the key or temporarily re-bind it to the transferred identifiers?
If not, does this mean transfer_sub must be generated before transfer acceptance, contrary to how TN3159 reads?
Would really appreciate any confirmation or guidance from Apple or anyone who’s gone through this recently.
Thanks,