App Store Apps & Charts Scraper

Live Top Free and Top Paid rankings for any Apple storefront, plus full app metadata by App Store ID, bundle ID or store URL — straight from Apple's own public endpoints. No login, no API key, no browser.

What it collects

Mode	What you get
charts	The live Top Free / Top Paid rankings for any of ~160 storefronts, with chart position preserved, optionally hydrated with each app's full metadata.
apps	Full metadata for specific apps — looked up in every storefront you list, so you get an N apps × M countries comparison table in one run.

Read this before you compare anything: per-country data really differs

Price, currency, rating, rating count and the current version are all per-storefront facts. Measured on Facebook in a single minute:

Storefront	Currency	Rating	Rating count	Version
us	USD	4.52522	28,006,734	575.0.0
gb	GBP	4.52205	3,173,060	576.0.0
jp	JPY	4.39079	1,031,790	576.0.0
de	EUR	4.37808	1,386,832	576.0.0

The US was a whole release behind the other three at that moment. So there is no such thing as "the app's rating" — every row here carries countryQueried, always.

The traps it handles

• lookup silently caps at 210 results. 10/50/100/150/200 identifiers all come back complete; 300 in returns 210, and 400 in returns 210 — HTTP 200, no error, no truncation flag. A client that posts 300 IDs loses 90 and cannot tell. Batched at 200, with the batch count reported.
• One vendor, three conventions for a bad country — and one of them lies. lookup?country=zz answers 400. The chart host answers 500 text/html. But apps.apple.com/zz/app/... answers HTTP 200 serving the US page, so an unsupported storefront reads as a real country-specific measurement. Bad countries are refused in code and every country's rating is compared against the US baseline, so a silent fallback shows up as ratingIdenticalToUsBaseline in the data.
• top-grossing is gone. Apple no longer serves it, new-apps-we-love or new-games-we-love from this API — all three 404 exactly like a typo would. Only top-free and top-paid remain, and asking for a removed one is refused with an explanation instead of an error row on every run.
• Chart limit is 1–100, and 101 is an HTTP 500 HTML page — not a 400, not a clamp. A bad feed on the same URL shape is a 404 with a JSON body. Clamped in code.
• Ratings are floats and Apple mixes types on purpose. averageUserRating is 4.85717, userRatingCount is an int, and fileSizeBytes is a string of digits. An int()-first coercion reports ChatGPT's 4.857 as 4 — that bug was caught on this actor's first smoke test and there is now a trap case pinning it.
• The two rating sources disagree. The store page's JSON-LD said 28,008,005 while lookup said 28,006,734 for the same app, storefront and minute — 1,271 apart, and the JSON-LD value is rounded to one decimal against lookup's five. Both are published, never merged, with the gap as a number in ratingCountDisagreement.
• A missing app is an empty success. lookup answers an unknown identifier with HTTP 200 and resultCount: 0, not a 404 — turned into an ERROR row that says so. An app can also genuinely exist in one storefront and not another.
• A chart row carries 8 fields; the app has 30+. Hydration costs one batched request per 200 apps and is on by default; rows say which shape they came from in metadataSource.

Why there are no reviews here

Individual review text is not reachable over HTTP without something this actor is not allowed to have, and both routes were taken to the end:

1. The legacy reviews RSS returns an empty feed on an HTTP 200 and will not say why. The same URL, ten times in a row:

App	Format	Entries returned
Facebook	xml	[50, 0, 0, 0, 0, 0, 0, 0, 0, 0]
Facebook	json	[0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
ChatGPT	xml	[0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
ChatGPT	json	[50, 50, 50, 50, 50, 50, 50, 50, 50, 50]

The first request after a pause returns real data and the rest come back empty — per-IP throttling answered with an empty 200 rather than a 429. Worse, a bogus app ID returns the identical shape, so "app doesn't exist", "app has no reviews" and "you're being throttled" are one response. sortby is inert too: mostrecent, mosthelpful, mostfavorable, mostcritical and bogus all return the same thing. Shipping that would mean shipping a scraper that returns nothing and calls it success.

2. amp-api.apps.apple.com needs a bearer token Apple no longer embeds. The 980 KB product page contains no MEDIA_API key, no config meta tag, and the string token does not occur anywhere in it.

What is exact and reachable is the rating summary — value and count, per storefront, from two independent sources — so that is what this actor publishes. It does not pretend to have review text.

Output

One dataset, recordType tells the rows apart:

• SEARCH_SUMMARY — one per run: storefronts requested vs returned, lookup batches and the silent cap, rating disagreements, suspected US fallbacks, identifiers not found.
• APP — one row per app per storefront, with upstream's object passed through verbatim alongside the normalised fields.
• ERROR — one per input that failed, so every input maps to at least one row.

Anti-bot and limits

No WAF. Seven TLS profiles (chrome124, chrome131, chrome136, safari17_0, edge101, firefox133, chrome99_android) returned 200 on lookup with byte-identical 10,455-byte bodies, cold, no warmup, no proxy. A proxy is optional and off by default.

Apple's chart host is genuinely flaky under load — six identical requests returned one connection error — so the retry ladder matters more than raw concurrency here.

Policy

itunes.apple.com disallows /search* and /*/rss/*; this actor uses /lookup, which is allowed, and does not do keyword search. rss.marketingtools.apple.com places no restriction on the chart paths. apps.apple.com disallows /api/* and /v1/*; the product page /{cc}/app/{slug}/id{n} is allowed and is the only path used there. No AI crawler group appears on any host. Verified with an RFC 9309 wildcard-correct matcher — urllib.robotparser matches by prefix only and would read /*/rss/* as harmless.