Google Play Console permissions explained
Play Console permissions come in two scopes, and mixing them up is the cause of most "the caller does not have permission" errors. Account permissions apply to all apps in your developer account. App permissions only apply to the selected app. That is Google's own wording, and it is the whole model in two sentences.
The practical consequence: you can grant a teammate or a service account permission to release one app to testing tracks without giving them anything on your other apps. You can also accidentally grant them nothing at all, by ticking boxes on the Account tab when you meant the App tab, or the reverse.
The three access levels
Above the individual permissions sit three levels of person:
- Account owner. The Google account that created the developer account. Manages payments and cannot be reassigned casually.
- Admin. Delegated management rights, including inviting other users.
- User. Everyone else, with whatever permissions you tick.
There is also a permission literally called Admin (all permissions), available at both account and app level, which is the "give up and grant everything" option. Use it on purpose or not at all.
The permission list, by scope
Some permissions exist only at account level, some only at app level, and most at both. Google notes that "Some permissions are exclusively available to app or account level users only", which is why the two tabs do not mirror each other.
Account level only:
- View app information and download bulk reports (read only)
- Create, edit, and delete draft apps
- Edit Google Play games services projects
- Publish Google Play games services projects
App level only:
- View app information (read only)
- Edit and delete draft apps
- View financial data
Available at either level:
- Admin (all permissions)
- Manage policy declarations
- Manage orders and subscriptions
- Release to production, exclude devices, and use Play App Signing
- Release apps to testing tracks
- Manage testing tracks and edit tester lists
- Manage store presence
- Reply to reviews
- Create and publish private apps to your organization
The release permissions are the ones that bite
Notice that releasing is split into three separate permissions, and they are not a ladder. They are independent.
Release apps to testing tracks covers internal, closed and open testing. It does not cover production.
Release to production, exclude devices, and use Play App Signing is Google's exact checkbox name, and it gates production releases and promotions from a testing track to production. Without it, an internal release succeeds and then promoting that same release to production fails.
Manage testing tracks and edit tester lists is separate again. Someone can be allowed to push a build to a closed track without being allowed to change who is in it.
This split is genuinely useful. If you want a tool or a junior engineer to be able to ship to testers all day but want the production button to stay a human act performed by a specific person, grant testing-track release and withhold production release. That is a deliberate policy, not a limitation.
Manage store presence is the other one people miss. It is the permission that covers editing the store listing, and it is described in the console under Store presence as "Edit your store listing...". Without it, pushing a description or screenshots through the API fails with "the caller does not have permission", even though the account authenticated perfectly.
Adding a teammate safely
Users and permissions → Invite new users. Enter the email address, optionally set an access expiry date, then set permissions on the Account permissions and App permissions tabs, and select Invite user.
Two details matter:
The email address must match exactly. Google states that users must sign in using the exact email address that was invited. An invite sent to a personal Gmail address cannot be accepted by the same human's work account.
Use the expiry date. For a contractor, an access expiry date is the difference between remembering to revoke access and not having to.
The least-privilege pattern for a teammate who writes listings and answers reviews, with no release rights at all, is app-level: View app information (read only), Manage store presence, Reply to reviews. Nothing else.
Adding a service account safely
A service account is invited the same way a human is, because to Play Console it is just another user with an email address. The full setup spans two consoles: you create the account and its JSON key in Google Cloud Console, then invite its client_email address, the one ending .iam.gserviceaccount.com, into Play Console and grant permissions there.
That split is the single most misunderstood thing about Play automation. Google Cloud says who is calling. Play Console says what that caller may do to your apps. A service account with Google Cloud's Editor role and no Play Console permissions can do precisely nothing to your apps.
So do not grant it Google Cloud IAM roles. It needs none. Grant it Play Console permissions instead, and grant the narrow ones:
- View app information (read only) as the baseline
- Manage store presence if it pushes listings or screenshots
- Edit and delete draft apps if it works on apps not yet published
- Reply to reviews if it handles a review inbox
- Release apps to testing tracks if it ships to testers
- Release to production, exclude devices, and use Play App Signing only if you actually want it pressing the production button
Prefer app-level grants over account-level ones for a service account. If the automation only touches one app, there is no reason for its credential to reach the others.
Give each system its own service account, named after the system. When you need to revoke one, you want the damage to be one pipeline.
Why permissions appear not to work immediately
This is the question that brings most people to this page, and there are four separate causes with the same symptom.
Cause one: you granted the permission at the wrong scope. An account-level grant does not appear on the App tab, and vice versa. Check both tabs for the user before assuming propagation.
Cause two: the session is stale. A signed-in user carries their old permissions until they sign out and back in, or hard-refresh. This is the most common false alarm.
Cause three: the invite has not been accepted. An invited user has no permissions at all until they accept and sign in with the exact invited address. A service account has no equivalent acceptance step, which is why service accounts are actually simpler here.
Cause four: genuine propagation delay. New grants sometimes take a few minutes to be reflected by the Play Developer API, even when the console shows them as ticked. If verification fails immediately after inviting, wait and retry before changing anything.
The debugging order that saves time: retry once, then check whether the user or service account appears in Users and permissions at all, then check which tab the boxes are ticked on, then sign out and in, and only then conclude it is propagation.
Reading a permission error properly
The Play Developer API returns the same unhelpful string, "The caller does not have permission", for every one of these. It does not say which permission is missing. So the useful diagnostic is not the error text, it is what the caller managed to do before failing:
- Authenticated but cannot read anything: the account is not in Users and permissions at all, or the API is not enabled on the Cloud project
- Can read app info but cannot save a listing: missing Manage store presence
- Can ship to a testing track but cannot promote: missing Release to production, exclude devices, and use Play App Signing
- Can ship a build but cannot change the tester list: missing Manage testing tracks and edit tester lists
AppSubmit verifies a service account against Google the moment you upload the JSON and names the specific permission that is missing rather than repeating Google's string, which is the same mapping as the list above. You can do it by hand with that list and the two tabs.