Monitoring App Store and Google Play reviews with n8n and AI

A one-star review mentioning a crash on launch, posted on the Play Store on a Friday evening, can stay invisible until Monday morning — long enough that it has already shaped that week's download decisions before anyone on the product team even knows a critical bug is circulating. Unlike Google Business Profile or Trustpilot reviews, where a collection-and-alert pipeline is a well-trodden n8n use case, App Store and Google Play reviews remain a blind spot: no native node covers them, and most teams settle for checking the average rating once a month in the developer console.

Why these reviews deserve special treatment

A mobile app review isn't quite like any other customer review. It arrives at the exact moment the user is most likely to act: they're still holding the phone, the app is still open, and their frustration (or satisfaction) is fresh. The foundational study by Dennis Pagano and Walid Maalej, User Feedback in the AppStore: An Empirical Study (IEEE RE, 2013), shows on a large corpus of reviews that feedback volume spikes sharply in the days following a new release, then drops off fast — a short window during which a release bug reports itself en masse before getting lost in the noise. A second study, Bin Fu and coauthors, Why People Hate Your App: Making Sense of User Feedback in a Mobile App Store (KDD, 2013), goes further: it shows that a significant share of negative reviews clusters around recurring, identifiable themes (crashes, battery drain, intrusive ads) rather than scattering at random — which is exactly what makes automated classification useful for prioritizing fixes.

In practice, a monitoring pipeline changes two things: how fast a critical release bug gets detected, and visibility into trends that no occasional glance at the average rating would ever reveal.

Two stores, two APIs, no native node

n8n offers neither an App Store node nor a Google Play node: both are integrated exclusively through the HTTP Request node, each with its own access logic.

Collecting iOS reviews via the public RSS feed

Apple exposes a public, unauthenticated RSS feed for recent reviews of any published app:

https://itunes.apple.com/us/rss/customerreviews/id=<APP_ID>/sortBy=mostRecent/json

A plain HTTP Request node with a GET on this URL, triggered by a Schedule Trigger every few hours, is enough to pull the latest reviews in JSON. Two limits to know before building on top of it: the feed caps out at roughly 500 recent reviews per app, and it only includes reviews that carry text — a plain star rating with no comment never shows up. For ongoing monitoring (as opposed to rebuilding a full history), neither limit matters much as long as the pipeline runs at least daily.

For a deeper integration on your own app (replying to reviews, reaching further back into history), the App Store Connect API exposes a dedicated customerReviews endpoint, but its JWT-based authentication (ES256 key, Key ID, Issuer ID) is considerably heavier to set up than a simple RSS call — worth it mainly for teams that already need that API for other purposes (build management, TestFlight).

Collecting Android reviews via the Google Play Developer API

On Android there's no equivalent public feed: you have to go through the reviews.list method of the Android Publisher API (Google Play Developer API):

GET https://androidpublisher.googleapis.com/androidpublisher/v3/applications/<PACKAGE_NAME>/reviews

Authentication follows the same pattern as Google Cloud Storage in n8n: a service account created in the Google Cloud console, whose JSON file (client_email + private_key) feeds a generic Google API credential on the HTTP Request node, with the https://www.googleapis.com/auth/androidpublisher scope. One extra step, specific to Google Play, is easy to miss: that service account must then be invited into the Play Console (Users and permissions), with at minimum the "View app information and download bulk reports" permission for read-only access to reviews.

Two structural limits of this API to plan for from the start: it only returns reviews from the past week, on a rolling basis, and only those that include a comment — a bare star rating with no text stays invisible. Polling at least weekly (ideally daily) is therefore essential to avoid losing anything, with every review archived the moment it first appears.

Normalizing and deduplicating in Supabase

The two sources return different shapes (nested XML/JSON on Apple's side, comments objects on Google's). A Set (Edit Fields) node normalizes each review into a shared schema before inserting it into a Supabase table: store (ios/android), review_id, rating, text, language, app_version, published_at, collected_at. A Postgres node with a uniqueness constraint on (store, review_id) prevents duplicates when the same review comes back on every scheduled run — the same deduplication principle used in our competitive monitoring pipeline.

Classifying every review with AI

A raw review doesn't by itself say whether it deserves an immediate reaction. An AI call with a Structured Output Parser turns the text into an actionable signal:

{
  "category": "bug_crash",
  "severity": 4,
  "version_mentioned": "4.2.1",
  "summary": "The app crashes on launch since the latest update on Android 14.",
  "suggested_action": "investigate_urgently"
}

The prompt should distinguish at least four categories: bug_crash, feature_request, positive_review, and spam_offtopic — following the same constrained-classification pattern as our Sentiment Analysis node guide. A one-star review that just says "terrible" with no technical detail doesn't carry the same actionable weight as a two-star review that precisely describes a crash sequence: the severity field should reflect that difference, not simply mirror the star rating the user left.

Routing: immediate alert or weekly digest

A Switch node splits reviews by urgency, following the same pattern as our brand mention monitoring pipeline:

• bug_crash category with severity ≥ 4 → immediate Slack alert to the product channel, with the summary, the version mentioned, and a direct link to the review.
• Everything else → simply logged to Supabase, aggregated into a weekly digest sent Monday morning: review count by category, top recurring keywords in negative reviews, average rating trend by version.

For cases where a public reply makes sense (a clearly identifiable user whose issue has since been fixed), the model can draft a reply shown in Slack for validation — never published directly. On mobile stores even more than elsewhere, a badly calibrated reply stays visible under the review indefinitely. For ambiguous cases, a human approval flow with Slack buttons pauses the workflow until explicit validation.

Securing access

The Google Play service account should carry only the read-only androidpublisher scope — there's no reason to grant it reply permissions if the workflow is only monitoring reviews. Our API credential security guide covers how to restrict scopes to the strict minimum and rotate keys regularly. Apple's RSS feed needs no credential at all — but it's still a standard external HTTP call, worth protecting with the same retry and timeout practices covered in our HTTP Request guide in case the feed becomes briefly unavailable.

Common pitfalls

• Confusing star rating with severity: a one-star review with no technical detail doesn't deserve the same reaction as a two-star review describing a reproducible crash — let the AI prompt decide based on content, not the rating alone.
• Forgetting locale coverage: Apple's RSS feed is split by country (/us/, /fr/…); without looping over every targeted market, a chunk of international reviews goes unnoticed.
• Polling Google Play too rarely: past a week without a run, the API's rolling window drops reviews that were never archived — a weekly cron is a strict minimum, not a nice-to-have.
• Publishing a generated reply without review: on a channel as visible as an app's store listing, the mistake stays displayed indefinitely in front of future users.

Extending monitoring to brand mentions on the web

The same pipeline (collection, deduplication, AI classification, routing) applies to mentions outside the stores: press, blogs, forums.

• Sources: Google Alerts is free but detects with a delay of a few hours to several days and misses poorly indexed forums. A periodic search through Firecrawl's Search operation shortens that delay, for a few credits per query.
• False positives: before sentiment scoring, a first LLM call answers only yes or no to "is this text really about brand X in sector Y?". It is more reliable than keyword filtering when the brand name is also a common word or another company's name.
• Responding: the LLM can prepare a draft, but nothing is published automatically on a public channel; human approval remains mandatory.
• Cost: with a small model, filtering and scoring cost a fraction of a cent per mention, i.e. a few cents to one euro a month for a few dozen mentions a day.

Going further

This monitoring pipeline directly reuses the classification-and-Slack-alert mechanics of the AI Inbox Pack (€79): the AI triage and daily digest it sets up for a mailbox adapt almost unchanged to a stream of mobile reviews. Once the history builds up in Supabase, the RAG Assistant Pack (€119) takes it further by making that history queryable in natural language — "why did version 4.2 generate so many complaints?" — instead of leaving it as a plain archive to read line by line.