Google Play Unofficial API: App Metadata and Reviews

There is a Google Play API. It’s just not the one you want. The Google Play Developer API exists to manage your own apps — publishing releases, reading your app’s reviews, editing your store listing. It is OAuth-scoped to a developer account and a package you own. What it explicitly does not do is let you read public metadata or reviews for any app on the store. There is no public, read-only “browse the catalog” endpoint at all. So if you need app metadata, ratings, or competitor reviews across apps you don’t own, you’re looking at a Google Play unofficial API built from the public store pages and the same internal RPC the web front-end uses. This guide walks through how that surface actually works.

The official API gap, precisely

To be exact about what’s missing:

• Play Developer API (androidpublisher) — manage your own app. Requires you to own the package. Useless for competitor or market research.
• Play Developer Reporting API — analytics for your own apps only. Same ownership wall.
• No public catalog/search API. Unlike Apple’s iTunes endpoints (thin as they are), Google ships nothing public for reading arbitrary app data. The store is web-only.

That last point is the whole reason a Google Play unofficial API has to exist: Google never gave third parties a read door, so the only door is the website.

What the public store page exposes

Every app lives at a predictable URL:

https://play.google.com/store/apps/details?id={packageName}&hl=en&gl=US

The hl (language) and gl (country) parameters matter — they change the localized title, description, and which reviews and rating you see. The page is server-rendered and embeds the data in inline <script> blocks (Google’s AF_initDataCallback payloads). Parsing those blobs gives you, per app:

• Title, developer name, developer email and website, privacy policy URL.
• Full description and the “what’s new” / recent-changes text.
• Aggregate score, rating count, and the 1–5 star histogram (Apple doesn’t even give you this).
• Install bucket (e.g. “1,000,000,000+”), content rating, last-updated date, current version, minimum Android version.
• Screenshots, icon, feature graphic, video trailer URL.
• The “similar apps” cluster and the developer’s other apps.

It’s positional-array JSON — fragile, undocumented, and reorganized periodically by Google — but it’s complete.

Reviews: the batchexecute RPC

Reviews are the part people most want and the part that isn’t on the static page beyond a teaser. Google Play’s web client fetches reviews through its generic batchexecute RPC endpoint:

POST https://play.google.com/_/PlayStoreUi/data/batchexecute

You send a form-encoded f.req parameter containing the RPC ID for “get reviews,” the package name, a sort order (most relevant / newest / rating), a page size, and a pagination token. The response is the classic anti-CSRF-prefixed ()]}') chunked JSON Google uses everywhere. Each review object carries author name, avatar, star rating, review text, timestamp, thumbs-up count, app version reviewed, and the developer’s reply if one exists. The response also returns a continuation token you feed back to fetch the next page.

This is the same call the play.google.com front-end makes, so it requires no login — just the right RPC ID and a well-formed f.req.

▶ Try the Google Play Data API on Apify — store metadata plus paginated reviews via the batchexecute RPC, no Play Console account needed. No auth required.

Rate limits and how to live with them

Google doesn’t publish a rate limit for these surfaces because they aren’t an official API — which cuts both ways. There’s no documented budget, but Google is excellent at bot detection. Practical guidance:

1. Throttle aggressively — keep a single IP under ~10–15 requests/min across pages and RPC calls. Bursting is what triggers challenges.
2. Always send hl and gl consistently within a run. Mixing locales mid-session looks unnatural and fragments your data.
3. Expect soft blocks, not 429s. Google tends to serve a consent page or an empty payload rather than a clean error. Detect the consent redirect and back off.
4. Use a residential or rotating pool for scale. Datacenter IPs hitting batchexecute at volume get flagged faster than IPs hitting plain store pages.

A clean output schema

One row per app per locale, reviews attached:

{
  "package_name": "com.spotify.music",
  "country": "US",
  "language": "en",
  "title": "Spotify: Music and Podcasts",
  "developer": "Spotify AB",
  "developer_email": "support@spotify.com",
  "category": "Music & Audio",
  "score": 4.4,
  "ratings_total": 32115400,
  "rating_histogram": { "1": 1200000, "2": 410000, "3": 980000, "4": 3100000, "5": 26425400 },
  "installs": "1,000,000,000+",
  "current_version": "9.0.12",
  "min_android": "8.0",
  "content_rating": "Teen",
  "last_updated": "2026-05-30",
  "recent_reviews": [
    {
      "author": "Maria K.",
      "rating": 1,
      "text": "Shuffle is broken since the update.",
      "version": "9.0.12",
      "thumbs_up": 214,
      "developer_reply": "Hi Maria, please reach out to support...",
      "posted_at": "2026-06-02T17:40:00Z"
    }
  ],
  "scraped_at": "2026-06-05T12:00:00Z"
}

Use package_name + country + language as the natural key — the same app is genuinely different data in each locale.

Use cases

• Competitor review mining — pull the newest negative reviews for rival apps daily and route them to product as feature requests.
• Crash / regression signal — a spike in 1-star reviews mentioning a version number is an early outage indicator before your own funnels show it.
• Market sizing — install buckets and rating counts across a category give a rough demand map without paid intelligence tools.
• Localization gaps — compare title/description across gl values to spot storefronts where a competitor never localized.
• Developer contact enrichment — the public developer email and website feed B2B prospecting for app-tooling vendors.

Build it yourself vs. a managed actor

Parsing one store page is a one-hour job. The batchexecute reviews RPC is where most people give up: you have to reverse the f.req envelope, find and pin the correct RPC ID (Google rotates them), decode the )]}'-prefixed chunked response, and manage continuation tokens — all while dodging consent redirects. And because none of it is documented, every Google front-end refactor can quietly break your parser. A managed Google Play unofficial API absorbs that maintenance so you’re not re-reversing the RPC envelope every quarter.

Common pitfalls

• Positional-array brittleness. The store-page JSON is index-addressed, not key-addressed. A new field shifts every offset. Parse defensively.
• Consent-wall responses. In the EU especially, an un-consented request returns a cookie-wall page, not data. Detect and handle it.
• Locale leakage. Forget gl/hl and Google guesses from IP, silently mixing your dataset across countries.
• Review pagination caps. You can page deep, but the RPC eventually stops returning new tokens. Don’t assume infinite backfill.
• Rotating RPC IDs. The reviews RPC ID is not a stable contract. Pin it, but expect to refresh it.

Wrapping up

Google never shipped a public read API for the Play Store, and the Developer API is walled to apps you own — so the only path to broad app metadata and reviews is a Google Play unofficial API built on the public store pages and the batchexecute RPC. It’s completely doable, it requires no login, and it’s also a maintenance treadmill thanks to undocumented, frequently-reshuffled payloads. If you’d rather not babysit the RPC envelope, a managed actor returns the same normalized data on demand.

▶ Open the Google Play Data API on Apify — export app metadata, rating histograms, and reviews across locales without a Play Console login. Pay per result.