There's No Webhook for New App Reviews — Here Are the Alternatives
Neither Apple nor Google POSTs to your endpoint when a review lands. So you poll. Here are the polling patterns, the quotas that bite, and the shortcut.
The Argus Team
Reply Argus
Neither Apple nor Google will POST to your server when a new review lands. There is no review webhook. You can subscribe an App Store Connect account to email notifications, and the Play Console can email you too, but there is no programmatic push event you can register a callback for. If you want new reviews in your own system the moment they appear, you poll: you call the store APIs on a schedule and diff the results against what you already have.
That one missing feature is why review-monitoring integrations are more work than they look. Below: why the webhook doesn't exist, the polling patterns that hold up in production, the quota and time-window traps that quietly lose reviews, and where a service that runs the poller for you hands you the outbound webhook the stores never gave you.
Why isn't there a webhook for new app reviews?
Both stores treat reviews as data you fetch, not events they broadcast. Apple's feed is the App Store Connect API: the `customerReviews` endpoint returns a paginated, historical list: rating, title, body, reviewer nickname, created date, and territory. Google's is the Play Developer API: `reviews.list` returns reviews for one app package — star rating, comment text, language, device metadata, and any developer-reply thread.
Neither has a `subscribe` call. Google runs real-time developer notifications through Cloud Pub/Sub, but those cover subscription and purchase lifecycle events, not reviews. Pointing a Pub/Sub topic at your reviews is not an option because the store never publishes to it. So the only programmatic way to know a review exists is to ask, repeatedly. If you want the field-by-field response shapes, the [Google Play reviews API reference](/blog/google-play-reviews-api-reference) and the [App Store Connect reviews API reference](/blog/app-store-connect-reviews-api-reference) map each object. A bare poll 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 (surfaces roughly 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 polling patterns that actually work
A poller is not a single loop that hits an endpoint. To catch every review once, exactly once, without hammering the API, you need four moving parts. This is the shape most teams converge on after the naive version starts dropping reviews.
- 1
Step 1 — Pick an interval per store
Apple's feed is historical, so you can poll it gently — every 15 to 30 minutes catches new reviews without stressing the quota. Google is the opposite: because its window is short, you poll more often and never let a gap open. A cron every 5 to 15 minutes per Google package is a reasonable floor; slower than that and you risk the window closing on a review before you fetch it.
- 2
Step 2 — Dedup on a stable key
Each poll returns overlapping results, so store each review's store-assigned id and only act on ids you haven't seen. Never key off text or timestamp alone — a reviewer can edit a review, and an edit changes the body while keeping the id, which is exactly the signal you want to catch, not suppress.
- 3
Step 3 — Persist every page immediately
Write each page to your own store the moment it lands, before any processing. This is the single defense against Google's 7-day window: your history is something you accumulate poll by poll, not something you can ask for later. If your persistence lags your fetch, a crash between the two loses the reviews you just pulled.
- 4
Step 4 — Back off and retry
Both APIs throttle and both fail transiently. Wrap calls in exponential backoff on 429 and 5xx, mint a fresh Apple JWT before each run (they expire inside 20 minutes), and refresh the Google OAuth token on schedule. A poller without retry logic doesn't lose reviews loudly; it loses them silently during the hour the API was grumpy.
- Google only returns ~the last week — `reviews.list` surfaces reviews from roughly the past seven days. Miss that window and the review is gone from the feed and cannot be backfilled. If your poller is down for a weekend, that weekend's reviews are permanently invisible to your system.
- Apple auth expires every 20 minutes — you sign a short-lived ES256 JWT yourself with a `.p8` key, so a long-running poller mints tokens continuously rather than pasting one API key once.
- Google needs a service account — an OAuth2 token from a service account linked in the Play Console, with the right permission grant. Not a key you configure in five minutes.
- Quotas apply to both — at the volume of an app with thousands of monthly reviews across two stores, and especially across many apps, you'll hit rate limits and need per-app scheduling, not one tight loop.
- Two schemas, forever — Apple's fields and Google's fields never line up, so anything that reads "all my reviews" is a normalization layer you build and maintain on both sides.
The 7-day window is the trap that bites hardest
Google's rolling window turns your poller from a convenience into a system of record. It is the only place those reviews will ever appear programmatically, for about a week. Downtime doesn't degrade your data gracefully; it deletes it. That's why a review integration you own needs monitoring, alerting, and a persistence layer that's more reliable than the app it watches. A cron that fails quietly is worse than no cron, because you'll believe you have every review.
Why teams miss reviews anyway
Even with a correct poller, reviews slip through for reasons that have nothing to do with code. A 1-star lands Friday night; the person who'd reply doesn't see it until Monday, by which point another shopper has read it at the top of your listing and bounced. Or the poller runs, the data lands in a database, and nobody is watching that database — reviews captured, but not routed to a human who can act.
Speed matters more than it seems. Since Google I/O 2019, both stores weight recent reviews more heavily in the score a shopper sees, and Google reported that developers who respond to reviews see an average +0.7 stars on their rating. A review you catch in an hour and reply to thoughtfully is worth more than the same review caught a week later. The math of a [recency-weighted rating](/blog/recent-reviews-weigh-more) rewards the fast reply, and your overall [review velocity](/blog/review-velocity) is part of what the ranking sees. Fetching the review is only half the job; the other half is a human seeing it in time to act. A here-is-the-JSON pipeline solves the first half and leaves the second wide open.
Latest update logs me out every few minutes. Can't even stay signed in long enough to finish a task. Deleting.
Getting kicked out mid-task is infuriating, and you're right to be annoyed. We traced it to a session-token bug in the last release and a fix is already in review. If you can hold off on deleting, update once the patch lands this week and it'll stop. If it keeps happening after that, reply here and we'll dig into your specific account.
That reply works because someone saw the review while it still mattered. The difference between a caught review and a missed one is rarely the API — it's whether an alert reached a person before the reviewer moved on.
The shortcut: let something else run the poller and give you the webhook
If the reason you want a webhook is "tell me the instant a review lands so I can act," you don't need to build the poller at all. [ReplyArgus](/features) already polls both the App Store Connect and Play Developer APIs on the right cadence per store, handles both auth flows, dedups, and persists every review so Google's 7-day window never eats your history. That's steps one through four, plus the normalization layer, run for you.
And it closes the gap the stores left open: the stores won't POST to you, but ReplyArgus will. New reviews fan out to Slack, Discord, Telegram, an outbound webhook, or email the moment they're detected, so your team sees a 1-star in the channel it lives in, and your own systems can subscribe to the webhook you always wanted. You get the event stream the stores don't publish, without owning a single line of polling code. The full list of destinations lives on the [integrations page](/integrations).
The webhook you wished the stores had
Point ReplyArgus at your App Store and Google Play apps and it becomes the poller-plus-webhook layer: it fetches on schedule and fires an outbound POST (or a Slack/Telegram/Discord ping) on every new review. Add an AI-drafted reply in the reviewer's own language waiting in the queue, and the alert isn't just "a review came in," it's "here's a reply ready to send."
There's an even lower-code path if your team lives in an assistant. Because ReplyArgus exposes reviews through an [MCP connector](/agentic-tools), you can ask Claude or ChatGPT "any new 1-stars in the last hour?" and get an answer from the live cross-store feed — no endpoint to stand up, no webhook to receive. The polling, the two auth rituals, and the 7-day bookkeeping all sit behind the tool call.
Frequently asked
- Is there a webhook for new App Store or Google Play reviews?
- No. Neither Apple's App Store Connect API nor Google's Play Developer API offers a webhook or push event for new reviews. The only programmatic way to detect a new review is to poll the reviews endpoint on a schedule and diff the results against what you've already stored. Both stores can send email notifications, but there is no callback you can register.
- How do I get notified when someone leaves a new review?
- Three options. Enable the store's built-in email notifications (App Store Connect and Play Console both offer this, but they don't route or scale well). Build a poller that calls the reviews APIs on a cron and fires your own alert. Or use a tool that already polls and pushes to Slack, Telegram, Discord, or an outbound webhook — see how to [get notified of new App Store reviews](/blog/get-notified-of-new-app-store-reviews).
- How often should I poll for new reviews?
- Poll Google more often than Apple. Because Google's reviews.list only returns roughly the last seven days, poll each package every 5 to 15 minutes and never let a gap open, or you'll lose reviews permanently. Apple's feed is historical, so every 15 to 30 minutes is fine. Always dedup on the store-assigned review id and persist every page immediately.
- Why do I keep missing reviews even though my poller runs?
- Usually one of two things. Google's 7-day window means any downtime permanently loses that week's reviews, since they can't be backfilled, so a poller that fails quietly loses data silently. Or the reviews are captured to a database nobody watches, so no human acts in time. Both are solved by reliable persistence plus an alert that reaches a person.
- Can I use Google Pub/Sub to get review events?
- No. Google Cloud Pub/Sub real-time developer notifications cover subscription and in-app-purchase lifecycle events, not reviews. The store never publishes review events to a Pub/Sub topic, so there's nothing to subscribe to. Reviews remain a poll-only feed on the Play Developer API's reviews.list method.
- Does ReplyArgus give me a webhook for new reviews?
- Yes. It runs the poller for both stores and fires outbound alerts on every new review via Slack, Discord, Telegram, email, or an HTTP webhook you point at your own system. It's the push event the stores don't provide, plus an AI-drafted reply waiting in the queue, so the notification arrives with a response ready to approve.
If reviews have to land in your own warehouse, build the poller and budget for the quotas, the 7-day window, and two auth flows. It's real work, but it's yours. If what you want is to know the instant a review appears and reply before it costs you a star, skip the plumbing. [Start free — no card](/signup): connect your App Store and Google Play apps, and Argus polls both stores, pings your channel on every new review, and has a reply drafted in the reviewer's language waiting for your approval.
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