DynoStaticAdmin sign in
Documentation

Google Play reviews

Google Play app reviews research contract

Reviewed: 2026-08-27 UTC

Research status: the official API provides authenticated access to recent, comment-bearing reviews of an operator's own production apps and permits manual reply creation or replacement. It is documented as a developer/customer-support integration, not as a public review-syndication surface. The current Google API terms prohibit permanent copies and third-party public display or distribution of returned content unless the content owner or applicable law expressly permits it. No reviewed Google Play source supplies that missing permission for a DynoStatic public widget.

This report is policy research only. It does not change the catalog, authorize API use, implement an adapter, or treat access to a Play Console account as ownership of reviewers' text.

Primary sources

Google can change these APIs, terms, permissions, quotas, and review behavior. Re-read the primary pages and the concrete response headers before any future readiness decision.

Decision rubric

The provider is suitable for a native DynoStatic review widget only if all of these questions have affirmative primary-source answers:

  1. Can each self-hosted operator authenticate only to apps it is authorized to manage, without DynoStatic brokering or sharing a credential?
  2. Does the official surface provide the review records and lifecycle signals needed for an accurate widget?
  3. May those records be stored for a defined duration and publicly displayed outside Google Play?
  4. May they be backed up, exported, synchronized to a local workspace, mixed, ranked, summarized, translated, or processed by AI?
  5. Can attribution, removal, disconnect, and credential revocation be implemented honestly?
  6. Can deterministic fixtures and an authorized live drill prove the result on ordinary PHP and MySQL hosting?

Questions 1 and 6 have workable technical answers. Question 2 remains incomplete even for recent records because Google may expose a new review to the developer before public publication while the API schema supplies no publication-status field. Questions 3 and 4 do not have the permission required for a public widget. Question 5 is also incomplete because the API supplies no public per-review URL, documented bulk lifecycle reconciliation for older locally retained reviews, or delete-reply method.

Own-app access and credential model

Official facts

  1. The operator must create or select a Google Cloud project, enable the Google Play Developer API, and grant access through its Google Play Console account. Linking the Play developer account to the Cloud project is no longer required.
  2. Google recommends a service account for secure server-to-server access. The service-account principal must be invited in Play Console and granted the necessary rights. The Reply to Reviews guide specifically requires the Reply to reviews permission for service-account use. Permissions should be limited to the selected app rather than granted across every app when the Console permits that narrower grant.
  3. An OAuth client is the documented alternative when a user accesses the API on their own behalf. The review endpoints require https://www.googleapis.com/auth/androidpublisher; the authorized user's Play Console permissions still bound what the client may do. Google's production OAuth policy separately requires verified branding and, unless an explicit exception applies, a public homepage that accurately describes the app and links its terms and privacy policy on a verified domain. Sensitive- or restricted-scope verification then depends on Google's current classification and applicable exceptions. An implementation must establish each prerequisite for the operator's project instead of treating a consent-screen configuration or an exception as automatic.
  4. The API is for feedback on the developer's own production apps. The review path contains a caller-supplied package name; the reviewed review API has no app-discovery method. Setup would therefore require an exact package name and a successful authorization probe. Possession of a package name is never authority.
  5. Service-account JSON contains a long-lived private key. Google says it must be kept secure and recommends service accounts only in a secure server environment. General API terms prohibit embedding developer credentials in open-source projects.

DynoStatic inference

A future private support-tool package could fit self-hosting if every installation operator supplied its own app-scoped service account or OAuth client. DynoStatic must never ship a shared Cloud project, service-account key, OAuth client, or hosted credential broker. A service-account private key would need owner-only setup, encryption at rest, memory hygiene, no webroot exposure, and exclusion from logs, diagnostics, exports, backups, static bundles, Automation, and local-workspace payloads.

Service-account JWT creation and OAuth token exchange can be implemented with ordinary PHP, OpenSSL, cURL, and the existing encrypted provider framework. Node is not a runtime requirement. That technical feasibility does not resolve the content-license problem.

Review surface, fields, and pagination

Official facts

  • GET https://androidpublisher.googleapis.com/androidpublisher/v3/applications/{packageName}/reviews lists reviews. reviews.get addresses one review by reviewId.
  • The API exposes only production-app reviews that include written comments. Rating-only feedback is absent.
  • The guide says the list contains only reviews created or modified within the previous week, with the most recently created or modified user comment first. The reference's short description saying “lists all reviews” must be read together with that explicit operational limitation; it does not provide lifetime history.
  • A page defaults to 10 reviews and may request at most 100. tokenPagination.nextPageToken is supplied when another page exists. The token must be treated as opaque. The reference also exposes startIndex, but token pagination is the safer continuity contract.
  • A Review contains reviewId, optional authorName, and a conversation-like comments list. A user comment can contain exact text, last-modified time, a 1–5 star rating, reviewer language, app version, device and device metadata, thumbs-up/down counts, and translated text plus originalText. A developer comment contains reply text and last-modified time.
  • Google says a newly submitted review can remain non-public for approximately 24 hours while the developer can already see and reply to it. Play Console exposes publication status, but the API Review schema has no equivalent field and the reviewed API documentation does not say whether held reviews are omitted from reviews.list or reviews.get.
  • The list response contains review rows, pagination, and page information. It does not contain the app's complete rating count, rating distribution, or authoritative aggregate rating. Google publishes those separately in Play Console reports.
  • When translationLanguage is supplied, Google may return translated text and retain the source in originalText. Translation is therefore an explicit request choice, not a property that should silently replace the original review.
  • The API does not return a public per-review Google Play URL. The private monthly CSV can contain a Play Console review link, but that is not a public attribution URL and must not be emitted to visitors.

Consequences

The API cannot populate a lifetime review corpus from a fresh connection, cannot represent rating-only users, cannot prove that every returned review is already public, and cannot produce an honest “Google Play average” or total review count. A completed page walk is complete only for the recent comment-bearing window returned in that run. It is not proof that an older stored review still exists, and absence from a later recent window is not a deletion signal.

Device model, operating-system, CPU, RAM, display, and app-version details are unnecessary for a review display and increase privacy exposure. A least-data adapter would reject or discard them rather than store them. It would map only review identity, optional author display name, exact original text, rating, relevant timestamps, exact developer reply, package identity, and a source label—if public use were ever separately authorized.

Replies

Official facts

  • POST .../applications/{packageName}/reviews/{reviewId}:reply creates a reply or replaces the existing one. The body contains replyText; approximately 350 characters is the maximum and HTML tags are stripped.
  • The review API exposes get, list, and reply only. It has no delete-reply endpoint, and the documentation does not define an empty reply as deletion. Deletion must not be invented by treating an undocumented value as a supported operation.
  • The user is notified after the first reply to a new or modified review. Developer replies appear publicly on the Play store page and must not contain sensitive user information.
  • Google discourages automated placeholder replies that are intended to be manually updated later. Play Console's developer-comment policy requires clear, relevant, truthful, civil, non-promotional, and clean responses.
  • Quotas are enforced separately per app: 200 review GET requests per hour and 2,000 reply POST requests per day. Google provides a quota-increase request route.

DynoStatic inference

If a future authorized package includes replies, every mutation should be an explicit, manual, CSRF-protected administrator action on one exact review. There should be no bulk reply, scheduled reply, rule-based reply, automatic placeholder, local-workspace reply route, or AI-generated/AI-posted response. An ambiguous transport outcome must be recorded as unknown, block a duplicate mutation, and require an authoritative reviews.get reconciliation. The local audit fact must omit reply bodies and credentials.

Because Google supplies no delete-reply method, DynoStatic cannot offer delete reply. The interface must say that limitation plainly rather than simulate success or replace the reply with whitespace.

Storage, redistribution, and attribution boundary

Official facts

  1. The general Google API terms say that, unless the content owner or applicable law expressly permits it, an API client may not scrape or build permanent copies, retain cached copies longer than response cache headers permit, copy or modify returned content, create derivative works, distribute it, publicly display it, sublicense it, misrepresent its source, or remove author/proprietary attribution.
  2. Google says review authors retain the intellectual-property rights in reviews they write. The author grants Google a license for operating, improving, and promoting Google's services. The reviewed terms do not state that this license grants an app developer the right to republish the review in an unrelated public website widget.
  3. The Reply to Reviews guide describes viewing feedback and interacting through a customer-support toolkit such as a CRM. It does not expressly authorize public republication of review bodies on the developer's website.
  4. Play Console offers private monthly review CSV reports and programmatic Cloud Storage access under Play Console permissions. That makes historical internal reporting technically available; it does not expressly grant public redistribution rights or override the API content restrictions.
  5. The API-specific documentation does not state a special Google Play logo or widget attribution treatment. The general terms require any documented attribution, prohibit false source/ownership statements, and reserve Google's brand features.

Research inference and required product policy

An app developer's authority to manage an app is not evidence that every reviewer licensed their prose for republication. Public availability on Google Play is also not an implied API redistribution license. The absence of a Google Play-specific public-display grant is therefore a blocker, not an invitation to choose a convenient cache duration.

Until Google or the review's content owner gives express permission covering this exact use, Google Play review bytes must not enter any DynoStatic public widget, review table, cache, backup, Import / Export payload, local workspace, Automation resource, portable bundle, static export, migration package, analytics/sentiment system, search index, or AI context. The private Play Console CSV must not be treated as a loophole or silently imported into the public review engine.

The same boundary rules out provider mixing, blended ratings, ranking, minimum-star filtering, curation, helpful reactions, rewriting, summarization, sentiment analysis, AI training, AI generation, and third-party translation. These operations either redistribute the content, create derivatives, or analyze a partial and non-representative comment-only sample. Google's own documented translation parameter is technically available, but it does not cure the independent public-display restriction; a future permission would still need to specify whether and how translated text may be shown alongside the original.

If express public-display authorization is later obtained, the approved attribution contract must be written before code: preserve the exact author name when supplied, original review text, rating, time, developer reply, a plain and accurate Google Play source label, and an app-listing link; never imply Google endorsement or use a Google logo without applicable brand permission. A private Play Console URL is never a visitor-facing source link.

Disconnect, deletion, and revocation

There is no valid local review corpus to retain under the present decision. A connection attempt should therefore not be implemented. Any future authorized design must still satisfy these lifecycle rules:

  • disconnect first stops jobs and public eligibility, purges all provider-derived bytes and cached/derived forms, then destroys local reusable credentials;
  • OAuth mode makes a best-effort request to Google's revocation endpoint and provides manual connected-app remediation when remote revocation cannot be confirmed;
  • service-account mode cannot safely delete the operator's remote IAM key with the review credential itself. Local key destruction must be immediate, while the operator is directed to remove the principal's Play Console permission and disable/delete the service-account key in Google Cloud;
  • deleting a service-account key does not revoke already-issued short-lived access tokens, so a high-assurance operator may need to disable/delete the service account as Google's IAM documentation describes;
  • app transfer, permission removal, key rotation, package removal, OAuth revocation, 401, and 403 all fail closed without retaining a stale public projection; and
  • a user editing or deleting an older review cannot be inferred from its absen