We are integrating the Android Developer Console API using the OAuth 2.0 Web Server flow with offline access and this scope:
https://www.googleapis.com/auth/androiddeveloperconsole
The API is enabled in the Google Cloud project. The OAuth identity is a verified Google Play developer account owner/admin. We reproduced the same behavior with two different verified developer accounts.
Observed behavior
ListDeveloperAccountssucceeds and returns the selected developer account asVERIFIED.ListAndroidPackagesfor that returned developer account consistently fails with HTTP 403 /PERMISSION_DENIED.CreateAndroidPackageconsistently fails with HTTP 400 /INVALID_ARGUMENTand onlyRequest contains an invalid argument., without field-level details.- The same Google identity can manually register a new package name in the Play Console UI.
Create request shape
POST https://androiddeveloperconsole.googleapis.com/v1/developerAccounts/{developerAccount}/androidPackages?androidPackageId=<new-package-name>
Authorization: Bearer <redacted>
Content-Type: application/json
{}
We use the official v1 contract (Discovery revision 20260912). We do not use a service account, Workload Identity Federation, or an API key for these authenticated developer operations.
We have already checked:
- The dedicated Android Developer Console API is enabled.
- The access token contains the required
androiddeveloperconsolescope. - The authenticated identity is a real Google account, not a service account.
- The developer account is verified and the identity has owner/admin permissions.
- The package name is syntactically valid and not already registered.
- Redirects are not followed automatically, so the original API response is preserved.
Could someone confirm:
- Do
ListAndroidPackagesandCreateAndroidPackagerequire additional allowlisting or preview eligibility for either the Cloud project or Play developer account? - Are these methods generally available to all verified developer accounts?
- Does the create request require an additional body field that is not represented in the published v1 contract?
- Is there a supported way to obtain more detailed diagnostics for the rejected permission or invalid argument?
I can provide exact UTC timestamps, redacted request/response headers, and resource identifiers privately to a Googler if needed.