Google Play API 401: 'This Developer Account Does Not Own the Application' — the Real Fix
The Google Play API 401 'this developer account does not own the application' is a permission-linkage bug, not ownership. Here's the fix, diagnosed in order.
The Argus Team
Reply Argus
A Google Play API 401 that reads *'This developer account does not own the application'* almost never means what it says. Your OAuth token is valid and your developer account is fine — the request authenticated cleanly. What failed is authorization: the service account behind that token hasn't been granted permission to act on this specific app inside Play Console. The reason code buried in the JSON is `developerDoesNotOwnApplication`, and it fires from a short, fixable list of linkage gaps.
The trap is that the word *own* sounds like a billing or account-transfer problem, so people go check everything that isn't broken: developer registration, whether the app is published, the payment profile. None of that is it. Below is the error exactly as the API hands it back, why a good token still gets rejected, and a diagnosis you can run top to bottom in about ten minutes.
What the 401 actually looks like
When you POST a reply and hit this wall, the androidpublisher API returns a 401 with a nested `errors` array, and the line that matters is the `reason` (the machine-readable cause, more precise than the human message). Log the full body: the top-level `message` is generic, but `reason: developerDoesNotOwnApplication` tells you exactly which class of problem you're in.
POST https://androidpublisher.googleapis.com/androidpublisher/v3/applications/com.yourcompany.app/reviews/gp:AOqpTO.../reply
Authorization: Bearer ya29.c.b0AX...
Content-Type: application/json
{ "replyText": "Fixed in 5.2 — thanks for flagging it." }
--- response ---
HTTP/1.1 401 Unauthorized
{
"error": {
"code": 401,
"message": "This developer account does not own the application.",
"errors": [
{
"reason": "developerDoesNotOwnApplication",
"domain": "androidpublisher",
"message": "This developer account does not own the application."
}
]
}
}Why a valid token still gets a 401
Google Play's reviews resource is a server-to-server API, so you authenticate as a service account — a non-human identity in Google Cloud that holds a private key and mints its own access tokens. For that token to do anything, two independent things have to be true, and they live in two different consoles. The Cloud project that owns the service account must be linked to your Play Console. Separately, the service account's email identity must be invited into Play Console with the 'Reply to reviews' permission actually ticked.
Linking makes your apps *visible* to the service account. The permission grant makes them *writable*. You can complete the link, see a green checkmark, mint a perfectly scoped token — and still 401, because the token authenticated but was never authorized to touch this app. That's the whole illusion behind the ownership error. If you haven't wired the two handshakes yet, the [Google Play service account setup for replies](/blog/google-play-service-account-setup-for-replies) walks the full path; this page is for when you've done it and the 401 shows up anyway.
The fastest tell: do reads work but replies fail?
Call reviews.list first. If list and get succeed but reviews.reply 401s with developerDoesNotOwnApplication, you almost certainly granted 'View app information' but not 'Reply to reviews' — they're separate checkboxes. If even list 401s, the problem is earlier: the project link, the package name, or an app that's outside the service account's scope. This one test splits the causes in half before you touch anything.
Diagnose it in order
Walk these in sequence. Each step either clears a cause or points at it, and they're ordered cheapest-first — most 401s die at step 2 or step 4.
- 1
Step 1 — Confirm the token is really scoped
Introspect it before blaming permissions. Run `curl "oauth2.googleapis.com/tokeninfo?access_token=ya29..."` and confirm the `scope` field contains `www.googleapis.com/auth/androidpublisher`. A missing scope usually throws an insufficient-scope 403, not this 401 — but rule it out so you're not chasing a permission gap that's actually a scope bug.
- 2
Step 2 — Verify 'Reply to reviews' is actually ticked
In Play Console → Users and permissions (or Setup → API access → Manage Play Console permissions), open the service account's email and confirm 'Reply to reviews' is checked, not just 'View app information'. This is the number-one cause. Linking the Cloud project does NOT grant it — it's a separate save.
- 3
Step 3 — Match the key to the granted account
Open your JSON key and read `client_email`. It must be the exact same address you granted in Step 2. Teams that manage several service accounts routinely download a key from the wrong one — the token is valid, it's just a different identity that owns no apps here.
- 4
Step 4 — Check the package name character-for-character
The `{packageName}` in the URL is the applicationId (com.yourcompany.app) — not the display name or the `gp:` review prefix. A typo'd or wrong package the service account can't map to an owned app returns THIS ownership 401, not a 404: Google won't say the app doesn't exist, only that you don't own it.
- 5
Step 5 — Confirm the app is in scope
If in Step 2 you used App permissions (per-app) instead of account-wide access, the app you're calling has to be in that allow-list. An app outside it reads as 'does not own the application', identical to a missing grant. Either add the app or switch the grant to account-wide.
- 6
Step 6 — Rule out propagation and the wrong console
A 401 in the first minutes after granting is often just Google catching up: a new permission or link doesn't always apply instantly and can lag for a while. Wait and retry before debugging further. Also confirm the linked project under Setup → API access belongs to the Play Console that actually owns the app, not a second developer account you also manage.
The cause the checklists miss: right permission, wrong identity
Most guides stop at 'you forgot to grant the permission.' The subtler failure, the one that eats an afternoon, is that the permission is granted correctly to service account A while your code authenticates as service account B. Both are valid Google identities that mint tokens passing authentication, but only one owns any apps here. The API can't tell you that you picked the wrong key file, so it falls back to the generic ownership error.
This is why Step 3 matters more than it looks. The `client_email` inside the JSON key is the ground truth for *who you are* on every call, so diff it against the email under Users and permissions. If they don't match to the character, you found it: either regrant the permission to the identity your key belongs to, or point your code at the key for the identity you already granted. Rotating keys and copy-pasted CI secrets are the usual ways the two drift apart.
Don't thrash on a 401 that's just propagating
If you granted the permission in the last few minutes and everything else checks out, stop editing. Re-granting, re-linking, and regenerating keys while access is still propagating just adds new variables to a setup that was about to work. Grants aren't always instant, so give it a real 15 to 30 minutes before you assume a misconfiguration.
Once the linkage is right, the same POST that 401'd returns a 200 with your reply text and a `lastEdited` timestamp, and the response lands under the review within the day. That's the payoff — and it's not cosmetic. When Google announced recency-weighted ratings at I/O 2019, it reported that developers who respond to reviews see an average lift of 0.7 stars. Under Play's hard 350-character reply cap, a reply that earns that lift looks like this:
Latest update broke sync. My notes stopped showing up on my tablet and I lost two days of edits. Uninstalling. Pixel 8 Pro.
This is a real sync regression in 6.1 on Android 14, and it's fixed in 6.1.2 (rolling out now). Your notes aren't lost — they're saved server-side and will reappear once you update and reopen the app. Please give it a try and reply here if anything's still missing; we'll pull your account and recover it directly.
That's the mechanical half solved. The other half is keeping up with reviews across both stores without the API build becoming a second job, and that's where most teams quietly give up. The reviews endpoint only returns the last seven days, there's no webhook for new reviews, tokens expire hourly, and every reply has to be trimmed to 350 characters. The full shape of that is in the [Google Play reviews API reference](/blog/google-play-reviews-api-reference). [ReplyArgus](/features) runs exactly that plumbing for you: it holds the service-account linkage, polls Google Play and the Apple App Store on a schedule, keeps history past the seven-day window, and drafts an on-brand reply for each review already fitted to Play's cap, so you approve instead of debug.
Or skip the OAuth build entirely
If the goal is to reply to reviews, not to run token-refresh and quota-backoff code, you can hand the whole handshake off. [ReplyArgus](/agentic-tools) exposes your live App Store and Google Play reviews to Claude, ChatGPT, or Cursor over an MCP connector — so instead of debugging a 401 you ask your agent to 'draft replies to my unanswered 1-stars' and approve the results. If you'd rather stay in the console, [replying by hand in Play Console](/blog/how-to-reply-to-reviews-in-google-play-console) needs no service account at all.
Frequently asked
- What does 'this developer account does not own the application' mean on the Google Play API?
- It's a 401 with the reason code `developerDoesNotOwnApplication`, and despite the wording it's almost never a real ownership problem. Your token authenticated fine — the service account behind it just hasn't been granted permission to act on that specific app inside Play Console. It's an authorization gap, not an account issue.
- Why does my token work but replies still return a 401?
- Usually because you granted 'View app information' but not 'Reply to reviews' — they're separate permissions. If reviews.list and reviews.get succeed while reviews.reply 401s, that's the signature of the missing reply permission. Tick 'Reply to reviews' for the service account in Play Console and retry.
- Can a wrong package name cause the 401 ownership error?
- Yes. The `{packageName}` in the URL must be the exact applicationId (like com.yourcompany.app), not the display name or the Play Store listing id. A typo or a package the service account can't map to an owned app returns this ownership 401 rather than a 404 — Google reports it as 'you don't own it,' not 'it doesn't exist.'
- I granted the permission but still get 401 — what now?
- Check two things the checklists miss. First, propagation: a new grant doesn't always apply instantly, so wait 15–30 minutes before assuming a bug. Second, identity: open your JSON key's `client_email` and confirm it exactly matches the account you granted in Play Console. Managing several service accounts, it's easy to authenticate as the wrong one.
- Is this the same as a 403 'API not enabled' error?
- No — different failure. A 403 usually means the Google Play Android Developer API isn't enabled on the Cloud project, or the token lacks the `androidpublisher` scope. The 401 `developerDoesNotOwnApplication` means the API is reachable and the token is scoped, but the service account isn't authorized for this app. Fix the 403 in Google Cloud; fix the 401 in Play Console.
- How do I avoid the whole service-account 401 dance?
- Use a tool that already holds the linkage. ReplyArgus manages the service-account OAuth, polls Google Play and the App Store, and drafts replies sized to Play's 350-character cap — you just approve. There's no token, scope, or permission grid to debug.
The Google Play API 401 is a linkage error in an ownership costume: a valid token, an ungranted service account, and a message that points you at the wrong things. Work the six steps in order and one of them is always the culprit. If you'd rather not own the OAuth plumbing at all and just answer reviews across both stores before the moment passes, [start free with ReplyArgus](/signup): no card, and it drafts your first reply in minutes, already fitted to Play's 350-character limit.
Try it
Let Argus draft your next reply.
Watch it answer a real review in your voice. 10-day trial, no card to begin.
Keep reading
App Store Reviews Not Showing? The Full Fix List for Apple and Google Play
App Store or Google Play reviews not showing? Here's every real cause — moderation delay, wrong country storefront, filtering, rating lag, cache — and the fix.
Read moreAre App Store Reviews Fake? How to Spot Them and What to Do
Yes, some App Store and Google Play reviews are fake — but fewer survive than you think. How to spot them, and what to do when they hit your app.
Read more