App Review Data for an AI Pipeline: The Two APIs, the Glue, and the Shortcut
There's no single app review data API. Apple and Google give you two mismatched feeds. Here's the glue an LLM pipeline needs, and how to skip it.
The Argus Team
Reply Argus
There is no single "app review data API." Apple and Google expose two separate, mismatched feeds, and neither one hands you the clean, structured review data an LLM pipeline actually wants. If you're building a RAG system, a classifier, or an agent that reasons over what users are saying, you'll spend most of your effort not on the model but on the plumbing that gets reviews into a shape you can embed and query.
This is the honest version of that plumbing: what the real APIs give you, the catches that aren't in the quickstart, what you still build after the JSON lands, and where a Model Context Protocol connector lets you skip the ETL and hand an agent structured reviews and themes directly.
What does an "app review data API" actually give you?
Two APIs, one per store, and they don't agree on much. Apple's is the App Store Connect API, where the `customerReviews` endpoint returns a paginated, historical list of reviews for an app: rating, title, body, reviewer nickname, created date, and territory. Google's is the Google Play Developer API, where `reviews.list` returns reviews for one of your packages: a star rating, the comment text, language, device metadata, and a thread of any developer reply.
Both return JSON. That's where the resemblance ends. The field names differ, the auth models differ, the pagination differs, and the time windows differ in a way that quietly breaks naive integrations. If you want the field-by-field breakdown, the [App Store Connect reviews API reference](/blog/app-store-connect-reviews-api-reference) and the [Google Play reviews API reference](/blog/google-play-reviews-api-reference) map each response object. The shape of a raw call looks like this:
# Apple — App Store Connect API (historical, paginated)
GET https://api.appstoreconnect.apple.com/v1/apps/{APP_ID}/customerReviews
?sort=-createdDate&limit=200
Authorization: Bearer <ES256 JWT, signed with your .p8 key, expires <= 20m>
# Google — Play Developer API (only surfaces ~the last 7 days)
GET https://androidpublisher.googleapis.com/androidpublisher/v3/
applications/{PACKAGE_NAME}/reviews?maxResults=100
Authorization: Bearer <OAuth2 token minted from a service account>The catches nobody puts in the quickstart
The endpoints are easy. What bites you is the behavior around them, and several of these silently lose data rather than erroring, so run the list before you assume a nightly pull gives you a complete corpus.
- Google only returns ~the last week — `reviews.list` surfaces reviews from roughly the past seven days, not your full history. If you don't poll continuously and persist every page, older reviews are simply gone from the feed. Your historical corpus is something you accumulate, not something you can backfill later.
- Apple is historical but per-territory and paginated — you get the archive, but you page through it 200 at a time, and territory is a field you normalize yourself for a single global view. Language you'll want handled downstream too.
- Auth is two entirely different rituals — Apple wants a short-lived ES256 JWT you sign yourself with a `.p8` key (it expires in 20 minutes, so you're minting tokens constantly). Google wants an OAuth2 token from a service account linked in the Play Console. Neither is a simple API key you paste once.
- No embeddings, no themes, no sentiment — the APIs return text. Nothing is chunked, vectorized, categorized, or clustered. Every bit of the structure your LLM pipeline needs is on you to compute after the JSON arrives.
- Replies are a separate endpoint with their own rules — reading reviews and writing replies are different calls. Google's `reviews.reply` caps you at 350 characters and one reply per review; Apple's response flow is its own relationship. Round-tripping data through a model back to the store means wiring both directions.
- Rate limits and quotas apply — both APIs throttle. At the volume of an app with thousands of monthly reviews across two stores, you'll hit backoff and need retry logic, not a single loop.
From raw JSON to something an LLM can use
Say you've solved auth, you're polling both stores, and you're persisting every page so Google's rolling window doesn't eat your history. You still have a raw pile of two-schema JSON. Turning that into a feed a model can reason over is its own project, and it's the part that never ends because reviews keep arriving. The pipeline usually looks like this.
- 1
Step 1 — Normalize both schemas into one
Map Apple's fields and Google's fields onto a single review object: id, store, rating, language, territory, text, created_at, and any existing reply. Everything downstream depends on you not carrying two shapes forward.
- 2
Step 2 — Classify and tag
Run each review through a model to label it bug, feature request, praise, pricing, and so on, with a strict schema so the output is queryable. This is a real task with real pitfalls; [classifying app reviews with an LLM](/blog/classify-app-reviews-with-an-llm) covers the taxonomy and the JSON-mode guardrails that keep accuracy up.
- 3
Step 3 — Chunk and embed
Split longer reviews, embed them, and write the vectors to a store. Now similar complaints sit near each other and you can retrieve by meaning instead of keyword — the foundation of any RAG answer over reviews.
- 4
Step 4 — Retrieve and ground
At query time, pull the relevant reviews (and your past replies, if you're drafting) into the context window so the model answers from real data, not from its priors. Grounding is the whole game; [grounded vs. hallucinated replies](/blog/grounded-vs-hallucinated-ai-replies) is why a draft anchored to retrieved reviews beats one improvised from a blank prompt.
- 5
Step 5 — Keep it fresh
None of this is one-and-done. New reviews land hourly, so the poll-normalize-classify-embed loop runs forever, plus token refresh, retries, and dedup. That's the cost that outlives the fun part.
You now own an ETL system, not a feature
The model was the easy part. What you've actually signed up for is a two-store poller with two auth flows, a persistence layer to beat Google's 7-day window, a normalizer, a classifier, an embedding job, a vector store, and retry logic, all running 24/7 so the corpus stays current. That's fine if review data feeding a warehouse is core to your product. It's a lot of surface area if you just wanted an agent that could answer "what's driving the 1-stars this week."
The shortcut: hand the agent structured reviews, skip the glue
If the consumer of all this is an LLM or an agent, there's a path that skips the ETL. Instead of you building the poller, the normalizer, and the vector store, a Model Context Protocol server exposes reviews to your agent as callable tools, already normalized across both stores and clustered into themes.
That's what the [ReplyArgus MCP connector](/blog/app-reviews-mcp) does. ReplyArgus already watches your App Store and Google Play reviews in one inbox, classifies them, and groups recurring complaints into a roadmap board, so the structure you'd compute in steps 1 through 4 is done. The connector hands your agent tools like `list_reviews` and `search_reviews` (the live cross-store feed, filtered by rating, status, language, or keyword), `theme_breakdown` and `analytics_overview` (ranked themes with counts, not raw text), and `draft_reply` (a reply grounded in your approved history, in the reviewer's own language). No JWT minting, no 7-day-window bookkeeping, no embedding job to maintain. You ask in plain language and get structured answers back.
# Two asks an agent can run over the MCP feed — no ETL underneath
"Pull every 1- and 2-star review for [APP] across both
stores from the last 30 days, cluster them by theme,
and return the top 5 themes with counts and three
representative quotes each, as JSON."
"Give me a normalized feed of new reviews since yesterday:
rating, language, territory, text, and the theme you
assigned. Draft a reply to each in its own language,
keep Play replies under 350 chars, and queue them —
do not publish."And because publishing is gated, the round-trip is safe by default. A reply the agent drafts lands in your approval queue, not on the store, unless you deliberately set a rule for it. Here's the kind of grounded draft that comes out of a themed feed rather than a blank prompt:
Sync broke after the last update. My workouts from the watch don't show up on the phone anymore and I've lost three days of data.
Losing three days of logged workouts is exactly the kind of thing that shouldn't happen, and we're sorry. The 4.2 update introduced a watch-to-phone sync bug we've now identified, and a fix is in review. If you open Settings and tap Force Sync, the missing sessions should reappear; if they don't, email us and we'll recover them from the backup.
That reply is specific because the agent had the review, its theme, and your prior replies in context — the same things a hand-built RAG stack assembles. The [AI agent for app reviews](/blog/ai-agent-for-app-reviews) walks through the full capability list once reviews sit behind a tool call.
So: raw API or MCP?
Both are legitimate. Build directly on the App Store Connect and Play Developer APIs when review data has to land in your own warehouse for BI, product analytics, or an ML system you own end to end. You pay the ETL tax, but the raw feed stays under your control. That's the right call when reviews are a first-class dataset in your stack.
Reach for the MCP path when the consumer is an agent or an LLM assistant and you want reviews, themes, and grounded drafting without owning the pipeline. You skip the auth juggling, the 7-day window, normalization, and the embedding job, and you get the write path (approve-by-default publishing) in the same connector. Plenty of teams do both: warehouse the raw data for analytics, point the agent at the MCP feed for reading and answering.
Frequently asked
- Is there a single API for both App Store and Google Play reviews?
- No. Apple exposes reviews through the App Store Connect API's customerReviews endpoint, and Google exposes them through the Play Developer API's reviews.list method. They use different auth, different field names, and different time windows, so any unified feed is something you build (or get from a tool that already merged them).
- What does the Google Play reviews API actually return?
- reviews.list returns reviews for your app package — star rating, comment text, language, device info, and any existing developer reply thread — but only from roughly the past week. To keep a full history you must poll continuously and store each page yourself, because older reviews drop out of the feed and can't be backfilled.
- How do I authenticate to the App Store Connect reviews API?
- You sign a short-lived ES256 JSON Web Token with a private key (.p8) generated in App Store Connect, including your key ID and issuer ID in the header and claims. The token expires within 20 minutes, so a long-running pipeline mints fresh tokens on a schedule rather than reusing one.
- Can I get app reviews as embeddings, themes, or sentiment from the API?
- No. Both APIs return plain text and metadata. Classification, sentiment, clustering into themes, chunking, and embeddings are all steps you add after the JSON arrives. A reviews MCP server like ReplyArgus is different: it exposes reviews already normalized and clustered into themes, so the agent gets structure instead of raw text.
- What's the difference between the review APIs and an MCP server for reviews?
- The store APIs are raw HTTP feeds you integrate, authenticate against, and transform yourself. An MCP server wraps reviews as tools your AI agent calls directly — list, search, theme breakdown, draft — with the normalization and clustering already done. Use the raw APIs to own the dataset; use MCP to give an agent structured reviews without building the pipeline.
- Can an AI agent reply to reviews through this data, not just read it?
- Yes, but safely. Through the ReplyArgus MCP connector an agent can draft replies grounded in your past approved replies and publish approved ones, while publishing stays approve-by-default — drafts land in a queue unless you set an explicit auto-publish rule by rating, keyword, or language. Reading and writing are separate, gated tools.
If your goal is a warehouse of review data, build on the store APIs and budget for the ETL. It's real work, but it's yours. If your goal is an agent that reads and answers reviews, you can skip the poller, the two auth flows, and the vector store. [Explore the agentic tools](/agentic-tools) to see the MCP connector and its tool list, or [start free, no card](/signup) — connect a store, point your agent at the endpoint, and ask it to cluster your reviews or draft its first reply in minutes.
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
Manage Your App Store Reviews From Claude: The 5-Minute MCP Setup
Connect one MCP server and run your App Store + Google Play review queue from a Claude chat: summarize complaints, draft grounded replies, queue for approval.
Read moreThe MCP Server for App Reviews: Connect Your AI Agent to Your Store Reviews
An app reviews MCP server hands your live App Store and Google Play reviews to Claude, ChatGPT, or Cursor as callable tools. Here's what it exposes and how to wire it up.
Read more