Nothing here reads Play Console, and nothing here can. Read this before assuming any part of this capability talks to Google.
The requirement
This is the rule the capability exists to help you meet, and the reason its headline number is an estimate rather than a count. Using Testers runs the roster; pithy testers reports it; the reference marks which fields are inferred.
Developers with personal accounts created after 13 November 2023 must run a closed test with a minimum of 12 testers opted in for at least the last 14 days continuously.
Three details do most of the damage:
The days must be consecutive. Google states it outright — testers who opted in, tested for less than 14 days and then opted out are not counted, and opting back in does not accumulate. Lose one tester on day nine and the clock effectively restarts.
Internal testing does not count. Only closed testing satisfies it.
It applies to personal accounts. Organization accounts are not subject to it.
The requirement launched at twenty testers and was later reduced to twelve, with the same window. Treat it used to be 20, it is now 12 as well established and the exact change date as unconfirmed — the secondary sources naming one are not Google.
The hundred-tester figure is about a different track
You will see “maximum 100 testers” repeated widely. It is real, and it is about internal testing.
Closed testing — the track the requirement actually runs on — has no such cap. Its limits are 2,000 users per email list, 50 lists per track, and 200 lists per account. Google states no maximum tester count on the requirement page at all.
This capability defaults a roster cap to 100 anyway, and says why: a hundred is roughly the number of people one developer can still chase by hand. That is a management judgment, not a store limit, and you can raise it.
What the Play Developer API exposes
Very little, and none of the part you want.
Tester management is Google-Groups-only. The testers resource has exactly one field — a list of Google Group addresses. Its methods are get, patch and update. There is no list, no per-tester resource, and no create or delete of an individual tester.
The limitation is documented on every method: while the Console UI can add testers via email lists, email lists are not supported by this resource.
So for the ordinary setup — a list of addresses added in the Console — the API is blind. It cannot read your roster, and it cannot write it.
The opt-in count is not readable. Not the streak, not the plain count. The v3 resource inventory contains no testing-metrics resource at all, and the Reporting API covers app quality — crashes, ANRs, wake-locks — not tester counts. The figure lives on one Console screen, and developers report it as unreliable even there.
Opt-out is not detectable. No tester-state resource, and no webhook: Play’s only push channel carries subscription and voided-purchase events. Google clearly tracks opt-out server-side — its own wording depends on it — and exposes it only to its own eligibility check.
What the API does cover is release management: tracks, version codes, staged-rollout fractions, country targeting, halt and resume. Genuinely useful, and genuinely not this capability.
Apple, for contrast
App Store Connect exposes almost exactly what Google withholds.
The beta-testers endpoint returns the roster with names, addresses, invite type and state — and testers can be added and removed individually.
BetaTesterState is a first-class readable attribute: not invited, invited, accepted, installed, and revoked — where revoked means the tester chose to stop testing or was removed. That is a machine-readable opt-out signal, which is the single largest gap between the two stores.
Per-tester sessions and crashes are still Console-only, and excluded even from Apple’s own export.
Apple has no minimum-tester or minimum-duration requirement. Nothing analogous exists. What Apple does have is a guideline prohibiting distributing TestFlight builds in exchange for compensation of any kind — so the paid-tester-farm ecosystem that grew around Google’s rule is an App Review violation on iOS.
Auth is an ES256 JWT signed with a .p8 key, and App Store Connect rejects tokens with a lifetime greater than twenty minutes for these resources.
The sequencing this forces
Because the API cannot add an address to an email list, that step is manual. And the store’s opt-in link does not work for a tester until it is done — they get App not available, which reads to them as a broken app rather than as a step you have not taken.
So the journey is two messages:
- “Will you help test?” — this capability’s own link, recording consent and confirming the address is deliverable before it goes on a Google-visible list.
- You add the confirmed addresses to Play Console.
- “You’re on the list — here’s the link” — carrying the store’s own opt-in page.
The store link is rendered, never redirected to. A 302 would make your Worker a redirector, and it leaves nowhere to put the two instructions that prevent most failures: open it in a browser rather than the store app, and sign in with the address the email reached you at.