The App Store Reviews RSS Feed Still Works — Here's How to Use It
Apple's customer-reviews RSS feed is still live in 2026: no auth, one URL, ~500 recent reviews per country. The format, a real example, and where it stops.
The Argus Team
Reply Argus
Yes — as of mid-2026 Apple's customer-reviews RSS feed is still live, still needs zero authentication, and still hands you roughly the 500 most recent reviews for an app from a single URL you can paste straight into a browser. No API key, no JWT, no App Store Connect login. Change the numeric app id and the two-letter country code in the URL and you get that storefront's reviews back as JSON or XML.
For a lot of quick jobs — a dashboard widget, a scheduled scrape, a sentiment experiment — it's all you need. It also has hard edges: it caps out, it's per-country, it drops your developer responses, and it can't post a reply. This guide covers the exact URL format, a real example against a live app, the fields you get back, and the precise line where you graduate to the App Store Connect API.
What is the App Store customer-reviews RSS feed?
It's a public, unauthenticated endpoint on `itunes.apple.com` that returns the recent written reviews for any App Store app as a machine-readable feed. It predates the App Store Connect API by years, and Apple never turned it off. There's no official documentation page and no support commitment — it's a de facto public feed, not a contract — but it responds today, and thousands of tools quietly poll it.
Because there's no auth, you can read any app's reviews, not just your own: competitor monitoring, market research, a public leaderboard. That's also why it can only read — writing a reply is a privileged action that has to go through an authenticated channel. The RSS feed is a window, not a door.
What's the URL format?
Three pieces do all the work: the two-letter country code (the storefront), the numeric app id, and the format suffix (`json` or `xml`). You can find your app id in any App Store link — it's the number after `id`, e.g. `apps.apple.com/us/app/whatever/id284882215`.
# Template — swap {country}, {appId}, and the format
https://itunes.apple.com/{country}/rss/customerreviews/id={appId}/sortBy=mostRecent/json
# Paginated form — page can be 1 through ~10, ~50 reviews per page
https://itunes.apple.com/{country}/rss/customerreviews/page=2/id={appId}/sortBy=mostRecent/json
# Concrete, live example — US storefront, most recent, JSON
https://itunes.apple.com/us/rss/customerreviews/id=284882215/sortBy=mostRecent/jsonPaste that last line into a browser right now and you'll get Facebook's US reviews back (284882215 is its real app id). That's the entire authentication story: there isn't one. Loop the country code over the storefronts you care about — `us`, `gb`, `de`, `jp`, `br`, and so on — and you've got a cheap, key-free review reader.
Here's the same call from the command line with `jq` pulling out just the rating and title of each review, which is usually the shape you want before you do anything else with it:
curl -s "https://itunes.apple.com/us/rss/customerreviews/id=284882215/sortBy=mostRecent/json" \
| jq '.feed.entry[] | { rating: .["im:rating"].label, title: .title.label, body: .content.label }'What does the feed actually return?
In the JSON form, `feed.entry` is an array of reviews. Each entry is a nest of `{ "label": "..." }` objects (the RSS-to-JSON conversion is clunky, but consistent). The fields you'll reach for on every review:
- `im:rating` — the star rating, 1 to 5, as a string label.
- `title` and `content` — the review's headline and body text.
- `author.name` — the reviewer's display name (a nickname, never an email or real identity).
- `im:version` — the app version the review was written against, which is gold for correlating a spike of one-stars to a bad release.
- `id` — a stable numeric review id you use to dedupe across polls.
- `updated` — an ISO-8601 timestamp of the review.
- `im:voteSum` / `im:voteCount` — the "was this helpful" tallies, if you care about them.
{
"feed": {
"entry": [
{
"author": { "name": { "label": "jane_on_the_subway" } },
"im:version": { "label": "4.2.1" },
"im:rating": { "label": "2" },
"id": { "label": "14272117577" },
"title": { "label": "Crashes on launch after the update" },
"content": { "label": "Ever since 4.2 it force-closes the second I open a thread...",
"attributes": { "type": "text" } },
"updated": { "label": "2026-07-06T09:14:22-07:00" }
}
]
}
}One gotcha with the XML variant
If you request /xml instead of /json, the first <entry> is app metadata (title, icon, id), not a review — clients skip index 0. The JSON feed we're showing here starts straight in on reviews, so watch which format you parse and don't blindly treat the first entry the same way in both.
How to pull your reviews with it
The whole loop, start to finish, for anyone wiring this into a script:
- 1
Step 1 — Grab your app id
Open your app's App Store page and copy the number after id in the URL. That single id is valid across every country storefront.
- 2
Step 2 — Pick your storefronts
Decide which countries matter. There's no 'all countries' call — you request each one separately, so build a list of country codes to loop over.
- 3
Step 3 — Page through 1 to ~10
For each country, request page=1 through page=10 with sortBy=mostRecent, stopping when a page comes back empty. That's the full window for that storefront.
- 4
Step 4 — Dedupe on the review id
Store each review's numeric id and skip ids you've seen on the next poll — that's how you spot what's genuinely new.
- 5
Step 5 — Schedule and diff
Run it on a cron (hourly is plenty; the feed caches). Any unseen id is a fresh review to act on.
The limits you'll hit
The feed is generous for what it is and then it stops, hard. Know these before you build on it:
- ~500 reviews, tops. Pagination dies around page 10 at ~50 reviews each, so you get roughly the 500 most recent per country — and never the back catalog. Apple publishes no official number, but that ceiling is consistent in testing.
- Per-country, always. One request is one storefront. A global app means looping dozens of country codes and merging the results yourself. There is no combined feed.
- No developer responses. The feed carries the reviewer's words only. Your public reply to a review does not appear in it, so you can't use it to audit what you've already answered.
- Ratings-only reviews are invisible. A user who taps three stars and writes nothing produces no entry. The feed is written reviews exclusively — a real blind spot given how many ratings carry no text.
- Read-only. There is no way to post, edit, or delete a reply through this endpoint. It reports; it can't act.
- No push, and it lags. You poll it, it doesn't notify you, and it caches — a brand-new review can take a little while to surface. It's a snapshot, not a live stream.
None of that makes the feed bad. It makes it a reader. The moment your job involves replying, covering more than the last 500, or reacting the instant a review lands, you've outgrown it, and that's where the official API begins.
RSS feed vs the App Store Connect API
Apple's real programmatic surface is the App Store Connect API — the `customerReviews` resource. It's a different animal: you authenticate with a JWT signed by an ES256 key you generate in App Store Connect, and in exchange you get the things the RSS feed can't do. Full review history with real cursor pagination instead of a 500-review wall. Your existing developer responses included on each review. Server-side filtering by rating and territory. And critically, the ability to POST a response — the API is how you actually reply in code. We walk through auth, endpoints, and the reply call in the [App Store Connect reviews API reference](/blog/app-store-connect-reviews-api-reference).
The honest split: reach for the RSS feed when you're reading, especially apps that aren't yours (you can't touch a competitor's reviews through App Store Connect). Reach for the API when you're writing, need the whole history, or need to move fast. Many teams use both. And note the asymmetry across stores: this RSS trick is Apple-only. Google Play has no public feed at all — pulling Play reviews means the authenticated Google Play Developer API from line one, its own [Google Play reviews API reference](/blog/google-play-reviews-api-reference), and the [App Store vs Google Play differences](/blog/app-store-vs-google-play-review-replies) are worth a read first.
The part everyone underestimates
Getting reviews out is the easy 10%. The real work is deduping across polls, merging dozens of country feeds, matching each new review to your reply history, and never letting a Friday-night one-star sit until Monday. That plumbing is most of the project — and you'll rebuild it for both stores.
When you'd rather not run the plumbing
Polling per-country RSS, paging the API for older reviews, wiring notifications, then building it all again for Google Play — that's a lot of code to own for what is, ultimately, "tell me about new reviews and help me reply." This is the exact job [ReplyArgus](/features) does out of the box: it watches both the App Store and Google Play in one inbox, so there's no per-country loop and no polling to babysit. New reviews surface the moment they land (mechanics in [get notified of new App Store reviews](/blog/get-notified-of-new-app-store-reviews)), each with an on-brand reply already drafted — grounded in your past approved replies and your store listing, not invented — and translated into the reviewer's own language. You approve and it posts through the official channel; nothing goes public unread unless you set a rule for it.
Here's the kind of draft it hands you for the crash review from the JSON example above — the sort of reply that reads like a person who runs the app, because it's grounded in what your app actually is:
Crashes on launch after the update. Ever since 4.2 it force-closes the second I open a thread. Was fine before.
A launch crash right after 4.2 is on us — thank you for pinning it to the version, that's the clue we needed. We found a thread-open crash in 4.2.1 and a fix is in the build going out this week. If you can update once it lands and it still force-closes, reply here with your device model and we'll chase it down directly.
Frequently asked
- Does the App Store reviews RSS feed still work in 2026?
- Yes. Apple's customer-reviews RSS feed on itunes.apple.com is still live and still requires no authentication. Paste itunes.apple.com/us/rss/customerreviews/id=YOUR_APP_ID/sortBy=mostRecent/json into a browser and you'll get JSON reviews back. It's an undocumented, de facto public endpoint with no support commitment, but it responds today.
- What's the URL for the App Store customer-reviews RSS feed?
- itunes.apple.com/{country}/rss/customerreviews/id={appId}/sortBy=mostRecent/json — swap in a two-letter country code, your numeric app id (the number after 'id' in any App Store link), and use /json or /xml. Add /page=2/ before the id for pagination, and sortBy accepts mostRecent or mostHelpful.
- How many reviews does the RSS feed return?
- Roughly the 500 most recent written reviews per country storefront — about 50 reviews across up to 10 pages. Apple documents no official limit, but pagination consistently stops around page 10 in testing. You cannot reach older reviews through the feed; for full history you need the App Store Connect API.
- Does the RSS feed include developer responses or ratings without text?
- No to both. The feed carries only the reviewer's title and text, so your public replies never appear in it, and a rating with no written review produces no entry at all. If you need to see your responses or reply in code, use the App Store Connect API's customerReviews resource instead.
- Can I reply to reviews through the RSS feed?
- No — the RSS feed is strictly read-only. Posting, editing, or deleting a developer response requires the authenticated App Store Connect API (for Apple) or the Google Play Developer API (for Google Play). The RSS feed is only for reading reviews, and it can read any app's reviews, not just your own.
- Is there a Google Play equivalent of this RSS feed?
- No. Google Play offers no public, unauthenticated reviews feed. Reading Play reviews programmatically means using the authenticated Google Play Developer API from the start. This RSS shortcut is Apple-only.
So: the RSS feed still works, it's the quickest key-free way to read App Store reviews, and it'll carry read-only jobs a long way. Build knowing its walls (500 reviews, one country per call, no responses, no writes, Apple only) and it earns its keep. But the day the job turns into replying, you're signing up to own a real pipeline. [Start free with ReplyArgus](/signup) (no card) and skip that build: both stores in one inbox, a grounded reply already written in any language, waiting for your one click.
Try it
Let Argus draft your next reply.
Watch it answer a real review in your voice. 10-day trial, no card to begin.
Keep reading
App Store Reviews Not Showing? The Full Fix List for Apple and Google Play
App Store or Google Play reviews not showing? Here's every real cause — moderation delay, wrong country storefront, filtering, rating lag, cache — and the fix.
Read moreAre App Store Reviews Fake? How to Spot Them and What to Do
Yes, some App Store and Google Play reviews are fake — but fewer survive than you think. How to spot them, and what to do when they hit your app.
Read more