The Google Play Reviews API: Quotas, the 7-Day Window, and Workarounds

The Google Play reviews API lives inside the Google Play Developer API as the `reviews` resource, and it gives you exactly three methods: `reviews.list` to pull recent reviews, `reviews.get` to fetch one by id, and `reviews.reply` to post a developer response. You authenticate with an OAuth service account, your reply text is capped at a hard 350 characters, and — the part that trips up almost everyone — the API only returns reviews from the last seven days. There is no backfill endpoint.

That last constraint is the one that ends most integration plans, so it's worth internalizing up front: the API is a live feed for recent activity and a reply channel, not an archive you can query for history. Below is the working reference — how to authenticate, the three calls with real request shapes, the two quota ceilings, the seven-day window and its only real workaround, and the fix for the `401` that stops nearly every first attempt.

The single biggest mistake on day one is reaching for a normal OAuth user-consent flow. The reviews resource is a server-to-server API — you authenticate as a service account, not as yourself. A service account is a non-human identity you create in Google Cloud; it gets a private key, requests its own access tokens, and acts on the app's behalf with no interactive login. Every review call carries a bearer token minted from that service account and scoped to `www.googleapis.com/auth/androidpublisher`.

There are two linkages that both have to be right, and this is where the setup goes sideways. First, the Google Cloud project that owns the service account has to be linked to your Play Console account. Second, the service account itself has to be invited into Play Console as a user and granted permission to reply to reviews on the specific app. Miss either one and your token is valid but powerless — you'll authenticate fine and then get told you don't own the app. Here's the order that works:

Every request hits `androidpublisher.googleapis.com/androidpublisher/v3/applications/{packageName}/reviews`, where `{packageName}` is your app's id (for example `com.yourcompany.app`). `reviews.list` returns recent reviews that have written comments — star-only ratings never appear, because there's no text to reply to. `reviews.get` fetches a single review by its id. `reviews.reply` posts your response to a review's `:reply` sub-path with a small JSON body.

One useful detail on `list`: pass `translationLanguage` and Google returns a machine translation of each review alongside the original, which is handy for triage across markets. Pagination is token-based — the response hands you a `tokenPagination.nextPageToken` you feed back as `token` on the next call, but remember it only ever pages within the seven-day window.

Each review in the `list`/`get` payload carries more than a star and a comment. You get the reviewer's language, the raw text plus an optional machine translation, the last-modified timestamp, and a `userComment` metadata block with the device model, Android OS version, and the app version code the review was left on. That last field is the quietly valuable one: it lets a reply name the exact build a bug landed in, which is what the widget example below leans on. Note too that there is no push or webhook for new reviews — Google gives you no callback, so a fresh review only surfaces when you next call `list`. Catching reviews promptly is entirely on your polling cadence.

A successful `reply` returns the text you posted plus a `lastEdited` timestamp. Each review holds exactly one developer response, so calling `reply` again on the same review edits the existing reply rather than stacking a second one — useful when you want to update an answer after a fix ships.

`replyText` over 350 characters is rejected outright — this isn't a soft guideline you can occasionally exceed, it's a validation error. Google Play's cap is the tighter of the two big stores to design around: Apple publishes no official character limit for App Store responses, and community testing suggests you can run to a few thousand characters there, but on Play you get 350 and not one more. If you're templating replies for both stores, build to the Play ceiling and Apple takes care of itself.

Three hundred and fifty characters is less room than it sounds, and it forces a good habit: lead with the fix, cut the throat-clearing. The [character caps and formatting rules for every store](/blog/reply-rules-for-every-app-store) are worth a skim if you template across both, and we cover the wider set of mechanical differences in [App Store vs Google Play review replies](/blog/app-store-vs-google-play-review-replies). Here's what a reply that respects the cap actually looks like:

That's 273 characters: names the bug, gives a workaround, promises a version, no filler. It's also the reply that actually moves your number — 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, and we dig into why in [does replying to app reviews raise your rating](/blog/does-replying-to-app-reviews-raise-your-rating).

The reviews API enforces two ceilings, applied separately and per-app, so a multi-app account gets its own budget on each title. Google's Reply to Reviews docs put them at:

This is the design decision that reframes the whole integration. The API isn't a database you query — it's a stream you have to catch. Anyone who wants a durable, searchable review history has to stand up a poller that runs on a cron, dedupes on review id, writes to their own store, and reconciles against the CSV export for the pre-history. That's a small service, an ops burden, and a set of edge cases (token refresh, quota backoff, propagation delays) that you now own. This is the exact plumbing [ReplyArgus](/features) runs for you: it holds the service-account OAuth, polls both Google Play and the Apple App Store on a schedule, keeps the full history past the seven-day window, and drafts an on-brand reply for each review in the reviewer's own language — already fitted to Play's 350-character cap — so you approve instead of build.

This is the error that stops nearly every first attempt, and it's misleading — it almost never means what it says. Your token is valid; the problem is the linkage between the service account and the app. The reason code is `developerDoesNotOwnApplication`, and it comes from one of a short list of causes:

So the Google Play reviews API is small and honest about what it is: three calls, a service-account handshake, two quotas, a 350-character reply, and a hard seven-day window that turns any history requirement into a polling service you have to build and babysit. If that's the project, this reference is the whole map. If the actual goal is just to keep up with every review across both stores and answer well before the moment passes, that's the part worth handing off — [start free with ReplyArgus](/signup), no card, and it drafts your first reply in minutes, already sized for Play's 350-character limit and grounded in your own past replies.