Quick answer: For Apple App Store reviews, use Apple's official RSS review feeds (a public JSON endpoint per app and country) or the App Store Connect API for your own apps. For Google Play reviews, use the Google Play Developer Reply-to-Reviews API for apps you own, or a licensed data provider for broader coverage. Both stores' terms restrict raw scraping, and the official feeds give you cleaner, structured review data anyway.
If you are building sentiment analysis, competitor tracking, or a voice-of-customer dashboard, app reviews are gold. The trick is collecting them without violating store terms or mishandling personal data. Here is the compliant path for each store.
Apple App Store: Official RSS Review Feeds
Apple publishes a customer-reviews RSS feed for every app, per country, that returns structured JSON. It is public and intended for programmatic use. You pass the app's numeric ID and a storefront country code, and you get back recent reviews with rating, title, body, author nickname, and version.
The feed is paginated and returns a bounded window of recent reviews rather than the full lifetime history, but for ongoing monitoring that is exactly what you want: poll on a schedule, store what is new, and build your own history over time.
For your own apps, the App Store Connect API gives you deeper, authenticated access to your customer reviews and lets you respond to them. Use that for first-party analytics.
Google Play: Official APIs for Your Own Apps
Google's story is more restrictive on third-party reviews. The Google Play Developer API (Reply-to-Reviews) lets you read and respond to reviews for apps you own and control. That is the sanctioned route for first-party review data, and it returns structured review objects with rating, comment, language, and timestamps.
For competitor reviews on Google Play, Google does not offer a broad public review API, and scraping the Play Store web or app violates Google's terms. The compliant option for broad coverage is a licensed third-party data provider that has its own agreements, rather than scraping Google directly.
| Store | First-party (your apps) | Third-party / competitor | Scraping the site |
|---|---|---|---|
| Apple App Store | App Store Connect API | Public RSS review feeds | Restricted by terms |
| Google Play | Play Developer API | Licensed data provider | Prohibited by terms |
What About Fetching Public Pages
The RSS feed makes fetching unnecessary for Apple reviews, which is the point: prefer the structured feed. For Google Play third-party reviews, fetching the Play web pages to harvest reviews runs against Google's terms, so that is not a lane I would recommend. When an official feed or API exists, use it.
There is a legitimate, narrow role for fetching in this space: pulling a public app landing page (a developer's own marketing site, a press page, a changelog) to enrich your dataset with context. That is public content you are permitted to read. For the boundaries, see whether web scraping is legal and ethical web scraping best practices.
For that permitted enrichment, link.sc fetches a public URL and returns clean markdown or structured JSON. Use it on public pages you may access, not to route around a store's protections.
A Code Sketch: Apple RSS Feed First
Primary path: pull recent App Store reviews from the official RSS JSON feed.
import requests
def fetch_appstore_reviews(app_id, country="us", page=1):
url = (
f"https://itunes.apple.com/{country}/rss/customerreviews/"
f"page={page}/id={app_id}/sortby=mostrecent/json"
)
r = requests.get(url, timeout=30)
r.raise_for_status()
entries = r.json().get("feed", {}).get("entry", [])
reviews = []
for e in entries:
# The first entry is app metadata, not a review; it lacks "author".
if "author" not in e:
continue
reviews.append({
"rating": int(e["im:rating"]["label"]),
"title": e["title"]["label"],
"body": e["content"]["label"],
"version": e["im:version"]["label"],
"author": e["author"]["name"]["label"],
})
return reviews
For Google Play first-party reviews, the Play Developer API uses OAuth 2.0 (Authorization: Bearer), which is standard. Just remember link.sc authenticates with x-api-key and an lsc_... key, a different scheme from Google's Bearer tokens.
And the permitted public-page enrichment fallback:
import requests
def fetch_public_page(url):
r = requests.post(
"https://api.link.sc/v1/fetch",
headers={"x-api-key": "lsc_your_key_here"},
json={"url": url, "format": "markdown"},
timeout=60,
)
r.raise_for_status()
return r.json()["content"]
The Sentiment Use Case
Once you have structured reviews, the analysis is the fun part: run each review through a classifier or LLM to tag sentiment, extract feature requests, and cluster complaints by theme. Because the RSS feed and Play API return clean fields, you skip parsing entirely and go straight to modeling. Track sentiment by app version to see whether a release helped or hurt.
If you want the reviews handed to an LLM as clean structured objects, our guide on extracting structured JSON from any webpage covers the general pattern of turning messy content into typed records ready for analysis.
ToS and PII Note
Not legal advice. Two things matter here. First, terms: prefer the official feeds and APIs, use the licensed route for broad Google Play coverage, and do not scrape the stores directly. Second, personal data: reviews contain author names and freely written text that can include personal details. Treat that as PII. Minimize what you store, avoid republishing individual reviewers' identities, honor deletion requests, and follow applicable privacy law (GDPR, CCPA) when you process it. Aggregate sentiment is usually all you need, and it carries far less risk than storing raw personal reviews indefinitely.
The short version: Apple RSS and App Store Connect for Apple, the Play Developer API or a licensed provider for Google, and handle reviewer data as the personal information it is.
Want clean, structured content from the public web to feed your review pipeline? Start free with link.sc.