App Store Review Radar 📱

Watch a list of App Store apps and get paid-for alerts only when a genuinely NEW review appears — not a one-shot pull, and not a bill for every check.

Most App Store review scrapers on the Store are a one-time pull: run it, get today's reviews, done. This one remembers which reviews it already delivered and only charges when a real, new review shows up since the last check.

How it works

1. Give it a monitorId and a list of {appId, country} pairs.
2. Each run fetches Apple's own public reviews feed for each app and compares against reviews already delivered for that app.
3. You pay per genuinely new review (new-review-detected) — checking an app with nothing new is free. Re-running the same monitor never re-bills a review you already got.

Input

Field	What it does
monitorId	Names this monitor's durable history — required.
apps	1–30 objects {"appId": "284882215", "country": "us"}. appId is the app's numeric Apple ID (visible in the App Store URL). country is a 2-letter storefront code. New apps can be added later under the same monitorId.
notifyOn	new_alerts (default) fires the webhook only when paid reviews were delivered.
webhookUrl	HTTPS only; delivers a digest of paid reviews as JSON.

Output

• Dataset — one row per delivered review: app, country, rating, title, text, reviewer, app version, review timestamp, App Store link. Unchanged checks don't appear in the Dataset.
• Run status — clear reasons on bad input or a run that ran out of time.

Delivery and charging guarantee: at-most-once

For a single detected review, the dataset write and the pay-per-event charge each happen at most once — never twice. This is not "exactly-once", and we do not claim it is: the right to perform an irreversible action (dataset write + charge) is granted by Apify's only atomic primitive, RequestQueue.addRequest(uniqueKey), in a separate named journal queue <prefix>-<monitorId>-claims. Apify's Key-Value Store has no CAS, no conditional write and no ETag, so a KV-based state machine cannot guarantee it and is kept for diagnostics only.

The trade-off is deliberate: if a run crashes after taking the claim, that event may be lost (it is closed as dataset_unknown / charge_unknown and is never re-delivered) — but you are never charged for it twice. "We never overcharge" is worth more than "we never miss a row".

Boundaries of the guarantee, stated honestly:

• it holds as long as the named claims queue exists. Anyone with account access can delete or recreate it from the Console/API, which starts the journal from scratch — an unavoidable boundary of any durable storage, not a defect of the protocol;
• it applies from the build that introduced the claim gate onward. Runs from older builds against the same monitorId are not covered, and old builds must not keep running on it;
• seenIds eviction is a separate, independent source of possible re-billing (see below).

What this does NOT promise

• Full historical backfill: each check reads only the most recent ~50 reviews Apple's feed returns for that app. For regular monitoring this is normally enough to catch everything new since the last run; if an app receives more than ~50 new reviews between two runs, the oldest ones in that burst may be missed. windowFull in the run coverage flags when a check hit that ceiling.
• Aggregate star rating changes — this actor reports individual new reviews only, not the app's overall rating trend.
• A change to an already-seen review's text or rating is not treated as a new event.

A note on the source

Reviews come from Apple's public, undocumented itunes.apple.com/.../rss/customerreviews/.../json feed — no login, no scraping risk, the same data a browser gets when it requests the RSS view. This is not the official App Store Connect Customer Reviews API (that requires a developer account and only covers your own apps); it's a public feed with no published stability guarantee, so its format could change.