Google Play Reviews Scraper

Get Google Play app reviews and app details (ratings, installs, developer info) by app ID or search term. HTTP-only (no browser), so runs are fast and cheap, and you're charged only for the rows you actually get.

It works as a Play Store data API and a Google Play data API in one Actor: pull the same review and app-details fields — ratings, installs, developer info, aspect ratings — as a clean dataset instead of scraping the storefront yourself. Use it as a mobile app reviews data source for any Android app, with country/language targeting and de-duplicated, watch-mode-ready results.

What it does

• Fetches reviews for one or more Google Play apps, plus an optional app-details record (title, developer, score, installs, price, description, rating histogram).
• Accepts package names (com.spotify.music), full Play Store URLs (paste the link straight from your browser), or searchTerms — the top matching app for each term is resolved automatically.
• Supports country/language targeting and sort order (newest / rating / helpfulness).
• Filter server-side by star rating (range or an exact set like 1★+5★), keyword(s), app version, or date range — so you're only charged for reviews you actually want, not the whole feed.
• Reviews are de-duplicated by reviewId, so a repeated row from Google Play is never pushed — or charged for — twice.
• Watch mode (watchLabel): run it on a schedule and get only the reviews posted since your last run instead of the same top-of-feed rows every time — a run with nothing new returns nothing and costs nothing. It also catches edits to reviews you already have: a reviewer changing their own star rating, or a developer reply being added or removed (watchEvents).
• Includes per-review aspect ratings (aspectRatings) — the sub-scores Google Play attaches to a written review for specific aspects (e.g. ad frequency, ease of use) when the reviewer filled them in. None of the leading Store competitors expose this field (re-verified against their live output schemas 2026-09-17).

Use cases

• Release QA — filter appVersions to a build you just shipped and maxScore: 2 to see what broke, before the next release.
• Support queue triage — replyFilter: "noReply" surfaces every review still waiting on a developer response; add minThumbsUp to prioritize the ones other users already found helpful.
• Competitive review monitoring — point watchLabel at a rival's package name on a schedule and get alerted only on genuinely new reviews, rating edits and reply changes — not the same top-of-feed rows every run.
• Category-wide research — searchTerms + genres resolves app names to package IDs and filters to a whole category (e.g. ["GAME"]) without knowing any package names up front.
• ASO sentiment digging — aspectRatings breaks a rating down into sub-scores (ads frequency, ease of use, …) the reviewer actually answered, so you can see why a score moved, not just that it did — a field the leading Store competitors don't expose at all.

Input

Field	Type	Description
appIds	array of strings	Google Play package names (e.g. com.spotify.music) or full Play Store URLs (e.g. https://play.google.com/store/apps/details?id=com.spotify.music) — the package name is extracted from the URL's ?id= param
searchTerms	array of strings	Alternative to appIds: search terms; the top match for each is used, or the first genre-matching hit of the top 5 when genres is also set — see FAQ
country	string	Play Store country code (default us)
language	string	Language for reviews/details (default en)
sort	string	NEWEST (default), RATING, or HELPFULNESS
maxReviewsPerApp	integer	Reviews to fetch per app before moving to the next one (default 100, max 5000) — counted before rating/keyword/appVersion/date filtering, see FAQ
includeAppDetails	boolean	Also push one app-details record per app (default true)
genres	array of strings	Only scrape apps in these Google Play genres — every other app is skipped before any review is fetched, so it costs nothing. Takes the genre id (GAME_STRATEGY, EDUCATION), the display name (Strategy, Music & Audio) or GAME for any game genre, case-insensitive. See FAQ
maxResults	integer	Hard cap across all apps and records (default 500)
minScore / maxScore	integer	Only keep reviews with a star rating in this range (1-5)
ratingFilter	array of integers	Only keep reviews whose rating is one of these exact values, e.g. [1, 5] — use it when you want a non-contiguous set that minScore/maxScore can't express. Applied on top of minScore/maxScore (an AND, not an override); a combination that leaves no reachable star rating, like minScore: 4 with ratingFilter: [1, 2], fails immediately instead of running. See FAQ
keyword	string	Only keep reviews whose title or text contains this word/phrase (case-insensitive)
keywords	array of strings	Only keep reviews containing at least one of these words/phrases (case-insensitive)
appVersions	array of strings	Only keep reviews written against one of these app versions, e.g. ["9.1.78.2218"]. Google Play leaves version null on roughly 1 review in 6 — those are dropped when this filter is set
minThumbsUp	integer	Only keep reviews with at least this many "helpful" votes from other users
replyFilter	string	any (default), hasReply (only reviews the developer already responded to), or noReply (only reviews still waiting for a response — the support-queue use case)
minReviewLength	integer	Only keep reviews whose text is at least this many characters — filters out one-word/emoji-only reviews
sinceDate / untilDate	string	Only keep reviews posted within this ISO date range
watchLabel	string	Optional. Name a saved watch (e.g. my-app-alerts) to get only reviews not delivered under that label before — see "Watch mode" below
watchEvents	array	Optional, watch mode only. Which changes to report: new, scoreChanged, developerReplied, replyRemoved. Empty = all four
webhookUrl	string	Optional. An http(s) URL to POST a small JSON completion summary to when the run finishes — see FAQ.

Watch mode — only new reviews since the last run

Set watchLabel to any name and this Actor stops re-delivering the same reviews on every scheduled run:

1. First run for a label is a free baseline. It records which reviews already exist (walking at least 1000 per app, regardless of your maxReviewsPerApp, up to 5000 reviews total) and returns zero rows — you are charged nothing.
2. Every run after that returns only reviews that weren't in the baseline, and adds them to it. Nothing new → zero rows → zero charge.
3. Reviews already in the baseline are re-delivered when they actually change. Google Play keeps a review's id stable when the reviewer edits their own star rating and when you add or delete a developer reply, so an id-only watch would go silent forever on exactly those events. Pick which ones you want with watchEvents (new, scoreChanged, developerReplied, replyRemoved; leave empty for all four). Changed rows carry watchEvent, previousScore and previousHasDeveloperReply so you can see what moved. developerReplied only fires for a reply added after the baseline exists — a review that already has a reply the first time the Actor ever sees it is recorded as hasReply: true with no "before" state to diff against, so it can never generate the event. Measured live: on apps with an active review-reply program this is most of what's visible (Cash App 91%, Robinhood 85%, Coinbase 65% of recent reviews already replied) — on apps that don't reply at all it's moot (WhatsApp, Instagram, Duolingo: 0%).

The baseline lives in your own Apify account, in a named key-value store called fetchsmith-google-play-reviews-watch, keyed by your label plus a fingerprint of the apps/search terms, country, language, sort order and every rating, keyword, app-version, thumbs-up, reply, genre and date filter. Change any of those and you get a fresh baseline rather than a silently wrong one — otherwise widening a filter would hide the newly-matching older reviews as "already seen". Delete the record to start over; use different labels to watch several filter sets in parallel.

Details worth knowing:

• Change events need one run to warm up. A baseline created before watchEvents existed stores review ids but not the star rating/reply state to diff against; the first run after upgrading records that state (and says so in the log), so scoreChanged/developerReplied/replyRemoved start firing from the run after that. New reviews are unaffected.
• A score edit that also added a reply is one row, not two. The change is reported under its primary event (scoreChanged) and charged once; the row's own replyText shows the current reply state.
• Use sort: "NEWEST" (the default). With RATING or HELPFULNESS a brand-new review isn't necessarily inside the first maxReviewsPerApp rows, so new reviews can be missed; the run logs a warning if you do it anyway.
• Never pin a watch to untilDate. A newly-posted review's date is its own post time, so once today's real date passes a fixed untilDate, nothing new can ever fall on or before that cutoff again — the watch goes permanently quiet while still reporting a healthy "nothing new" every run. A run in that state logs two warnings and sets watchDeadDateBound: true in the webhookUrl payload. sinceDate alone is safe to keep in a watched query; it only trims old reviews, it never excludes new ones.
• maxReviewsPerApp is your fetch-depth budget on incremental runs and is left exactly as you set it. If every matching review inside that window turned out to be new, the run warns you (and says so in the status message) that reviews posted before the window may have been missed — raise maxReviewsPerApp or run the watch more often.
• App-details records are only returned on a run where that app actually has a new review, so a quiet run really does cost nothing. On non-watch runs they behave as before.
• If a searchTerms lookup resolves to a different app than last time, that app is baselined on the spot rather than having its entire back catalogue delivered as "new".
• Baseline size cap. The saved record holds at most 20,000 review ids; once a long-running label grows past that, the oldest ids fall off and those reviews would be reported (and charged) as "new" again on a later run. The run now says so explicitly — a WARNING in the log, in the run's status message, and baselineTruncated/baselineTruncatedTotal in the webhookUrl payload and the saved record (truncatedLastRun/truncatedTotal) — so you can narrow the filters or split the apps across labels before it costs you anything.

Output

One item per row, either an app-details record (recordType: "app") or a review (recordType: "review").

Sample review row:

{
  "recordType": "review",
  "appId": "com.spotify.music",
  "reviewId": "24191734-8bd7-4aac-a714-46193c46b4d4",
  "userName": "Nikhil Rathod",
  "reviewerProfileImageUrl": "https://play-lh.googleusercontent.com/a-/...",
  "score": 5,
  "title": null,
  "text": "my motivation",
  "date": "2026-09-08T03:01:35.135Z",
  "language": "en",
  "thumbsUp": 0,
  "version": null,
  "replyText": null,
  "replyDate": null,
  "aspectRatings": [
    { "criteria": "vaf_app_quality_ads_frequency", "rating": 2 }
  ],
  "url": "https://play.google.com/store/apps/details?id=com.spotify.music&reviewId=..."
}

Sample app-details row includes: title, developer, score, ratings, reviewsCount, histogram, installs, price, free, genre, contentRating, released, updated, url.

Pricing

result — $0.0001 per returned item (review or app-details row). The run start is free, and rows dropped by your filters are never charged. That matches the flat rate of the two busiest real-usage rivals, thewolves/google-play-reviews-scraper (1,887 users, re-verified live 2026-10-16) and theagents/googleplay-reviews (667 users), both $0.0001/review with no start fee. Against the niche's biggest competitor by users, neatrat/google-play-store-reviews-scraper (2,873 users), we are cheaper on the lower plans and level on the higher ones: their per-review price is tiered $0.00015 FREE, $0.00013 BRONZE, $0.00011 SILVER, then $0.0001 from GOLD through DIAMOND. Re-verified against all three live listings 2026-10-03.

What we do not claim. We are not the cheapest per-review Actor in this niche, and we are not even close to it — a 15-term Store sweep (261 matching listings, re-checked live 2026-10-06) found ten listings that beat our $0.0001 — the 2026-10-08 full-tail sweep described further down raised that running total to twenty-five, and the 2026-10-09 resweep raises it again to thirty-one, with five more that undercut us above a crossover and one that bills per app rather than per review. Six are described immediately below; the 2026-10-05 sweep added three more, all previously unnamed here, and all invisible to a headline-price comparison because their Store-displayed primary event is an app-level event while the review event they actually bill per review is cheaper than ours: unfenced-group/google-play-store-scraper (3 users but 153 successful runs in the last 30 days) charges a flat $0.00005 per review at every plan tier — half our rate on any run size, with no Actor-start fee (it bills $0.00069 per app row on FREE, so a 1-app/1,000-review run costs about $0.051 there against $0.100 here); maximedupre/google-play-store-scraper (6 users, 344 runs in 30 days) ties our $0.0001 on FREE and BRONZE and then halves it to $0.00005 from SILVER up, so it undercuts us on every paid plan, though it caps at 500 reviews per app against our 5,000; and lergassy/google-play-scraper charges $0.00007 per review on FREE tapering to $0.00005 at GOLD and above. Two further listings were checked and ruled out of scope rather than counted: shahidirfan/Google-Play-Store-Scraper (9 users, 146 runs) carries no pricing record at all — Apify's FREE model, i.e. $0 — but its input schema (url, keyword, category, subcategory, results_wanted, max_pages) has no review parameter of any kind despite a description that advertises reviews, so it is an app-listing scraper and not a review feed; and ivanvs/google-play-scraper (33 users — the largest listing in this niche that no sweep here had ever named) prices reviews at a flat $0.0001, exactly our rate, but adds a $0.001 Actor-start fee that makes every run of any size dearer than ours, and its entire input is three keys (urls, collectApplicationDetails, collectReviews) with no review filters, no search-term resolution and no per-app cap. Three are flat-rate undercutters with no crossover point where we win on price alone: x.com/google-playstore-review-scraper (23 users, re-verified live 2026-10-16) charges a flat $0.00001 per review plus a $0.00005 start fee — about 90% below our rate on any run of a few hundred reviews or more; apihq/google-play-reviews-scraper (66 users, 28 of them in the last 30 days, re-verified 2026-10-18) charges a flat $0.00008 per review with no Actor-start fee, in force since 2026-07-10; delectable_incubator/google-play-store-reviews-scraper-low-cost charges a flat $0.00009/review plus the same $0.00005 start fee. Three more were never named here before this sweep. A tenth, thenetaji/google-play-scraper, was found in this cycle's live-pricing of the remaining 49 unnamed matches (2026-10-06): it bundles four unrelated datasets — full app record, keyword search, developer portfolio, and reviews — behind one scraperType mode picker, all billed through the same result event, tiered $0.00008 FREE down to $0.000056 DIAMOND — cheaper than our flat $0.0001 at every tier, including FREE. Its reviews mode's entire input is maxReviews, sort, language and country — no star-rating, keyword, date-range or reply filter of any kind, and no per-app resolution beyond a package ID — so it undercuts us on price alone, not on scope. magicfingers/appstore-scraper (134 users) carries no pricing record at all — it is on Apify's FREE model, i.e. $0 per review, which no paid Actor can beat on price (it covers both the Apple App Store and Google Play — search, app details, reviews, top charts, developer profiles, 150+ countries), so if price is your only criterion, start there and come back here only if you need the filtering and watch mode below. reviewbot/google-review-scraper (17 users) charges a flat $0.00005 per review with no start fee and bills nothing for the first 10 reviews of each run — half our rate at every run size. The sixth, apilab/google-play-scraper (83 users), is cheaper above a crossover rather than everywhere: it charges a tiered Actor-start fee ($0.005 per GB of run memory on FREE, $0.00367 BRONZE, $0.00233 SILVER, $0.001 GOLD and above) plus a tiered per-row rate ($0.00005 FREE, $0.00004 BRONZE, $0.00002 SILVER, $0.00001 GOLD and above), so we are the cheaper option only on very small runs — past roughly 100 reviews in one run on the FREE plan, or about 11 reviews on GOLD and above, it wins. Choose this Actor over any of theirs for the app-resolution, filtering and watch-mode features described below, not for a lower unit price.

For completeness, every other rival we have priced live costs more than us at typical run sizes, verified live 2026-10-03 — the 2026-10-05 re-sweep live-priced every one of the 49 unnamed matches at 3 or more users, and the 2026-10-08 sweep then closed the remaining gap by live-pricing all 224 unnamed listings including the 1-and-2-user tail (see that paragraph above for the fifteen undercutters it found), so this is no longer limited to "every rival with real usage". A 2026-10-06 re-sweep (niche grown to 261 matches) live-priced the full 49-listing >=3-user cohort again and found exactly one new result — thenetaji above — with every other listing in that cohort tied or dearer than us at every tier (the nearest ties: jdtpnjtp/google-play-reviews-scraper, 9 users, and the review event — not its primary — on freshactors/google-play-scraper, 9 users, both $0.0001 only at their very top tier and dearer below it): curious_coder/google-play-scraper (2,702 users — the niche's second-biggest listing by users, and a Store sweep's first time naming it) charges a flat $0.0003/review with no start fee, 3x our rate; it scrapes app details and developer/category data as well as reviews, but at triple the per-row price. solidcode/google-play-store-reviews-scraper (130 users) $0.0002/review plus a $0.00005 start fee, shahidirfan/Google-Play-Store-Reviews-Scraper (16 users) $0.0002 plus a $0.0005 start fee, benthepythondev/google-play-reviews-scraper (39 users) $0.002 tapering to $0.0014 at DIAMOND, coder_zoro/google-play-app-reviews-scraper (118 users) $0.00499 tapering to $0.00299, easyapi/google-play-reviews-scraper (646 users) $0.00299 per review plus a $0.09 start fee, webdatalabs/google-play-reviews-scraper (173 users) $0.01 tapering to $0.007 plus a $0.004 start fee, and scrapesmith/google-play-store-reviews-scraper (18 users) $0.0001/review (tying our rate) plus a $0.01 start fee that makes every run dearer than ours. One exception with a real crossover: fetchcraftlabs/playstore-reviews-scraper (133 users) charges a $0.05 start fee plus a review rate tiered $0.0001 FREE down to $0.00007 GOLD and above — its flat start fee means it's dearer than us below roughly 1,700 reviews in a single run at its cheapest tier, but cheaper above that, a genuine high-volume undercut we didn't have named before. A second, much sharper crossover found in a 2026-10-04 full-niche sweep (250 matches, 218 of them unnamed here, diffed and live-priced rather than just the top-10-by-users): dami_studio/google-play-reviews-scraper (4 total users, but 97 successful runs in the last 30 days and last modified 2026-10-03 — a real, actively-run listing the low user count alone would hide) matches our scope exactly — package-ID-or-link input, country targeting, star/date filters, up to 5,000 reviews per app — and charges a flat $0.001 Actor-start fee plus a review rate tiered $0.00009 FREE down to $0.000087 DIAMOND. Its start fee makes it dearer than us only below about 100 reviews in a single run; above that, it undercuts us on every plan. A further listing, moving_beacon-owner1/my-actor-1 ("Google Play Store Reviews Scraper Pro", 351 users) at $0.004999/review plus a $0.00005 start fee, carries Apify's own UNDER_MAINTENANCE notice as of 2026-10-03 — dearer than us even if it were reliable, and not recommended as a live alternative while that notice stands. Verified live 2026-10-03.

The same 2026-10-03 sweep priced nine more listings this README had never named, all dearer than us, checked live 2026-10-03: automation-lab/google-play-scraper (1,035 users, re-verified live 2026-10-16 — the niche's fourth-biggest listing by users, and the biggest one no earlier sweep here had ever surfaced) charges a $0.005 Actor-start fee plus a tiered per-review rate of $0.00115 FREE down to $0.00028 DIAMOND, so it is 2.8x–11.5x our rate depending on your plan, and it bills app-detail rows separately at $0.0023 → $0.00056; solidcode/google-play-apps-scraper (295 users, verified live 2026-10-09) $0.0005/row plus a $0.01 start fee; crawlerbros/google-playstore-scraper — named here at 89 users and $0.001 FREE → $0.0005 GOLD and above plus a $0.005 start fee, dearer than us — gone from the Store as of 2026-10-09 (confirmed 404, a removal not a rename); haketa/google-play-scraper (44 users) $0.0025 → $0.0015 plus a $0.00005 start fee; andok/app-store-reviews (37 users) $0.001 FREE → $0.00014 DIAMOND plus a $0.01 → $0.0014 start fee, i.e. above our rate even at its very cheapest tier; focused_vanguard/appstore-reviews-scraper (36 users) $0.00399 → $0.00299; memo23/google-play-scraper (36 users, verified live 2026-10-16) $0.001/row plus a $0.005 start fee; scrapesage/google-play-scraper (28 users, re-verified live 2026-10-16) $0.0008 → $0.0002 per review plus $0.005 per app detail; and sian.agency/play-store-apps-scraper (16 users, verified live 2026-10-05) $0.00015 FREE → $0.0001 PLATINUM/DIAMOND per review plus a $0.005 start fee, which ties our rate at its two top tiers and never beats it. Two more worth knowing about because their names mislead: scrapestorm/google-play-store-reviews-scraper---cheapest (5 users) is titled "Cheapest" but charges $0.00299 per row plus a $0.00005 start fee — about 30x our rate, the dearest flat rate in this list; and scrapebench/reviews-insight-mcp ("App Review Teardown & Insights (AI)", 55 users) is not a per-review scraper at all — it charges $0.05 per AI insight, so comparing it to a per-review price is meaningless. Also in the sweep but out of scope for a per-review comparison: nexgendata/google-play-store-scraper (17 users) at $0.02 per app listing and parseforge/google-play-store-scraper (16 users) at $0.016 → $0.012 per result item, both app-metadata/ASO products rather than review feeds.

A 2026-10-07 resweep (niche grown to 271 matches, 67 unnamed listings at 3+ users, all live-priced individually rather than by title) found two more undercutters, neither named here before: ahmed_jasarevic/google-play-reviews-scraper (3 users, title advertises "$0.08/1K") charges a flat per-review rate tiered $0.00008 FREE, $0.00007 BRONZE, $0.00006 SILVER, $0.00005 GOLD through DIAMOND plus a one-time $0.00005 Actor-start fee — under our $0.0001 at every single tier, Google-Play-only, reviews plus ratings and a sentiment field for ASO use. glitchbound/app-reviews-scraper (1 user) is a dual-store (App Store + Google Play) reviews scraper priced $0.0002 FREE → $0.00016 BRONZE → $0.00013 SILVER → $0.00011 GOLD → $0.000086 PLATINUM → $0.00007 DIAMOND plus a one-time $0.001 start fee — dearer than us on the four lower plans, undercutting only from PLATINUM up, the same "cheaper above a crossover" shape as fetchcraftlabs above. One apparent third candidate, johnvc/google-play-api (9 users), was ruled out on a closer read: its cheapest-looking event is Apify's own generic "Dataset item stored" platform-accounting charge ($0.00001, not primary), stacked on top of its real named review_returned event (tiered $0.0009 FREE down to $0.0006 GOLD+) — several times dearer than us, not an undercutter; the rest of the 67-listing cohort stayed tied or dearer at every tier, same as the two prior sweeps. Verified live 2026-10-07.

A 2026-10-08 resweep closed the long-standing gap this section has flagged since 2026-10-05: every one of the 224 unnamed matching listings was live-priced individually, the 1-and-2-user tail included, not just the 3+-user cohort. The tail is where the cheap listings were. Fifteen previously unnamed listings beat our flat $0.0001 per review at any realistic run size, which is why the "not the cheapest, and not close to it" statement above should be read as strongly as it is written. Six charge no Actor-start fee at all, so they are cheaper than us on a run of any size with no crossover in our favour: scrapersdelight/google-play-reviews-scraper at a flat $0.000045 per review — 55% under our rate, the cheapest honest per-review price found anywhere in this niche, and its own description advertises "no start fee" plus a monitor mode that never bills a review twice; steadyscrape/google-play-reviews-scraper (2 users) and pappy-dev/google-play-reviews (2 users) both at a flat $0.00005 (pappy-dev adds optional $0.05-per-report pain-point/feature-request analysis events you only pay for if you ask for them); realai_pl/google-play-reviews-fast (2 users) and peerless_columbine/google-play-reviews-scraper-api (1 user) both at a flat $0.00008; and cheapapi/app-store-google-play-scraper at $0.00009 per review across both stores. Nine more carry only Apify's default $0.00005 start fee or a $0.0001 one, which pushes the crossover down to between 2 and 5 reviews in a run — below any real use of either Actor, so treat them as undercutters too: cirkit/google-play-reviews-scraper and soilair/google-play-reviews-api at $0.00007 (2 reviews); ninhothedev/google-play-reviews-scraper, automationnation/google-play-reviews-scraper and thenetaji/google-play-reviews-scraper at $0.00008 (3 reviews); cirkit/google-play-store-scraper, whose $0.00008 review event is not its Store-displayed primary ($0.0006 per app record is) and so is invisible to any headline-price comparison (3 reviews); tidydata-labs/app-reviews-scraper at $0.00009 (5 reviews); and zenomastro/google-play-reviews-pro and zenomastro/google-play-reviews-reliable, both $0.00008 per review behind a $0.0001 start fee (5 reviews each).

Three listings from the same 2026-10-08 sweep are cheaper only above a real crossover, and one was ruled out. superslowsloth/google-play-reviews (2 users) charges $0.00007 per review plus a $0.002 start fee, so we are cheaper below about 67 reviews per run and it wins above that; tactful_anvil/google-play-reviews-scraper (2 users) charges $0.00008 behind a $0.01 start fee, giving a much higher crossover of about 500 reviews — the one listing in this group where we are genuinely the cheaper choice for small and medium pulls. second_coming/app-store-review-analyzer (2 users) prices differently again: a single flat $0.02 per scan run with no per-review event at all, so it undercuts us past roughly 200 reviews in one run — though it is a sentiment/issue-detection aggregator over both stores rather than a raw review export, so it is not a like-for-like substitute if you need the review rows themselves. Finally, listless_adzuki/app-store-review-scraper (2 users) is not counted as an undercutter despite showing $0.00001 per row: that is Apify's own generic "Dataset item stored" platform-accounting event, and it sits alongside a named review-result event at $0.004 per review, 40x our rate. This is the same misleading shape the johnvc/google-play-api note above describes, with one difference worth recording: here the generic platform event is the one flagged as the Actor's primary event, so "primary" is not a reliable guide to what a rival actually bills. Verified live 2026-10-08.

A 2026-10-09 resweep (niche at 270 matching listings, 207 of them unnamed here, every one live-priced individually again) found six more undercutters, none named here before, and every one of them hidden by the same reading error: their FREE-tier price ties or beats ours while their real price is on the tiers below it. A tiered rival's FREE-tier rate is not its price — if you are on any paid Apify plan, these six are cheaper than our flat $0.0001 and we are not. Two charge no Actor-start fee at all, so there is no run size at which we are the cheaper choice: deriverge/google-play-reviews-scraper (2 users, 54 runs in the last 30 days) ties us at $0.0001 on FREE and then falls to $0.00008 BRONZE, $0.000065 SILVER and $0.00005 from GOLD up — half our rate on the top three plans — and its scope is a close match for ours (star, date and reply filters, review language and storefront, newest/most-helpful sort); and om_kh/google-play-store-scraper (2 users) follows almost the same ladder, $0.0001 FREE → $0.000085 BRONZE → $0.00007 SILVER → $0.000055 GOLD and above. Four more carry only a one-time $0.00005 Actor-start fee, which puts the crossover at 2 to 5 reviews — below any real run, so treat them as undercutters too: getanyapi/google-play-reviews-scraper (1 user) is dearer than us on FREE at $0.000152 but halves to a flat $0.000076 from BRONZE up (its title advertises "$0.076/1K", i.e. the discounted tier, not the one new accounts land on); chorelet/app-reviews-scraper (1 users, App Store and Google Play in one schema) ties us on FREE then tapers $0.00009 → $0.00008 → $0.00007 GOLD and above; arman-bd/google-play-reviews-scraper (1 user) starts above us at $0.00015 and crosses under at $0.00009 GOLD, $0.00008 PLATINUM, $0.00006 DIAMOND; and lightmoon/google-play-store-reviews-scraper starts at $0.00017 and reaches $0.00009 from GOLD up. That takes the running count of listings in this niche that beat our price to thirty-one. All six verified live 2026-10-09 against their live pricing records, tier by tier.

Five further listings from the same sweep undercut us only above a real crossover, because a per-review rate below ours sits behind per-run or per-app charges that are well above ours. In ascending order of the run size at which they overtake us, all computed against their cheapest tier: ntriqpro/google-play-review-signals (2 users) charges $0.000078 per review from GOLD up behind a $0.00052–$0.001 per-run charge, so it wins past roughly 24 reviews; eiv/play-store-reviews-scraper (2 users) charges $0.00008 SILVER / $0.00006 GOLD and above plus a $0.00005 start fee and $0.002 per app scraped, crossing over at about 50 reviews on GOLD (or 100 on SILVER) for a one-app run; s_actors/google-play-scraper (2 users) charges $0.00008 from GOLD up behind a $0.003 run charge and $0.0008–$0.001 per app-details row, so about 190 reviews; cylindrical_lighthouse/app-reviews-monitor (2 users) charges $0.00008 from GOLD up behind a $0.003 start fee and $0.0015–$0.002 per app checked, about 225 reviews; and northbell/google-play-rating-tracker (1 user) charges $0.00008 from GOLD up but behind a $0.01 run charge and $0.004–$0.005 per app checked, so we stay cheaper until roughly 700 reviews in a single run — the widest margin in our favour in this group. Below those crossovers our flat $0.0001 with no start fee and no per-app charge is the cheaper option; above them it is not. All five verified live 2026-10-09.

One listing from the same sweep prices on a different unit from every other rival here, and it is worth describing on its own because no per-review comparison can express it. alexmorain/app-store-play-store-scraper (1 user, 67 runs in the last 30 days, title "App Store & Google Play Reviews Scraper | $0.01/App, No Cap") bills per app, not per review: a $0.02 one-time Actor-start fee plus $0.01 per app on FREE, tapering to $0.006 from GOLD up, and its own charge-event description states that a single app event covers "its metadata and full review sweep, however many reviews that returns. Reviews are never billed per unit." So its bill for one app is about $0.03 on FREE or $0.026 on GOLD regardless of review count, against our $0.0001 per review — which means we are cheaper only below roughly 300 reviews per app (260 on GOLD), and past that its advantage grows without limit: a 50,000-review app costs about $0.03 there and $5.00 here. Verified live 2026-10-09 against its live pricing record and charge-event descriptions. If your apps have large review counts and you do not need our review-level filters, watch mode or webhooks, it will be far cheaper than this Actor; pick this one for filtered, incremental pulls and for apps with modest review counts.

Also checked and ruled out in the 2026-10-09 sweep, recorded so no later sweep re-counts them: logiover/google-play-data-api (13 users) shows a sub-$0.0001 figure, but that is its Actor-start fee ($0.00005 FREE tapering to $0.000035), not a per-row price — its actual per-result charge is $0.0007–$0.001, seven to ten times ours. This is the start-fee mirror of the johnvc/listless_adzuki trap noted above: the cheapest number on a rival's pricing record is frequently not a per-row number at all. bovi/google-play-scraper (9 users, re-verified 2026-10-18) likewise shows a $0.0000475–$0.00005 start fee beside a real review charge of $0.0056–$0.0059, 56x ours. angaba92/google-play-store-reviews-scraper (3 users) is an exact flat $0.0001 tie at every tier plus a $0.00005 start fee, so it is strictly dearer than us on every run. happyscrapper/app-store-google-play-reviews (2 users) is $0.0003 FREE → $0.00015 GOLD+, dearer at every tier. nexgendata/review-intelligence-mcp-server (6 users) charges $0.05 per tool call — an MCP server for agents, not a per-review export. Three listings carry no pricing record at all and so are free to run, the cheapest possible price, which no paid Actor can beat: darknezz/google-play-reviews-scraper (explicit FREE pricing model), creative_maitake/google-play-review-pain-miner (2 users) and miladamirzadeh/google-play-scraper (2 users). The remaining listings in the 207-strong unnamed cohort were tied or dearer than us at every tier, consistent with the four prior full-cohort sweeps. Verified live 2026-10-09.

On features, rival neatrat takes a single app per run (appIdOrUrl is one string) and offers rating/keyword/version/date filters plus a device-type filter we don't have. This Actor instead accepts many apps per run, resolves apps from searchTerms when you don't know the package names, filters whole apps by genres before fetching a single review, and adds replyFilter, minThumbsUp, minReviewLength, includeAppDetails, stateful watch mode with edit/reply change events, and a completion webhookUrl — none of which exist in their live input schema, checked property by property against their 2026-09-30 build rather than their Store description. Verified live 2026-10-01.

Correction (verified live 2026-10-05): this README previously said code-node-tools was "the one rival that does overlap our review-level filters". That is no longer true, and the full-niche sweep of 2026-10-05 found a closer match than it. unfenced-group/google-play-store-scraper (3 users, 153 runs in the last 30 days) overlaps our review filter set more completely than code-node-tools does, and does it at half our per-review price ($0.00005 flat, see Pricing above). Its input schema carries direct equivalents for essentially every review filter we advertise below — reviewRatings (our ratingFilter), reviewKeywords (keyword), reviewReplyFilter/reviewsWithReplyOnly (replyFilter), minReviewLength, minThumbsUp, reviewAppVersions (appVersion), reviewsSince/reviewsUntil plus a reviewDaysOld rolling window we do not have, and sortReviewsBy — and it also resolves apps without package names (searchTerm, developerId, collection/chartType, categoryId) and filters whole apps before fetching reviews (genres, minScore, minInstalls, contentRatings, adsFilter, iapFilter), which is the same shape as our searchTerms + genres path. So do not choose this Actor over unfenced-group on either price or review-filter coverage. What it has no equivalent for, verified against its live input schema: watch mode and webhookUrl (it is a one-shot run, with no incremental "only new reviews since last run" state), and per-review aspect ratings. It is also app-first by construction — reviews are an opt-in includeReviews add-on to an app crawl, so you pay its app rate on every app you touch, and its maxReviewsPerApp defaults to 100. Pick this Actor for watch mode, webhooks and aspect ratings; pick unfenced-group if you want the cheapest filtered one-shot pull.

A second rival that overlaps our review-level filters is code-node-tools/google-play-reviews-scraper (289 users, 55 in the last 30 days). Its input schema carries minThumbsUp and minReviewLength under those exact names, plus hasReply (our replyFilter), dateFrom/dateTo (our sinceDate/untilDate), minScore/maxScore and keywords, and like us it takes many apps per run — so treat the filter list above as what neatrat lacks, not as unique to us in the niche. What it has no equivalent for: searchTerms app resolution, genres app-level filtering, includeAppDetails, watch mode, webhookUrl, and per-review aspect ratings (its documented output row has no aspect-rating field). It also bills a $0.002 Actor-start fee on every run plus $0.0005 per review on the free plan ($0.0003 at Gold and above), so 1,000 reviews costs about $0.50 there versus $0.10 here. Input schema and pricing verified live 2026-10-01.

FAQ

Can I get reviews in a specific country or language? Yes, set country and language (Play Store returns different review sets per locale — run the Actor for each locale you need). Can I search by app name instead of package ID? Yes, use searchTerms; the top matching app is resolved automatically. Why did I get fewer reviews than the app's total rating count? Google Play's review API only returns a subset of written reviews, not every rating — this is a platform limitation, not a bug. Does keyword/keywords handle accented words correctly? Yes, as of v0.1.20 — both fields and the review text they're matched against are Unicode-normalized before comparing, so an accented word (e.g. "café") matches regardless of which of Unicode's two equivalent representations (composed vs. decomposed) you typed it in. Can I filter to just negative or just recent reviews? Yes — set maxScore (e.g. 2) for negative-only, ratingFilter: [1, 5] for only the extremes, or sinceDate/untilDate for a date window; filtering happens before you're charged, so you never pay for rows you filtered out.

Can I restrict a run to games (or to any one app category)? Yes — set genres. ["GAME"] keeps every game genre (GAME_STRATEGY, GAME_CASUAL, GAME_PUZZLE, …); ["GAME_STRATEGY", "Music & Audio"] mixes an exact genre id with a display name. Verified 2026-09-28: with genres: ["GAME"], com.king.candycrushsaga (GAME_CASUAL) and com.supercell.clashofclans (GAME_STRATEGY) were scraped while com.spotify.music (MUSIC_AND_AUDIO) and com.duolingo (EDUCATION) were skipped with zero reviews fetched and zero charged. It needs one app-details lookup per app, so it works with includeAppDetails off too, and if the genre can't be read the app is skipped rather than scraped unfiltered — you are never billed for rows the filter exists to exclude.

With genres set, does a searchTerms lookup still use just the top hit? No — when genres is set it pulls the top 5 search hits (instead of 1) and keeps the first one whose own genre already matches, falling back to the top hit only if none of the 5 do. Without genres, searchTerms still resolves to the single top hit, same as always. This matters because Play's #1 result for a term is not always the right category: verified 2026-09-28, searchTerms: ["sky"] with genres: ["EDUCATION"] resolved to com.noctuasoftware.stellarium_free (EDUCATION, Play's 4th-ranked hit for "sky") — the unranked #1 hit for "sky" is a role-playing game. Before this fix, a term like that returned zero apps instead of the education one buried a few ranks down.

Can I see what broke in a specific release? Set appVersions to the version string(s) you care about (they match the version field on each review row) and, if you want, combine it with maxScore: 2 and keywords to isolate the complaints. Reviews where Google Play reports no version are excluded rather than guessed at.

Can I find reviews my support team hasn't answered yet, or check response quality on the ones we have? Yes — replyFilter: "noReply" returns only reviews with no developer response (combine with maxScore: 2 for an unanswered-complaints queue); replyFilter: "hasReply" returns only the ones you already responded to, e.g. to audit response quality or turnaround. minThumbsUp and minReviewLength are the same idea applied to helpfulness votes and review length — e.g. minThumbsUp: 5 surfaces the reviews other users found worth upvoting, and minReviewLength: 100 filters out one-word/emoji-only noise. All three were already computed on every review row (thumbsUp, replyText, text) but unfilterable before this — live-verified on a real app (Discord) that 21/50 recent reviews had a developer reply and the other 29 didn't, split exactly by replyFilter.

What is aspectRatings? Google Play sometimes prompts a reviewer to rate specific aspects of the app (e.g. "Ads frequency", "Ease of use") alongside their overall star score. When present, each row's aspectRatings array has one {criteria, rating} entry per aspect the reviewer answered — verified live across 800 reviews on 4 major apps (Spotify, WhatsApp, Duolingo, Candy Crush Saga): 27.3% carried at least one aspect rating, and the taxonomy is category-aware (games get dozens of genre-specific criteria, utility apps get a small generic set). It's [] when the reviewer didn't answer any (most reviews). We're the only Google Play reviews Actor on the Store that surfaces this field — the top 3 competitors by users don't include it in their output schema (re-verified 2026-09-17). One quirk worth knowing: ~2% of criteria entries use a vaf_never_display_* prefix — Google's own internal name implying its UI won't render that category, yet it comes back in the same array as every normal one, with nothing distinguishing the two. See the full write-up for the per-app numbers.

Why did I get fewer reviews than maxReviewsPerApp? maxReviewsPerApp is a fetch cap, not a match count — Google Play returns up to that many reviews (newest-first by default), and rating/keyword/appVersion/date filters are applied after that, per review. A narrow filter combined with a low cap can miss real matches sitting further back in the feed: on WhatsApp (com.whatsapp) with keyword: "crash", maxReviewsPerApp: 20 fetches 20 reviews and keeps 0, but raising it to 200 finds 1 — the match was always there, just never fetched. When this happens the log carries a WARN naming the cap and how many fetched reviews were dropped, and the run's status message says the same — raise maxReviewsPerApp to search deeper. Filtered-out reviews are not charged either way. Why does ratingFilter: [1, 2] return 0 rows even though the app clearly has low ratings? Check sort. RATING sorts highest-first, so the maxReviewsPerApp fetch cap (applied before any filter, see above) can fill up entirely with 5-star reviews and never reach a 1★ or 2★ one — same root cause as the fetch-cap FAQ, just with sort order as the trigger instead of a low cap. Use sort: "NEWEST" (the default) when hunting for specific low ratings — raising maxReviewsPerApp will not rescue a RATING-sorted run on a popular app. Verified 2026-09-25 on Spotify (com.spotify.music): with sort: "RATING", maxReviewsPerApp: 5000 (the maximum) fetched all 5000 and kept 0 for both ratingFilter: [1, 2] and ratingFilter: [4] — every one of the 5000 was a 5★ review, so no allowed cap value can reach lower stars. The run now warns about this combination up front, before spending the fetch budget.

Can I use ratingFilter and minScore/maxScore together? Yes, but they are ANDed, not overridden — a review must satisfy both. That means some combinations can never match anything: minScore: 4 with ratingFilter: [1, 2] asks for reviews that are simultaneously ≥4★ and exactly 1★ or 2★, and Google Play reviews only carry whole stars 1-5. Such a run now fails immediately with an explanation instead of silently returning 0 reviews. That mattered because the old behaviour was actively misleading: verified 2026-09-30 on Spotify (com.spotify.music), minScore: 4 + ratingFilter: [1, 2] fetched all 60 requested reviews, dropped all 60, and closed with "raise maxReviewsPerApp to search further" — advice that cannot work at any depth, because the contradiction is in the input, not in the feed. The same check catches a ratingFilter containing only values outside 1-5 (e.g. [6] or [4.5]), which the input editor accepts. Partial overlaps are left alone and still work normally: minScore: 2, maxScore: 4 with ratingFilter: [1, 3] legitimately means "3★ only".

How do I get alerted about new reviews instead of re-downloading the same ones? Set watchLabel and schedule the Actor (Apify Console → Schedules). The first run is a free baseline that returns nothing; every later run returns only the reviews posted since the previous run, so a scheduled hourly watch on a quiet app costs nothing at all. See "Watch mode" above for how the baseline is keyed and what to watch out for.

My watch says "nothing new" every single run — is it broken? Check whether you set untilDate. A watch combined with a fixed upper date bound is a dead end: every brand-new review is dated "now" (with the default sort: "NEWEST"), so once the calendar passes your cutoff no new review can ever satisfy it again, and the run honestly reports zero new rows forever. Such a run now logs two warnings and sets watchDeadDateBound: true in the webhookUrl payload so a scheduled watch can alert on it instead of trusting the quiet. Fix it by removing untilDate from the watched query — keep sinceDate if you want a floor — or drop watchLabel if you genuinely wanted a one-off historical window rather than an ongoing watch. (Changing the filter starts a fresh free baseline, since untilDate is part of the watch fingerprint.)

Can I be alerted when someone edits a review I already downloaded? Yes — that is what watchEvents is for. Google Play lets a reviewer rewrite their own review (same review id, new star rating) and lets a developer add or delete a reply at any time, and a watch keyed only on review ids can never see either. With a watchLabel set, this Actor also diffs the star rating and reply state each review had when it was last delivered, and re-delivers it as watchEvent: "scoreChanged", "developerReplied" or "replyRemoved" with previousScore/previousHasDeveloperReply filled in. Restrict it to the events you care about (e.g. ["scoreChanged"] to track only rating downgrades) so you never pay for the rest. A baseline created before this existed needs one run to record the state it will diff against.

How is webhookUrl different from Apify's own platform webhooks? Apify's platform webhooks are configured separately per Task/Actor via the Console or the Webhooks API — useful if you already live in the Apify Console, but extra setup if you're calling this Actor's API directly and just want a completion ping. webhookUrl is a plain input field: set it on the run itself and it POSTs a JSON body (actorRunId, defaultDatasetId, finishedAt, pushed, and — if watchLabel is set — watchSeeding/watchNewCount/watchSkipped/baselineTruncated/baselineTruncatedTotal/watchDeadDateBound) once the run finishes and every review has already been pushed and charged. It's best-effort — a slow or failing webhook only logs a warning, it never fails the run, changes the result set, or affects billing.

Related guides

Engineering write-ups behind this Actor:

• Google Play has no public reviews API — but the store's own JSON endpoint does
• Google Play's review API carries two fields almost nobody reads — a full star histogram and a hidden per-review "aspect" breakdown
• HTTP-only vs headless browser scraping: a timed benchmark
• Four ways an invisible character makes a scraper return zero rows
• We nearly charged our own buyers twice for rows they'd already paid for — a capped watch-mode baseline can silently evict old-but-current ids on a high-volume run, re-delivering (and re-billing) rows already paid for. This is the Actor the bug was first found and reproduced on.
• App Store, Google Play and Steam reviews — three JSON APIs, three unrelated meanings of "empty" — how this Actor's specific silent-empty failure mode compares to the other two review platforms we scrape.
• Eight ways an "only new since last run" watch mode silently stops working — the fleet-wide survey of watch-mode failure shapes across all nineteen incremental Actors, this one included.
• Google Play's "developer replied" watch event only fires for replies added after you start watching — measured live across 8 popular apps how much of each one's review pool already carries a reply before any watch could ever see it.

Notes

Only public Google Play data is collected. Issues or feature requests: support@fetchsmith.com. Also available as a hosted API at https://fetchsmith.com/tools/google-play-reviews-scraper

Source code: https://github.com/Fetchsmith/fetchsmith/tree/main/actors/google-play-reviews-scraper