App Store Monitor — Version, Price, Rating & Listing Changes
Pricing
from $1.20 / 1,000 changes
Watch App Store and Google Play listings on a schedule and get one row per change: new versions with release notes, price and in-app purchase changes, rating moves past your threshold, title and description edits, developer, category, size, minimum OS and installs band. Or a full snapshot.
One app per entry. An App Store URL (https://apps.apple.com/us/app/spotify-music-and-podcasts/id324684580, with or without the name in it), a numeric App Store ID (324684580), a Google Play URL (https://play.google.com/store/apps/details?id=com.spotify.music) or an Android package name (com.spotify.music) all work. An App Store bundle ID looks exactly like an Android package, so write it with a prefix: ios:com.spotify.client. The country in a URL is ignored — countries decides which storefronts are read. The same app written twice is read and billed once.
[ "324684580", "com.spotify.music", "ios:com.spotify.client"]snapshot returns every listing whole — one paid app row per app per country, no check fee — and stores a baseline for any listing that has none yet, so a later monitor run has something to compare against. monitor reads every listing — one paid app-check each, changed or not, the first sighting included — compares it with the previous run and returns one paid change row per family that changed. A listing seen for the first time gets a baseline row; an unchanged one gets no row of its own. Schedule monitor mode daily.
Two-letter storefront codes. Each app is read in each country and gets its own row and its own history: price, rating, title and even availability differ between storefronts. gb, not uk. Up to 50.
[ "us"]The language Google Play pages are requested in (hl), for example en, de or pt-BR. App Store listings always come in the storefront's own language.
Which change families are worth a row. Applied before anything is billed: a family you did not tick is never charged for, and the snapshot still moves past it, so ticking it later reports what happens next rather than everything since.
[ "version", "price", "rating", "listing", "metadata"]Report a rating change when the average rating has moved at least this many stars since it was last reported. Compared with the last reported value, not yesterday's, so a slow slide is still caught once it adds up. 0 reports every move.
Report a rating-count change when the number of ratings has moved at least this many percent since it was last reported. 0 reports every move — on a popular app, that is every run.
Also write a full app row for every listing that was compared and had no change, billed as an app row on top of its app check. Off by default: a monitor's job is to stay quiet when nothing moved.
Put the whole store description on app rows. descriptionLength is always there. Change rows never carry the description twice: they carry the lines added and removed and the first 200 changed characters.
Put the current version's release notes ("What's new") on app rows and, in full, on version change rows.
Put every screenshot URL on app rows. screenshotCount is always there; the URLs are 40 per app on some Play listings, so they are off by default.
When a monitor run finds at least one change, POST one JSON digest of the change rows to this URL. Ten-second timeout, one retry, 64 KB cap, and a redirect to another host is never followed. Treated as a secret: only its host is ever logged. A failed POST is a free webhook-failed row and never fails the run. Leave empty for no webhook.
Name of the key-value store that holds each listing's last snapshot — one record per app per country. The Actor creates it on its first run and reads it back on every run after; that memory is what makes this a monitor. Keep one store per watchlist: two schedules sharing a store would compare against the same snapshots, so the second stops with a clear message instead of double-reporting. Snapshots not seen for 90 days expire.
Apps past this many are not read and not charged; one free row lists them.
How many lookups and Play pages are in flight at once. Each parallel worker keeps its own proxy session, and its successive requests are spaced 300–600 ms apart.
Wall-clock budget for the whole run. When it is reached the Actor stops fetching, keeps and bills what it already delivered, and writes a free timeout row for each listing it never reached — those keep their snapshots.
Apple's lookup and Google Play's app pages both answer through Apify's datacenter proxy, so that is the default and its cost is inside the event prices. Switch to the RESIDENTIAL group if a store starts refusing it; a refused listing is a free blocked row after one retry from a fresh exit.
{ "useApifyProxy": true}