Google Play Reviews Scraper & App Search API

Pull Google Play app reviews and search the Play Store at speed, with clean, LLM-ready JSON. Built for AI agents, review-monitoring pipelines, and product teams who need real user feedback in a structured shape.

Two things make this one different: it runs in Standby mode, so an agent can call a live HTTP endpoint mid-task with no cold start, and every field is flat and predictable, so you can feed the output straight into an LLM, a sentiment model, or a database without a cleanup step.

What you get

• Reviews by app: rating, review text, app version, thumbs-up count, timestamp, the developer's reply, and a permalink.
• App search: find the Android package name for any app, plus developer, rating, price, currency, and icon.
• Full pagination: ask for 5,000 reviews and it pages through Google for you.
• Any storefront and language: country and lang control which reviews you see.
• Standby HTTP API: a persistent endpoint your agent or app can hit directly.
• MCP ready: exposed as a typed tool through Apify's MCP server via the input schema.
• Maintained upstream: built on the community google-play-scraper library, so Google's internal RPC changes are handled by a shared, actively maintained project instead of one private scraper.
• No dead columns: every field in the output is a field Google actually serves. Nothing is advertised that always comes back empty.

Use cases

• Monitor what users say after each release, and catch a crash wave in the reviews before support tickets arrive.
• Feed competitor reviews into an LLM for feature-gap and pain-point analysis.
• Read how a developer answers complaints, at scale, from the replyText field.
• Build a sentiment dashboard for your app and three rivals.
• Give an AI agent a live tool that answers "what are people complaining about in this app right now".
• Collect training or RAG data from real, public product feedback.

Modes

Mode	You give it	You get back
search	query (app name or keyword)	matching apps with their Android package names
reviews	appIds (package names)	reviews, paginated up to maxItems

Start with search to get a package name, then run reviews on it. reviews and search are the only two accepted modes, lowercase and exact.

Input

Find an app:

{
  "mode": "search",
  "query": "notion",
  "country": "us",
  "maxItems": 5
}

Pull its reviews:

{
  "mode": "reviews",
  "appIds": ["com.adobe.scan.android"],
  "country": "us",
  "lang": "en",
  "maxItems": 100,
  "sort": "newest"
}

Compare three apps in one run. maxItems is the budget for the whole run and is split evenly, so this returns 30 reviews of each, not 90 of the first one:

{
  "mode": "reviews",
  "appIds": ["net.booksy.business", "com.fresha.Business", "com.squareup.apos"],
  "country": "us",
  "maxItems": 90
}

Field	Type	Default	Notes
mode	reviews or search	reviews	required. Any other value is rejected before anything is fetched.
appIds	array of strings		Android package names, for example com.whatsapp. Required when mode is reviews. Ignored in search.
query	string		app name or keyword. Required when mode is search. Ignored in reviews.
country	2-letter code	us	Play Store storefront
lang	2-letter code	en	review language
maxItems	integer 1 to 5000	100	budget for the whole run, split evenly across appIds. 100 across 3 apps is 34 / 33 / 33.
maxItemsPerApp	integer 1 to 5000		optional. When set, every app gets exactly this many and the even split is ignored, so 3 apps at 50 return up to 150 rows.
sort	newest, rating, helpfulness	newest	review order, reviews mode only

A run that asks for reviews without appIds, or search without query, fails immediately with a clear input error and returns nothing, so a misconfigured run costs you nothing.

Output

Real output from runs on 5 September 2026. Larger samples of both are in the examples/ folder of the source.

App search:

{
  "type": "app",
  "appId": "notion.id",
  "name": "Notion: Notes, Tasks, AI",
  "developer": "Notion Labs, Inc.",
  "rating": 4.5757923,
  "price": 0,
  "currency": "USD",
  "free": true,
  "url": "https://play.google.com/store/apps/details?id=notion.id",
  "icon": "https://play-lh.googleusercontent.com/-GY1Xv9hhhK_RFJCCb-rvDX8OMR8Fj68AgcRIFcD8zIXlOA8pG-L-cuOJbgSs_U6GGGyGs8qiiQsjIfEBazE8g"
}

A review with a developer reply:

{
  "type": "review",
  "appId": "com.adobe.scan.android",
  "country": "us",
  "lang": "en",
  "reviewId": "0d06d6ed-fb52-40aa-bcca-a06628e648ab",
  "author": "Rachel Ganiyu",
  "rating": 5,
  "text": "love it",
  "version": "26.04.30",
  "thumbsUp": 0,
  "date": "2026-09-03T20:28:17.542Z",
  "replyText": "Hi there! Thank you for your kind words! We truly appreciate your support...",
  "replyDate": "2026-09-04T03:54:18.598Z",
  "url": "https://play.google.com/store/apps/details?id=com.adobe.scan.android&reviewId=0d06d6ed-fb52-40aa-bcca-a06628e648ab"
}

A review with no reply looks the same with replyText and replyDate set to null. (Reply text above is shortened for the example; the API returns it in full.)

Use it from an agent (Standby)

Standby keeps the Actor warm and answers over plain HTTP, so there is no per-call container start.

GET {standbyUrl}/search?query=notion&country=us&maxItems=5
GET {standbyUrl}/reviews?appId=com.adobe.scan.android&country=us&lang=en&maxItems=50&sort=newest

Every successful response is:

{
  "ok": true,
  "count": 30,
  "perApp": [
    { "appId": "net.booksy.business", "requested": 10, "fetched": 10, "charged": 10, "error": null },
    { "appId": "com.fresha.Business", "requested": 10, "fetched": 10, "charged": 10, "error": null },
    { "appId": "com.squareup.apos", "requested": 10, "fetched": 10, "charged": 10, "error": null }
  ],
  "items": [ ... ],
  "tookMs": 589
}

That is a real response to /reviews?appIds=net.booksy.business,com.fresha.Business,com.squareup.apos&maxItems=30, recorded 6 September 2026.

perApp is the run's own accounting: what each app was allotted, what it returned, and what it was billed. An app id that cannot be read gets an error string and charged: 0 while the rest of the call keeps its full budget, so one bad id does not fail the request.

GET {standbyUrl}/ returns a small service document with the modes and the running build number.

appId (singular) is accepted as a convenience alongside a comma-separated appIds.

Errors are typed, so an agent knows whether to retry

Status	When	Body
404	the path is not /reviews or /search, for example /foobar, /REVIEWS, /v1/reviews	{ "ok": false, "error": "...", "statusCode": 404, "modes": ["reviews","search"] }
400	the path is valid but the parameters are not, for example /reviews with no appId	same shape, statusCode: 400
500	an upstream failure	same shape

404 and 400 mean "fix the call", not "try again". Neither fetches any data, so neither returns anything billable.

Good to know

• There is no review title field. Google Play stopped serving review titles. Measured across 1,200 reviews from 8 apps on 5 September 2026: zero had one. Rather than ship a column that is always empty, the field is not in the output at all. Use text.
• replyText and replyDate are real, and common on apps whose developers answer. Same measurement: 111 of 150 on Adobe Scan, 30 of 150 on Grammarly Keyboard, 11 of 150 on Canva, 7 of 150 on Trello, and 0 on Duolingo, Uber, and Shazam, which simply do not reply. They are null when that particular review has no reply.
• version is present on most reviews but not all, because reviewers on older clients do not always report one.
• maxItems is split evenly across appIds. Three apps at maxItems: 90 return 30 each, and an app that runs out early leaves its remainder unspent rather than handing it to the next app, so no app can spend another app's budget. Set maxItemsPerApp when you want a fixed number each regardless of how many apps you list. (Until 6 September 2026 the first app in the list took the whole budget and the rest returned nothing. That is fixed.)
• Per-app accounting is in the run. Every batch run writes a summary to the key-value store as OUTPUT, including a mode: search run where the per-app list is empty, and logs one [app] <id> requested=N fetched=N charged=N line per app. Standby answers over HTTP and does not write to the key-value store: it returns the same breakdown as perApp in the response body instead.
• Reviews are public data published by users on the Google Play Store. Respect Google's terms and any applicable privacy law in how you store and use it.

Parity with the App Store Actor

There is a sibling Actor, App Store Reviews Scraper & App Search API, with the same two modes, the same Standby routes, the same error shapes and the same pay-per-event model. Input is the same except for two fields, and the review record maps field for field with five differences. Every difference below is a difference in what the two stores publish, not a difference in style.

Input:

Field	Google Play	App Store
mode, appIds, appId, query, country, maxItems, maxItemsPerApp	same	same
review order	sort: newest, rating, helpfulness	sortBy: mostRecent, mostHelpful
review language	lang	not accepted, Apple serves per storefront only

Review output:

What it means	Google Play	App Store
record kind	type	type
app identifier	appId (package name, com.whatsapp)	appId (numeric, 310633997)
storefront	country	country
review id	reviewId	reviewId
author display name	author	author
stars, 1 to 5	rating	rating
review body	text	text
app version	version	version
permalink	url	url
when it was posted	date	updatedAt
review language	lang	not served
helpfulness	thumbsUp	votesHelpful and votesTotal
headline	not served	title
developer reply	replyText, replyDate	not served

The five differences, each measured rather than assumed:

1. Timestamp name. Apple's customer-reviews feed names its only time field updated, so the App Store Actor exposes updatedAt. Google Play carries a review date, exposed as date.
2. Language. A live Apple feed entry carries exactly these keys: author, content, id, im:contentType, im:rating, im:version, im:voteCount, im:voteSum, link, title, updated (read 6 September 2026, storefront us, app 324684580, 50 entries). There is no language key, so there is nothing to expose.
3. Helpfulness. Google Play gives one number, thumbsUp. Apple gives two, a sum and a count, exposed as votesHelpful and votesTotal.
4. Headline. Apple serves a review title. Google Play no longer does: zero of 1,200 reviews across 8 apps carried one on 5 September 2026, so the field is not in the Google Play output at all.
5. Developer reply. Google Play serves it and it is common (111 of 150 reviews on Adobe Scan, same 5 September sample). Apple's feed has no reply key at all (see the key list in point 2), so the App Store Actor has no replyText or replyDate.

One behavioural difference worth knowing when you compare depth: Google Play pages with a continuation token until it runs out, while Apple serves up to 10 fixed pages and an individual page can come back empty while later pages are full. Those empty pages belong to the exact page URL and they refill within minutes, so the App Store Actor reads every one of the 10 pages until your budget is full instead of treating a run of empty pages as the end. A deep App Store pull can still come back shorter than the app's real review count, when Apple is serving those pages empty for the whole run.

Pricing

You pay for results, not for time. There is no start fee, and nothing is charged for a run that returns nothing.

• review: one review row returned, in batch mode or through Standby.
• app: one app record returned by a search.

A 1,000-review pull is charged as 1,000 review events. Finding an app costs a handful of app events. Current rates are on the Pricing tab of this page.

FAQ

How do I find an app's package name? Run mode: "search" with the app name. The appId in the output is the package name, for example com.whatsapp.

Can I get every review an app ever received? Google serves a deep but not unlimited window per storefront and sort order. sort: "newest" with a high maxItems gets you the most recent history; switching country surfaces a different set of reviews.

Does it need a proxy? No. It talks to Google's public endpoints through a maintained library.

Can I run it on a schedule? Yes. Use Apify's scheduler, or call the Standby endpoint from your own job.

Do you support the Apple App Store too? Not in this Actor. There is a separate App Store Reviews Actor in the same series.

---

Built by Omar Nagy. Part of an agent-native data-tool series on Apify.