Google Play App Lookup: Google Play Store Scraper (Details + Reviews)

Paste a list of Android package names and get each app's live Google Play listing — name, developer, category, rating, rating count, price, content rating and icon — read straight from the store page's own schema.org structured data, or switch to reviews mode and get real customer reviews from the same page. No API key, no Play Console access, and no rendering.

Who it's for

Built for anyone tracking Android apps without an ASO platform subscription. App developers and product teams use it to watch a competitor's rating trajectory, check whether their own listing looks right after a store update, or catch a review-bombing spike early by pulling reviews on a schedule instead of checking manually. Market researchers run a category's worth of package names to map developers, pricing and content ratings, or pull recent reviews for a sentiment pass, without opening each listing by hand. It's also the fast path for verifying an app is still published before referencing it in a report, a comparison table, or a partnership deck — one row tells you live or gone.

Why this one

• Reads Google's own listing data, not a scrape. Details mode parses the schema.org SoftwareApplication block Google embeds for search engines; reviews mode reads the same page's own server-rendered review list. No headless browser, no CSS selectors to break.
• You don't pay for apps that aren't there. A removed, unpublished or region-locked package comes back found: false and is never billed.
• Two modes, one actor. details gives you the app profile; reviews gives you real customer reviews, billed separately and only for reviews actually returned.
• One row per package or per review, ready for a table. No nested arrays to flatten — data arrives flat and stably named.
• Bare package names, no URL wrangling. Pass com.spotify.music and the store URL is built for you.
• Built for bulk. Feed in thousands of packages; maxConcurrency controls how hard it goes.

What you get

The shape depends on mode. Field names are stable within each mode and won't be renamed between runs.

Details mode fields (default)

One row per input package.

Field	Type / format	Description
query	text	The package name exactly as submitted.
found	boolean	Whether the package resolved to a live Play listing. Gates billing — false rows are never charged.
status	text	OK, NOT_FOUND (no live listing), or BAD_FORMAT.
packageId	text	The Android package name, e.g. com.spotify.music.
name	text	App title as shown on the listing.
description	text	Full store description.
developer	text	Developer or publisher name.
developerUrl	link	Developer's Play Store page.
category	text	Play's application category, e.g. Music & Audio.
contentRating	text	Content rating, e.g. Everyone, Teen.
operatingSystem	text	OS requirement string as Google publishes it.
ratingValue	number	Average star rating, 1–5. null on apps with too few ratings.
ratingCount	number	Number of ratings behind ratingValue.
price	text	Listed price. 0 for free apps.
priceCurrency	text	ISO currency code for price.
icon	link	App icon image URL.
scrapedAt	date (ISO 8601)	When the lookup ran.

Reviews mode fields

One row per review, up to maxReviews per app.

Field	Type / format	Description
packageId	text	The app the review belongs to.
reviewId	text	Google's own id for the review.
rating	number	Star rating the reviewer gave, 1–5.
body	text	Review text. Google Play reviews have no separate title field, unlike Apple's.
author	text	Reviewer's display name.
version	text	App version the review was written against.
updatedAt	date (ISO 8601)	When the review was posted or last edited.
thumbsUpCount	number	How many people marked the review helpful.
isNew	boolean	With monitoring on, true if no earlier run of this watchlist saw the review; null otherwise.
firstSeenAt	date (ISO 8601)	With monitoring on, the run that first returned the review; null otherwise.

Details mode vs reviews mode

The two modes bill differently and answer different questions, so picking the right one matters before you run a big list.

details (the default) answers "what is this app" — one row per package, billed once per app that resolves, regardless of how much metadata comes back with it. Use it for catalog enrichment, competitor tracking on rating and price, or confirming an app is still live.

reviews answers "what are people saying" — one row per review, billed per review actually returned rather than per app. An app with 3 reviews costs 3 review events; an app with maxReviews set to 20 but only 8 real reviews available costs 8, not 20. Reviews come from the same store listing page as details mode, so there's no separate storefront/locale knob — but there's also no combined mode: a run is either details or reviews, so pulling both for the same app list means two runs. There's also a hard ceiling of 20 reviews per app: Google serves that many "most relevant" reviews server-rendered on the plain listing page, with no further pagination available without a signed-in session — so maxReviews caps at 20, not a bigger number picked to look generous.

Where the data comes from

Details mode reads a hidden schema.org SoftwareApplication block every Play listing carries, meant for search engines rather than people — it's how Google gets an app's rating stars to show up directly in search results. Reviews mode reads a second, separate block on the exact same page: Google's own internal hydration data (AF_initDataCallback), which happens to already carry ~20 server-rendered reviews even though nothing in the visible page requires you to click "see all reviews" to get them. Neither mode renders the page or executes JavaScript — both are plain HTML parses.

The trade-off is real: Google puts a deliberately small set of fields in the structured-data block, and reviews mode's review count is capped at whatever the page ships without a signed-in, paginated session. Install counts, in-app purchase tiers and screenshots aren't in either block, and stay out of scope here. If you need those, you want a different tool — one built to parse the fully rendered page, accepting the maintenance cost that comes with it. This actor trades that coverage for something else: data that keeps working after a redesign, because both blocks it reads are ones Google has its own incentive to keep populated.

Price

• Successful lookup: $4 per 1,000 results
• Review returned: $1.5 per 1,000 results

Plus a $0.00005 start fee per run. Each event above is billed independently, only when it actually returns data — misses (found:false) are never charged.

In details mode you're billed once per package that resolves. In reviews mode you're billed per review actually returned, so an app with three reviews costs three review events, not maxReviews. A removed, unpublished or region-locked package costs nothing in either mode. Run 1,000 package lookups and, at the live FREE-tier price, that's roughly $4 if every one resolves; 1,000 reviews on top of that adds about $1.50. No subscription runs in the background between lookups.

How to use

1. In the Apify Console. Open the actor page and click Start — the items field is already pre-filled with a working example. Results land in the run's dataset as soon as each item is found.
2. Via the API. Call it directly with a POST request — no Console needed once you have an API token:

   curl "https://api.apify.com/v2/acts/accountable_eel~google-play-app-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>" \
     -X POST \
     -H "Content-Type: application/json" \
     -d '{"items":["com.whatsapp"]}'
   

3. On a schedule. Save this actor as an Apify Task with the input you want, then add a Schedule (hourly, daily, weekly) so it runs on its own — no server of your own required.

1. Paste your package names into items — one per line, bare package ids.
2. Choose mode: leave it on details for app profiles, or set reviews for customer reviews.
3. In reviews mode, set maxReviews for how many to pull per app (up to 20 — see below).
4. Read the dataset. Each row carries the app profile or a review, or found: false if the package has no live listing. Misses are never charged.

Common ways teams use this:

• Track a competitor's rating and rating count over time by re-running on a schedule and diffing the rows.
• Pull recent reviews for a sentiment pass without building a Play Store scraper.
• Enrich an app catalogue with developer, category and content rating for a market map.
• Check whether an app is still published before referencing it in a report or directory.
• Compare pricing across a category by running a package list and reading price and priceCurrency.
• Feed an ASO or market-research pipeline with clean, flat listing or review data.

Input

{
  "items": ["com.spotify.music", "com.whatsapp"],
  "mode": "details",
  "maxReviews": 20,
  "maxConcurrency": 5,
  "proxyConfiguration": { "useApifyProxy": true }
}

items is your list of Android package names — the string after ?id= in a Play Store URL, so https://play.google.com/store/apps/details?id=com.spotify.music becomes com.spotify.music. mode is details (default) or reviews. maxReviews caps how many reviews come back per app in reviews mode (default and maximum 20 — see "Details mode vs reviews mode" for why there's no higher cap). One dataset row comes back per item (or per review in reviews mode), and rows with found: false are never charged. maxConcurrency (default 5) caps parallel requests; keep it conservative, since this target has no browser fallback and hammering it risks being blocked. proxyConfiguration routes requests through Apify Proxy, which is the default and is generally what you want for bulk runs.

Sample output

query	found	status	packageId	name	developer	category	contentRating	ratingValue	ratingCount	price	priceCurrency	scrapedAt
com.spotify.music	true	OK	com.spotify.music	Spotify: Music and Podcasts	Spotify AB	Music & Audio	Teen	4.3	32145678	0	USD	2026-08-23T21:04:47.132Z

A single row in full:

{
  "query": "com.spotify.music",
  "found": true,
  "status": "OK",
  "packageId": "com.spotify.music",
  "name": "Spotify: Music and Podcasts",
  "developer": "Spotify AB",
  "developerUrl": "https://play.google.com/store/apps/dev?id=...",
  "category": "Music & Audio",
  "contentRating": "Teen",
  "operatingSystem": "Android",
  "ratingValue": 4.3,
  "ratingCount": 32145678,
  "price": "0",
  "priceCurrency": "USD",
  "icon": "https://play-lh.googleusercontent.com/...",
  "scrapedAt": "2026-08-23T21:04:47.132Z"
}

Reviews mode, one row per review:

{
  "query": "com.whatsapp",
  "found": true,
  "packageId": "com.whatsapp",
  "reviewId": "da1c2d72-5619-42d6-b0ee-a7501e8eafb1",
  "rating": 3,
  "body": "Works great on both Android and PC, however I do wish that there was a way to disable/remove the \"Archive\" button...",
  "author": "Mike Fanning",
  "version": "2.26.31.77",
  "updatedAt": "2026-08-17T16:29:33.000Z",
  "thumbsUpCount": 16,
  "scrapedAt": "2026-09-08T01:03:47.000Z"
}

A package with no live listing still returns a row, and is never charged:

{
  "query": "com.example.removed",
  "found": false,
  "status": "NOT_FOUND",
  "scrapedAt": "2026-08-23T21:04:47.132Z"
}

Failed packages stay in the dataset rather than vanishing — useful when you're auditing which of a hundred package names were typed wrong versus genuinely delisted.

Monitoring: only new reviews

Pick Reviews mode, turn on Only return reviews that are new since the last run, and this actor becomes a review alert for your app or a competitor's. Every review is checked against the review IDs your previous run already delivered, and anything you have seen is dropped before you are billed. An app with nothing new returns one uncharged row with status: "NO_NEW_ROWS", so a quiet day costs only the run fee.

Google Play shows about 20 reviews per app, in its "most relevant" order. Monitoring catches new reviews that rank into that list, not every review ever posted, so check updatedAt on each row.

The first run has nothing to compare against, so it returns up to your cap and remembers the whole list.

To turn that into an alert:

1. Save your app list as a task in Reviews mode with the checkbox on.
2. Add a Schedule to that task, daily.
3. Add a webhook on Run succeeded, pointing at Slack, n8n, Make or Zapier.

Memory lives in a named key-value store, google-play-app-lookup-delta, one record per app.

Use it from Clay, n8n, Make, or an AI agent

This actor runs synchronously over plain HTTP — call it directly from a script, a workflow tool, or an AI agent, no Apify Console needed once you have an API token.

curl "https://api.apify.com/v2/acts/accountable_eel~google-play-app-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>" \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"items":["com.whatsapp"]}'

n8n. Add an HTTP Request node: Method POST, URL https://api.apify.com/v2/acts/accountable_eel~google-play-app-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>, Body Content Type JSON, JSON Body {"items":["com.whatsapp"]} (swap in an expression from an earlier node for a real value).

Clay. Add an "HTTP API" column: Method POST, URL https://api.apify.com/v2/acts/accountable_eel~google-play-app-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>, Body {"items":["{{value}}"]}, mapping the row's value into the items array.

MCP. In Claude, Cursor, or any MCP client with the Apify MCP server, ask for "Google Play App Lookup | Apify" — the agent will find and run this actor.

Tips

• Use the package name, not the app title. com.spotify.music resolves; "Spotify" doesn't. It's the string after ?id= in any Play Store URL.
• Expect ratingValue to be null on new or niche apps. Google withholds the average until an app has enough ratings — treat null as "not enough data", not as zero.
• Region-locked apps look like misses. A package live only in some markets may return found: false from Apify's egress region. That row is free, but it isn't proof the app is gone.
• Keep maxConcurrency conservative on big lists. There's no browser fallback here, so being rate-limited costs you a rerun rather than degrading gracefully.
• Re-run on a schedule and diff ratingValue and ratingCount to watch a competitor's trajectory rather than just its current state.
• Reviews mode bills per review returned, so maxReviews is a budget dial, not a promise — set it to 5 for a quick sentiment sample instead of 20 if you're running a long app list.
• Google Play reviews have no title field. Unlike Apple's, body is the whole review; don't expect a separate headline column.

vs. alternatives

	What it costs	What you get	Trade-off
This actor (google-play-app-lookup)	$4 per 1,000 resolved packages, $1.50 per 1,000 reviews, $0.00005 actor start, nothing for a package with no live listing	A flat app profile or up to 20 real reviews per package, from Google's own listing page	Reviews are capped at the page's own 20 "most relevant" reviews — no deeper pagination. No install counts or in-app purchase tiers.
curious_coder/google-play-scraper (2,525 users)	$0.0003 per result	Much cheaper per row, and it searches and crawls rather than only resolving known packages	Roughly a thirteenth of the price per row. If cost per row is your binding constraint and you don't need the never-charged-for-a-miss guarantee, that's the cheaper tool.
neatrat/google-play-store-reviews-scraper (273 users, 4.95 rating)	$0.15 per 1,000 reviews	A reviews-focused actor with deeper pagination and sort options	Cheaper and deeper on reviews alone; if reviews at volume are the whole job, benchmark against this dedicated actor. This actor's edge is combined details+reviews in one actor with no separate reviews-only tool to manage.
Doing it yourself	Your time + parsing the structured-data block and the review hydration payload, handling region locks, retries and rate limits	The same data	This actor absorbs the parsing, the retries and the concurrency ceiling and hands you a flat table.

(Competitor prices above are their August 2026 FREE-tier list prices — check their own pages before deciding on cost alone.)

FAQ

Do I need a Google Play API key or Play Console access? No. This reads the public store listing's own structured data, the same block Google publishes for search engines. No credentials are involved.

What counts as "found"? The listing page must return a schema.org SoftwareApplication block. A removed, unpublished or region-locked package returns found: false and is never charged.

Why is ratingValue empty on an app that clearly has stars? Google only publishes an aggregate rating once an app has enough of them, and only in the structured-data block on some listings. A sparse listing yields null rather than a guess.

Can I get install counts or in-app purchase prices? No. Neither is in the structured-data block this actor reads. Pulling them would mean parsing rendered HTML, which is exactly the fragility this design avoids.

Can I get reviews? Yes — set mode to reviews. You get up to 20 real customer reviews per app, most relevant first, billed per review actually returned rather than per app.

Why is reviews mode capped at 20 per app? That's how many reviews Google serves server-rendered on the plain listing page. Pulling more would mean a signed-in, paginated session — a different, heavier target than the public page this actor reads. If you need deeper review history, a dedicated reviews-focused actor is worth benchmarking (see "vs. alternatives").

Does it work for apps only live in some countries? Partly. The lookup runs from Apify's egress region, so a package restricted to other markets may come back as a miss. That row is free, but don't read it as proof the app was removed.

Can an AI agent run this on its own? Yes. It's registered with the Apify MCP server, so a Claude or Cursor agent with that MCP connected can find "Google Play App Lookup" and pull dataset rows back without any integration code being written.

Related actors

• Apple App Store Lookup — the same details-plus-reviews lookup for iOS apps.
• Shopify Store Lookup — live product catalogues for merchants running their own storefront.
• Tech Stack Lookup — platform and tooling detection for the developer's website rather than their app.