App Store Reviews Scraper - All Countries, No API Key

Pull customer reviews for any iOS app on the Apple App Store, from any country storefront, without an API key, without a developer account, without App Store Connect access and without a proxy. Give the actor an app ID, an apps.apple.com URL or an iOS bundle ID, pick your storefronts, and get back a clean table: star rating, review title, review body, author, date, whether the review was edited, and the developer's public response where one exists.

It reads the same endpoint Apple's own storefront web app uses, anonymously. Nothing to authenticate, nothing to sign. It runs on the Apify free plan and returns data on the free plan.

Up to ~78,000 reviews per app, not 500

This is the headline, and it is a measured number rather than a claim.

The old public RSS review feed served 50 reviews per page and refused page 11, a hard ceiling of 500 per app per country. This actor no longer uses that feed. Its depth is now bounded by the app's actual review count, not by a policy limit:

App	Reviews reachable (measured)
Facebook	~78,000
Calm	~42,000
A 170k-rating app	~14,000

Verified end to end: a single run pulled 1,500 unique reviews from one app in one storefront, zero duplicates, spanning September 2017 to August 2026. Under the old feed that request would have stopped at 500.

Pagination was checked for integrity, not just for volume: 800 consecutive reviews across 40 pages returned zero duplicate review IDs.

What you get per review

Field	What it holds	Fill rate measured live
reviewId	Apple's review identifier, stable across runs	300/300
appId / appName	The app the review belongs to	300/300
country	Storefront	300/300
source	Which endpoint served this row - see below	300/300
rating	Star rating, 1 to 5, as a number	300/300
title	Review headline	300/300
text	Full review body, HTML entities decoded	300/300
userName	Reviewer's display name	300/300
updatedAt	ISO 8601 timestamp	300/300
isEdited	Whether the reviewer edited it after posting	300/300
hasDeveloperResponse	Boolean, so you can filter without null checks	300/300
developerResponseText / developerResponseAt	The publisher's public reply	6/300 (~2%)
reviewUrl	Link back to the app's reviews on Apple	300/300
scrapedAt	Collection timestamp	300/300

Three fields are always empty, and you should know why

appVersion, voteSum, voteCount and userUrl are emitted as null on every row from the current source.

The retired RSS feed carried them. Apple's current reviews endpoint does not expose them, and no parameter recovers them - extend=version, extend=appVersion, include=app and an explicit fields[user-reviews] request were all tried and all returned the same six attributes.

They are kept in the schema rather than deleted so that rows from the legacy feed (see the fallback section) stay shape-compatible, and so nobody wonders where the column went. If your workflow depended on reading sentiment by app version, that specific analysis is not currently possible from Apple's public reviews data. Saying so is better than shipping you a column of nulls with no explanation.

The source changed on 2026-08-21, and here is exactly what happened

The itunes.apple.com/rss/customerreviews feed went dark. Not down - dark. It still answers HTTP 200, still returns a complete envelope with "title":"iTunes Store: Customer Reviews", an author block, a rights block and a same-day updated timestamp. It simply publishes zero review entries, for every app, every country, in both /json and /xml.

That was verified across 12 app-and-country combinations from three separate networks, including Apify's cloud, while lookup, search and the chart feeds kept working normally from the same machines.

An empty 200 is the most dangerous failure a scraper can meet, because the naive reading is "this app has no reviews" - a confidently wrong answer. So this actor does two things about it:

1. It uses the endpoint Apple's own web storefront uses. Apple's site bundle declares a same-origin proxy mapping https://amp-api.apps.apple.com/ to /api/apps/, and requests through that proxy need no bearer token at all. There is no token to extract, rotate or hardcode, and nothing that expires.
2. The legacy feed is still tried as an automatic fallback. If the new endpoint cannot serve an app or storefront, the old RSS feed is attempted before anything is reported as failed - it costs nothing when it is dark, and it carries appVersion and vote counts if it ever returns.

Every row carries source: amp-api for the current endpoint, rss for the legacy one. You never have to guess which fields to trust on a given row.

Ordering: there is no sort parameter, and no actor can give you one

Apple's reviews endpoint accepts no sort option. Nine variants were tested - sort=-date, date, -rating, rating, helpful, -helpful, mostRecent, mostHelpful and no sort at all - and all nine returned an identical first result. The parameter is silently ignored.

What you get is Apple's own fixed relevance ordering, which is not chronological. Sampling one app confirmed it: offset 0 held reviews from 2025 and 2024, offset 20 from 2021, offset 2,000 from 2017, offset 20,000 back to 2018. Recent reviews are present - the newest review in the first 120 was from July 2026 - but they are scattered rather than at the front.

This is why the old sortBy input has been removed instead of left in place as a knob that does nothing. In its place there is a filter that actually works:

publishedAfter - give it a date like 2026-01-01 and only reviews newer than that are delivered and billed. A live test returned 40 rows with the oldest at 2026-01-07. Because Apple does not sort, this filters what was fetched, so a narrow date range on a very large app may need a higher maxItems before matches turn up.

Input

{
  "appIds": [
    "310633997",
    "https://apps.apple.com/us/app/chatgpt/id6448311069",
    "com.burbn.instagram"
  ],
  "countries": ["us", "gb", "de", "jp"],
  "maxItems": 2000,
  "maxReviewsPerApp": 500,
  "minRating": 1,
  "maxRating": 2,
  "publishedAfter": "2026-01-01"
}

App identifiers are flexible on purpose. All three forms work and can be mixed in one run: numeric ID 310633997, full URL https://apps.apple.com/us/app/chatgpt/id6448311069, or iOS bundle ID com.burbn.instagram (resolved through Apple's lookup endpoint automatically).

Input aliases. Migrating from another scraper, or driving this from an LLM that guessed the field names? appIds also accepts ids, appId, apps, appUrls and urls. countries also accepts country, countryCodes and storefronts. maxItems also accepts maxResults, limit and maxReviews. publishedAfter also accepts since and reviewsAfter. A comma separated string like "us,gb,de" works anywhere a list does.

Every input field

• appIds - the apps to scrape. Required.
• countries - two letter iTunes storefronts. Defaults to ["us"]. Verified on us, gb, de, jp, br, pe, au and in.
• maxItems - hard ceiling on rows delivered and therefore on the bill. Matters more than it used to: depth now runs to tens of thousands, so this is the setting that keeps a run from being enormous.
• maxReviewsPerApp - optional per app-and-country cap so one huge app cannot eat the whole budget. 0 means no per-app cap.
• minRating / maxRating - star filter, applied before anything is written or billed.
• publishedAfter - ISO date. The way to target recent reviews given there is no sort.
• onlyWithDeveloperResponse - keep only reviews the publisher answered. Narrow by design; see the ~2% fill rate.
• proxyConfiguration - optional and off by default. Apple does not require a proxy here.

Scraping 1-star and 2-star reviews only

Set minRating: 1 and maxRating: 2. Filters run before the row is written, so you are not charged for the four and five star reviews you discarded. A live test returned 60 rows containing only ratings 1 and 2.

With tens of thousands of reviews now reachable per app, a complaint corpus is a genuinely different artefact than it was under a 500-review cap - you can pull years of one-star reviews for a whole competitive set and cluster them by theme.

Set minRating: 5 for the opposite job: testimonial-grade quotes with the reviewer name attached.

Multi-country review scraping for localisation

Reviews in de are written in German, in jp Japanese, in br Portuguese. Each storefront has its own review pool, so running one app across ten countries gives you a per-market sentiment read instead of a US-weighted average. Teams use this to decide which locale to localise next, and to separate a product problem from a translation problem.

Developer response mining

Filter with onlyWithDeveloperResponse: true to get only the reviews a company chose to answer publicly, plus the reply text and its date. This is unusually high-signal competitive research: support teams disclose known issues, refund policy and roadmap in review replies far more freely than in any official channel.

Plan for volume in the tens, not the thousands - measured at roughly 2% of reviews. This field is new; the retired RSS feed never carried developer responses at all.

Competitor review monitoring

Put five competitor app IDs in appIds, set a modest maxItems, add publishedAfter set to your last run date, and schedule it daily. Because reviewId is stable, deduplicating against yesterday's dataset is a single join. What you are building is an early warning system: the complaint in a competitor's reviews this week is the feature request in yours next month.

Sentiment analysis input

The output is already shaped for a sentiment or topic model: one row per review, text decoded and clean, rating as a numeric label to train or validate against, country as a segment, updatedAt for time series. Export as JSON or CSV from the dataset, or read it from the Apify API.

How this actor behaves when something goes wrong

1. Errors never enter the dataset. An app with no reviews in a storefront, an ID that does not resolve, an endpoint failure - each goes to a FAILURES record in the key-value store with the exact reason per input. None becomes a dataset row, because a row that says "error" bills you for receiving an error.
2. A run that delivered nothing is marked FAILED, not SUCCEEDED. Verified: a nonexistent app ID fails the run with a pointer to FAILURES.
3. A bad publishedAfter fails immediately with the offending value echoed back, rather than silently filtering everything away.
4. The current endpoint is validated before parsing. Apple's proxy rejects incomplete requests with 429 API capacity exceeded, which looks like rate limiting but is really a malformed request - the actor always sends the required platform parameters, so that path is not hit.
5. The free tier returns data. Nothing throws because a plan feature is missing. Proxy is optional and defaults to off.

Pricing

Pay per event. $0.0003 per review delivered, which is $0.30 per 1,000 reviews. No monthly subscription and no charge for starting a run.

You are billed only for rows that reach the dataset. Reviews removed by the rating, date or developer-response filters are not billed. Failed inputs are not billed. maxItems is a hard ceiling on both the row count and the bill, so a run cannot cost more than maxItems x $0.0003.

A 1,500-review deep pull costs $0.45. Pulling Facebook's full reachable ~78,000 US reviews would cost about $23 - possible now, which is exactly why maxItems exists.

Output sample

{
  "reviewId": "11405574963",
  "appId": "310633997",
  "appName": "WhatsApp Messenger",
  "country": "gb",
  "source": "amp-api",
  "userName": "Gruff The Sigma Rizzler",
  "userUrl": null,
  "rating": 5,
  "title": "Amazing",
  "text": "WhatsApp is really good however it's a bit hard to find some stuff...",
  "isEdited": false,
  "appVersion": null,
  "updatedAt": "2026-06-14T08:22:41.000Z",
  "voteSum": null,
  "voteCount": null,
  "developerResponseText": null,
  "developerResponseAt": null,
  "hasDeveloperResponse": false,
  "reviewUrl": "https://apps.apple.com/gb/app/id310633997?see-all=reviews",
  "scrapedAt": "2026-08-22T05:41:12.884Z"
}

Dataset views

• Reviews - date, country, stars, title, review, author, source. The reading view.
• Developer responses - the review paired with the publisher's reply and its date.
• Full records - every field including IDs, edit flag and the legacy columns. The export view.

Frequently asked questions

Do I need an Apple developer account? No. This reads what Apple's public storefront serves. It works on any app, including ones you do not own.

Do I need a proxy or an API key? Neither. No bearer token either - the endpoint used is a same-origin proxy that Apple's own site relies on, and it requires no authentication.

How many reviews can I get for one app? As many as the app actually has, up to a measured ~78,000 for a very large app. Use maxItems to control cost.

Why are appVersion and the vote counts always empty? Apple's current reviews endpoint does not expose them, and four different parameter approaches to recover them were tested and failed. See the field notes above.

Can I sort by newest? No - Apple's endpoint ignores every sort parameter, so no tool can honestly offer it. Use publishedAfter to target recent reviews instead.

What is the source column? Which endpoint served the row: amp-api for the current one, rss for the legacy feed used as fallback. Rows from rss carry appVersion and vote counts; rows from amp-api do not.

Can I schedule it? Yes. A small maxItems plus publishedAfter set to your last run date is the cheap daily-monitoring configuration.

Related actors

• App Store App Details Scraper - ratings, in-app purchase names and prices, versions and release notes.
• ASO Keyword Rank Tracker - what position an app holds for a keyword in a given storefront.
• Google Play Reviews Scraper - the same job on Android, with developer replies and app version.
• App Update Monitor - new versions and release notes across both stores.