Google Play App Lookup — App Store Data API

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. No API key, no Play Console access, and no HTML selectors that break when Google reskins the page.

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 or check whether their own listing looks right after a store update. Market researchers run a category's worth of package names to map developers, pricing and content ratings 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 structured data. Every Play listing embeds a schema.org SoftwareApplication block for search engines. That's what this parses — not CSS selectors.
• 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.
• One row per package, ready for a table. No nested arrays to flatten — the app profile 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

One row per input package, with field names frozen between runs — a schema an agent or a Clay column maps once keeps working.

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.

Where the data comes from

Every Play Store listing carries a hidden schema.org SoftwareApplication block, meant for search engines rather than people — it's how Google gets an app's rating stars to show up directly in search results. That block is the only thing this actor reads. No rendered page is scraped, so there's no CSS selector waiting to break the next time Google changes the listing layout.

The trade-off is real: Google puts a deliberately small set of fields in that block. Install counts, in-app purchase tiers, screenshots and individual reviews all live in the rendered page instead, and none of them are in scope here. If you need those, you want a different tool — one built to parse the live page rather than its structured-data summary, accepting the maintenance cost that comes with it. This actor trades that coverage for something else: listing metadata that keeps working after a redesign, because the block it reads is the one thing Google has an incentive to keep stable for its own search results.

Price

$4 per 1,000 results, plus a $0.005 start fee. Misses (found:false) are never charged.

You're billed per package that resolves to a live listing. A removed, unpublished or region-locked package costs nothing, no matter how many are in the list. Run 1,000 packages and, at the live FREE-tier price, that's roughly $4 if every one resolves — cheaper in practice, since apps that aren't there cost nothing, and cheaper again on paid Apify tiers. 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. Run the actor. Each listing is fetched and its structured-data block parsed, in parallel up to maxConcurrency.
3. Read the dataset. Each row carries the app profile, or found: false if the package has no live listing.
4. Filter to found: true before you export if you only want live apps.

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.
• 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 metadata.

Input

{
  "items": ["com.spotify.music", "com.whatsapp"],
  "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. One dataset row comes back per item, 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"
}

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.

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.

vs. alternatives

	What it costs	What you get	Trade-off
This actor (google-play-app-lookup)	$4 per 1,000 resolved packages (less on paid tiers), $0.005 actor start, nothing for a package with no live listing	A flat, stably-named app profile per package — developer, category, rating, price, content rating, icon — from Google's own structured data	Profile only. No install counts, no in-app purchase tiers, and no individual reviews.
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.
automation-lab/google-play-scraper (644 users)	$0.0023 per app detail, $0.005 start	App details plus reviews as a separately billed event	Cheaper per detail row, and it covers reviews — which this actor deliberately doesn't.
Doing it yourself	Your time + parsing the structured-data block, 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? Not from this actor — it returns one profile row per package. Review scraping is a different shape, billed per review, and there are dedicated actors on the Store for it.

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 profile lookup for iOS apps, plus an optional reviews mode.
• 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.