App Store & Google Play Metadata Scraper & Monitor

Export App Store and Google Play app metadata, releases, prices and aggregate ratings to a normalized Dataset. Compare competitor listings, then reuse the same Task to identify version, price and rating changes. Each app keeps your externalId and optional cross-store groupId for joining to a CRM or spreadsheet.

Review collection is retired. This Actor does not fetch review text, reviewer profiles or developer replies. Older inputs with includeReviews: true return INVALID_INPUT with REVIEWS_UNAVAILABLE, without source requests or app-event charges. Set that flag to false to use metadata monitoring.

Paste URLs first; add grouping when you need it

The App URLs or IDs field accepts one URL, Apple ID or Android package per line. Advanced JSON is optional. For example:

{
  "appUrls": ["https://apps.apple.com/us/app/spotify/id324684580", "com.spotify.music"],
  "apps": [],
  "mode": "snapshot",
  "includeReviews": false
}

URL storefront settings are preserved; bare IDs default to US/en. URL and advanced entries share the 500-entry limit. To compare the same product across stores, use two advanced entries with groupId: "spotify" and distinct externalId values, as in the competitor Task. Group IDs are supplied by you; the Actor never guesses an iOS/Android match.

Track competitor versions and release dates focuses the output on version, previous_version, last_updated, changed_fields and group_id. The releases view chooses columns and retains baseline, unchanged and failure rows. For a release alert, require status == "SUCCESS" and change_types containing VERSION_CHANGED or NEW_RELEASE; join the two storefronts by group_id. A null version or release date stays null.

Related tools for app-brand research

• Compare branded search interest: Google Trends compares app or publisher names you select. Use the relevant country and review ambiguous names before comparing a timeline with release dates. Google search interest is not app-store search volume or download counts.
• Watch branded search suggestions: Google Autocomplete monitors suggestions for app-name prefixes on Google. It does not collect App Store or Google Play autocomplete or app rankings.

Pass selected names as new keyword inputs yourself, or through your own workflow. These Actors have separate runs and pricing; this metadata monitor does not call them automatically.

How to scrape App Store and Google Play apps

Start with the metadata export example or the competitor monitor. Replace the sample IDs. Numeric App Store IDs, Google Play package IDs and full listing URLs are accepted in the App URLs field. Advanced objects add explicit storefront and CRM IDs:

{
  "apps": [
    {"store": "google_play", "id": "com.spotify.music", "country": "US", "language": "en", "externalId": "spotify-android"},
    {"store": "app_store", "id": "324684580", "country": "US", "externalId": "spotify-ios"}
  ],
  "mode": "snapshot",
  "includeReviews": false,
  "maxReviewsPerApp": 0
}

Use a $0.04 spending limit and 180-second timeout for this two-app example. A successful snapshot costs $0.004 in app-check events, including platform usage at the current Store tariff. Larger batches support up to 500 listings; start small to check coverage and duration in the required countries.

App Store and Google Play scraper output

The apps Dataset view contains one app status row per input: identifiers, source link, observation timestamp, name, version, release date, price and currency, aggregate rating and counts where supplied, listing metadata, changed_fields, previous values and error. Missing source fields remain null; no release or review count is invented.

Statuses distinguish SUCCESS, PARTIAL, NOT_FOUND, RATE_LIMITED, FAILED, INVALID_INPUT and SKIPPED_BILLING_LIMIT. A failure is not an app removal or a zero rating. Failed and partial checks never replace the last good baseline. Legacy review fields and the retired review view remain in the schema for historical Dataset compatibility; new runs emit only app records.

Three ASO monitoring recipes with existing Tasks

Use metadata changes to decide which competitor listing deserves review. This Actor does not measure keyword positions, search visibility, installs over time, conversion rates or the effect of a listing edit on those metrics.

Scenario	Existing Task and input	Output and downstream rule
Version and release changes	Release monitor; replace app IDs, country and optional groupId	Releases view; require SUCCESS and VERSION_CHANGED or NEW_RELEASE in change_types
Description and title edits	Competitor monitor; use your target listings and a fixed country/language	Listing metadata view; require SUCCESS and changed_fields containing description or name; compare the current value with previous
Paid/free and listing price changes	The same competitor Task; select Listing prices after running	Require SUCCESS and PRICE_CHANGED, BECAME_FREE or BECAME_PAID in change_types; retain currency, country and previous values

The first successful monitor check saves a baseline. Repeat the same Task to observe later edits. Views select columns, not events: baseline, unchanged and failure rows remain visible. A listing that changes several fields produces one app change event, not a charge per edited field. Metadata and price recipes reuse the same checks, so no second Task or second run is needed.

Price means the public app listing's purchase price, not subscriptions, in-app purchases or promotional eligibility. Missing fields remain null. A description change is a listing observation, not proof of an ASO improvement; export the text for editorial comparison with your own performance data.

Repeating a competitor check

Switch to mode: "monitor" and reuse the same saved Task. The first successful check establishes BASELINE. Subsequent checks report UNCHANGED or confirmed version, release, price, rating/count and metadata changes. Both output modes retain an app status row, including quiet checks. For direct API runs, keep an explicit monitorId stable; use another ID for an independent watchlist.

Each country/language combination has its own baseline. groupId joins iOS and Android listings only when you supply it. Do not interpret a difference between storefronts as a historical change.

Pricing and repeated-use cost

The Store Pricing tab is authoritative:

• app-check: $0.002 per distinct successful app/storefront check, including a quiet monitoring check.
• app-change: $0.002 per delivered non-baseline metadata change event.
• review-new: the historical event may remain visible in Pricing; current builds never charge it.

A quiet daily watchlist of 10 app/storefront entries for 30 days has $0.60 in app-check events. Ten delivered app-change events add $0.02, for $0.62 total. The current Store tariff includes platform usage; your external integrations can have their own costs. Invalid, failed, partial, rate-limited and skipped checks incur no app events. Duplicate aliases and retries are not separately billed. Use Apify's maximum total charge setting.

CSV, Google Sheets, n8n and API workflow

Export the apps view as CSV or JSON. In n8n, run the saved Task using the Apify integration, wait for completion, retrieve its default Dataset and route only successful non-baseline changes to an alert or spreadsheet update. Upsert by source_id and retain scraped_at; keep failures in a separate review queue. The Actor does not create schedules, send notifications or write to Sheets.

Source scope and limitations

Apple metadata uses the documented root ID Lookup endpoint. Google Play metadata uses the public app-details page, not a documented developer API. No login or browser is required. Direct HTTP is the default; bounded retries stop on access blocks. A proxy must not be used to bypass source restrictions.

The exact Apple review RSS and Google Play review RPC paths are disallowed by the sources' robots policies. Google Play terms also prohibit harvesting user personal data. Those request implementations have been removed. The root Apple lookup and Google Play app-details paths are different endpoints. Public access does not grant blanket redistribution rights. Apple promotional assets have separate use restrictions; this Actor does not download them. Use metadata and links within applicable source terms.

Country availability, undocumented Play markup and incomplete fields can change. Only compact last-successful monitoring state is retained; raw responses are not stored. Customers control Dataset retention in their Apify account.

AI and MCP

Direct authenticated endpoint: https://mcp.apify.com?tools=automa-flow/app-store-google-play-monitor. Ask: “Check these two Google Play package IDs in the US, without reviews, and return versions, prices, aggregate ratings and explicit failure statuses.” Execution uses your own Apify account and pricing. Discovery alone does not prove that a source request will succeed.

FAQ

Can this export or monitor reviews?

No. Both review sources and their saved examples are retired. Use the metadata and competitor examples linked above.

Does an empty change list mean that the source failed?

Check status: SUCCESS with UNCHANGED is a verified quiet check. A source failure has its own status and error, and retains the previous good state.

Do I need a developer account?

No Apple or Google Play credentials are accepted or required. The supported scope is public listing metadata, not private console metrics or review APIs.