Give app reviewers access with OTP, magic links, or social login

The reviewer can’t get past sign-in, so they can’t review the app you’ve built. A password isn’t enough if the next screen asks for a code sent to your phone. Prepare a way to sign in that works without you being online.

A one-time password (OTP) is a code sent by text or email, or generated by an authenticator. A magic link signs someone in when they open it. Both need extra care when preparing review access.

Google requires reusable, continuously available review access, including access beyond paywalls. Apple asks for a working demo account; a built-in demo mode offered because of legal or security obligations needs Apple’s prior approval.

Match the instructions to your login flow

Your sign-in method	What to prepare and test
Email and password	A dedicated account whose credentials won’t expire during review
SMS or authenticator code	Reusable access for the dedicated review account that doesn’t depend on a person relaying codes
Magic link	A way for reviewers to sign in repeatedly; yesterday’s expiring email link won’t be enough
Social login	All details needed to sign into the dedicated test account and clear any additional challenges
Organization or invitation	A preconfigured membership with the roles needed for the relevant features
Location restriction	Review access that works from the reviewer’s location, with any special route clearly explained

Ask your developer to limit any special access to a dedicated review account with safe test data. A reusable code that works for every customer would create an account-takeover risk. Review access should expose the same features honestly, with the special setup documented for the reviewer.

Put the information where reviewers look

For Google, complete App access in App content. Supply the instructions in English and include the steps for every restricted area. For Apple, fill in the sign-in details and notes in the app version’s App Review Information.

We recommend having someone outside the project follow those instructions on a clean installation. They should reach the app without contacting you, then use the important features, including paid ones.

Here’s an outline to adapt, not credentials to copy:

Sign in using the review account in the credential fields. It belongs to our sample workspace and has access to the paid reporting feature. After sign-in, open Reports, select Sample project, and choose Export. No invitation or purchase is needed to inspect this feature. The sample records contain no customer data.

Add your actual OTP, magic-link, or social-login steps when relevant. Keep credentials in the store’s private review fields, outside public screenshots and listing text.

Retest after you change access

Check sign-out and sign-in, account roles, populated sample content, paid features, and any destructive action the reviewer needs to test. Use disposable accounts for account deletion and explain how another can be obtained without waiting for you.

Keep the account and backend available through review and future checks. If the store already rejected access, update the details, reply with the correction, and follow the required Apple or Google resubmission step. Try the review instructions from a fresh installation, even if you’re already signed in on your own phone.