Your app needs a login? How to give testers (and reviewers) access

If your app has a login, two groups need a way in: Google's reviewers and your closed testers. Reviewers get working credentials through the sign-in details declaration under Policy and programs > App content. Testers either sign up like real users or use accounts you prepare. Without both, reviews can fail and testers can't really test.

This article covers both sides, and the details that often go wrong.

Why this matters more than it seems

Google is direct about reviewer access. Its requirements for providing sign-in details say that if the credentials don't work, "we may not be able to review your app and, therefore, the app may be rejected." When you apply for production access, Google also lists test credentials among the things to check: "provide valid, working login credentials in Play Console so reviewers can fully test your app's features."

On the tester side, it's about engagement. A tester who stops at a login screen hasn't used your app, and Google lists "insufficient tester engagement during the testing period" as a reason it may require more testing.

Part 1: Access for Google's reviewers

Where to add the details

1. In Play Console, open Policy and programs > App content.
2. Find the sign-in details (app access) declaration.
3. Say whether all or some of your app's functionality is restricted.
4. If it is, add the username, password and any other information a reviewer needs.
5. Use the Any other instructions field to explain anything unusual, such as a one-time password, multi-factor authentication or a login with more than two fields (App content).
6. Save. App content changes go through review like other changes, so send them from Publishing overview.

What Google requires of the credentials

From Google's sign-in details requirements:

• Always available and reusable. "Your sign-in details must be accessible at all times, reusable, and valid regardless of user location."
• No codes the reviewer can't receive. "If your app typically requires a 2-Step verification code or One-time password, make sure to provide reusable login credentials that can bypass these requirements."
• In English. If your login details are normally in another language, provide an English version.
• Clear instructions for accounts that need setup, and full details if the app uses third-party sign-in (such as signing in with a Google or Facebook account).
• Paywalled content: give access details that let reviewers "fully and freely access and review the app."

Practical tips

• Create a dedicated review account. Never give out your own account or a real user's.
• Fill it with sample data. An empty account shows empty screens. Add a few realistic records so every feature has something to display.
• Turn off expiry and lockouts for that account. Password rotation, inactivity timeouts or a "too many attempts" lock will break the credentials without you noticing.
• Whitelist the account on your backend if you use SMS, email codes or device binding, so it can sign in without them.
• Test the login from a clean device before you submit, and again after every backend change.

The pre-launch report crawler is a separate case. It also gets stuck on login screens, and it has its own credential settings. Treat it as a third audience.

Part 2: Access for your closed testers

Testers aren't reviewers. They should experience the app the way real users will, but they still need a smooth path in.

Option A: testers sign up themselves

This is the most realistic choice. It tests your sign-up flow, email delivery and onboarding, which are exactly the parts new users hit first.

It works when:

• sign-up is open to anyone (no invite code or approval queue)
• verification emails and SMS arrive reliably in your testers' countries
• the app is usable straight after sign-up

Option B: you create accounts for testers

Choose this when sign-up isn't open yet, needs manual approval, or depends on something testers don't have (a company email, a paid plan, a physical device).

• Give each tester their own account. Shared accounts mix up data, kick each other out and make feedback hard to trace.
• Send credentials privately, not in a public group.
• Prefill enough data that every feature can be tried.
• If features are behind a subscription, decide how testers will reach them, for example with a test account that already has premium access. (If the app itself has an upfront price, closed testers must buy it.)

Option C: a mix

Many developers let testers sign up normally but keep a few prepared accounts ready for anyone blocked by SMS or email delivery. That keeps the realistic path while making sure nobody stalls for days.

Tell testers how to get in

Put the login instructions where testers will see them before they open the app:

• in the welcome message you send with the opt-in link (see how testers join your closed test)
• in the release notes for the closed track
• pinned in your tester chat, if you have one

Keep it short: how to sign up or which account to use, what to do if a code doesn't arrive, and who to contact. Then use the first day or two to confirm everyone actually got past the login. Our tips on keeping testers engaged and collecting feedback take it from there.

Common mistakes

• Credentials that worked once. A reviewer account that has since expired or been locked is the same as no account.
• OTP-only login with no bypass for the review account.
• Region-restricted backends. Testers or reviewers in another country hit a blocked API. Google requires reviewer credentials to work regardless of location, and testers need the same.
• Declaring "no restrictions" when part of the app sits behind a login.
• Forgetting to update the declaration after you change your login method.

Checklist

• Sign-in details declared under Policy and programs > App content
• Dedicated, reusable reviewer account with sample data
• OTP and 2-step bypass for that account
• Instructions in English
• Testers know how to sign up or which account to use
• Backend reachable from every tester's country
• Login checked from a clean device

This fits into the wider prep in our closed testing checklist.

If your testers come from GoPlayTester, they are based in Indonesia, so make sure your sign-up flow, verification messages and backend work there before testing starts. When you submit your app links on your GoPlayTester tracking page, there is an optional tester login field: add a test username and password there and our testers use that account. Our setup guide covers the Play Console side.