How to Scrape Google Play Reviews With Python (and When Not To)

The fastest way to scrape Google Play reviews in Python is the `google-play-scraper` package: `pip install google-play-scraper`, call `reviews()` with a package name, and page through the results with the continuation token it hands back. Copy-paste code is below, and it works. But before you wire a pipeline on top of it, two things are worth knowing up front.

First, it's an unofficial scraper — it reads Google Play's internal web endpoints, so it can break the week Google changes them, and automated scraping runs against Google's Terms of Service. Second, and this is the part people learn the hard way: it gives you a pile of read-only data, not a way to actually reply. If your goal is competitor research or a one-off dataset, scraping is the right tool. If the reviews are on your own app and you need to answer them, you want a different door entirely. Here's both.

There are a few options, but the one people actually reach for is `google-play-scraper` (the JoMingyu package on PyPI). No API key, no OAuth, no Play Console access — you hand it a package name and it returns a list of review dicts. That zero-friction setup is exactly why it's fragile and why it isn't an official supported interface: it's reading the same JSON payloads the Play website loads, not a documented API surface with a stability contract.

The `app_id` it wants is the `?id=` value from a Play Store URL. For `play.google.com/store/apps/details?id=com.spotify.music`, the id is `com.spotify.music`. Every review is scoped to a language and a storefront, so the same app returns different reviews for `country="us", lang="en"` than for `country="br", lang="pt"`. There's no single global firehose — you scrape one storefront-language pair at a time.

`reviews()` returns a tuple: the batch of reviews plus a continuation token. To get the next page, you pass that token back in. The token encodes the whole query — sort, filters, storefront — so on continuation calls you don't repeat those params; the token carries them. Loop until a call comes back empty, and add a small `sleep` between requests so you're not hammering the endpoint from a single IP.

There's a shortcut for "just get everything": `reviews_all()` handles the paging internally. It's convenient, but it can be slow and memory-heavy on a popular app with hundreds of thousands of reviews, and it gives you less control over when to stop. For anything beyond a quick pull, the explicit token loop is the one to keep.

Each item in the list is a plain dict. The fields you'll actually use:

Honestly: automated scraping runs against Google's Terms of Service, which prohibit accessing the service through automated means outside their published APIs. `google-play-scraper` doesn't use a published API — it reads the site's internal endpoints. That doesn't mean your machine bursts into flames when you run it; a modest, well-behaved pull for research is a very different risk profile from a commercial product built on continuous scraping. But be clear-eyed that you're relying on undocumented behavior with no stability promise and no support channel when it breaks.

The practical failure mode isn't a lawyer — it's the endpoint. Scrape too fast from one IP and Google starts returning empty results or throttling you. There's no published rate limit to code against, so you treat it like any polite crawler: pace your requests, cache aggressively, and never re-fetch what you already have.

Here's the when-not-to. If the reviews you want are on an app you own, do not scrape them. Google publishes a real, supported interface — the Google Play Developer Reviews API (`reviews.list`, `reviews.get`, `reviews.reply`) — that authenticates with a service account, returns the reviews on your own apps, and, unlike any scraper, lets you post a reply back. It's ToS-compliant by definition, it doesn't break when the website's markup shifts, and it's the only path that can actually answer a customer. We break down its exact params and quirks in the [Google Play Reviews API reference](/blog/google-play-reviews-api-reference).

One hard number to design around: a Google Play developer reply is capped at 350 characters — that's a firm limit in both the console and the API, and it's tighter than the App Store's, where Apple publishes no official ceiling at all. Any reply tooling you build has to respect it. The scraper, of course, can't reply at all; the `replyContent` field just tells you whether someone already did. If replying is the goal — and for your own app it usually is — a read-only scrape is the wrong shape entirely. The two stores behave differently enough that it's worth reading [how App Store and Google Play review replies compare](/blog/app-store-vs-google-play-review-replies) before you commit to either.

Say you scrape 40,000 reviews and load them into a notebook. Now what? You have a CSV. You still have to cluster the complaints, decide which ones need a human, write a reply that sounds like your brand, translate it into whatever language the reviewer used, keep it under 350 characters, and — for your own app — push it back through the official API without letting anything lapse during a busy week. The scrape was the easy 10%. The workflow is the other 90%, and it's the part that actually moves your rating: Google said at I/O 2019 that developers who respond see about +0.7 stars on average. A dataset sitting in a notebook moves nothing.

That gap is the whole reason [ReplyArgus](/features) exists. It connects to your Play Console (and App Store Connect) through the official supported path — no scraping your own store — watches both stores in one inbox, and drafts a reply grounded in your past approved replies plus an auto-ingested knowledge base of your listing and marketing pages. It writes in the reviewer's own language, both directions, and keeps Play replies inside the 350-character limit for you. You approve each one, or set rules to auto-publish the easy cases by rating or keyword. It's the workflow the scraper was never going to give you.