Zapier and Make Recipes for App Reviews (and Where They Break)
No-code recipes to route App Store and Google Play reviews to Slack or Sheets in Zapier and Make — plus the honest limits that break them.
The Argus Team
Reply Argus
There is no native "new App Store review" trigger in Zapier or Make. Neither platform ships an App Store Connect or Google Play app that fires when a review lands, because neither store publishes a review event to fire on. So the recipes below don't listen for reviews; they go and ask for them on a schedule, then push what's new to Slack or a spreadsheet. That works, and it's genuinely useful for a small app. It also breaks in a few specific, predictable places, and it's better to know where before you wire it up than after a weekend of reviews goes missing.
This is the honest version: two working recipes you can build today, then the four limits — no trigger, polling cost, the API windows, and the 350-character reply cap — that decide whether a no-code Zap is enough or whether you've just rebuilt a worse review tool. The deeper reason the trigger doesn't exist lives in [why there's no webhook for new app reviews](/blog/no-webhook-for-new-app-reviews).
Why isn't there a Zapier trigger for App Store reviews?
Because a trigger needs something to trigger on, and the stores don't offer one. Apple's App Store Connect API and Google's Play Developer API both treat reviews as data you fetch, not events they push: no `subscribe` call, no callback to register, no Pub/Sub topic carrying review events. Zapier's "instant" triggers rely on the source app POSTing to a Zapier webhook the moment something happens, and since the stores never POST, there is nothing for an instant trigger to receive.
So every no-code review recipe is really a polling recipe wearing a trigger's clothes. You use Zapier's Schedule trigger (or Make's scenario scheduling) to run every few minutes, call the reviews endpoint with a Webhooks or HTTP step, and diff the result against last time. Zapier and Make are the glue and the schedule; the auth and the diffing are on you. Keep that model and the recipes below make sense, and their limits stop being surprises.
Recipe 1: Route new reviews to Slack (Zapier)
The most requested one, and the most useful: a 1-star hits Slack the moment your Zap catches it, so someone actually sees it. Here's the shape that holds up, using Zapier's Schedule trigger plus a Code or Webhooks step to hit the store API. (If you want to run the whole reply from the channel, not just the alert, see [replying to app reviews from Slack](/blog/reply-to-app-reviews-from-slack).)
- 1
Step 1 — Trigger: Schedule by Zapier
Set the Zap to run every hour, or on the shortest interval your plan allows. Zapier's polling cadence is plan-dependent (lower tiers check less often, higher tiers more), so this interval, not the store, is what caps how fast a review reaches Slack. There is no "on new review" option, only "every N minutes."
- 2
Step 2 — Fetch reviews with a Code step
For Google Play you mint an OAuth token from a service account and GET reviews.list; for Apple you sign a short-lived ES256 JWT with your .p8 key and GET customerReviews. A Zapier Code (JavaScript/Python) step is the realistic place to do the signing. A plain Webhooks step can't mint the token for you.
- 3
Step 3 — Filter to only what's new
The endpoint returns overlapping results every run, so you must dedup. Use Zapier Storage to remember review ids you've already posted, and a Filter step to stop the Zap unless the id is unseen. Skip this and Slack gets the same review every hour.
- 4
Step 4 — Send Channel Message in Slack
Format the message: stars, nickname, country, review body, and a deep link to the review so a human can reply in two clicks. Route 1- and 2-star reviews to an #urgent channel and the rest to a quieter one with a second Filter.
# The call your Code/Webhooks step makes each scheduled run
# Google Play — reviews.list (surfaces ~the last 7 days only)
GET https://androidpublisher.googleapis.com/androidpublisher/v3/
applications/{PACKAGE_NAME}/reviews?maxResults=100
Authorization: Bearer <OAuth2 token minted from a service account>
# Apple — App Store Connect customerReviews (historical, paginated)
GET https://api.appstoreconnect.apple.com/v1/apps/{APP_ID}/customerReviews
?sort=-createdDate&limit=200
Authorization: Bearer <ES256 JWT you sign per run, expires <= 20m>Recipe 2: Log every review to a Google Sheet (Make)
Make (formerly Integromat) fits better when you want a durable log rather than a ping, because its visual scenarios make the fetch-then-iterate-then-append loop easier to see. The goal: one row per review in a Sheet you can pivot, filter, and hand to whoever owns support.
- 1
Step 1 — Schedule the scenario
Set the scenario to run on an interval (Make lets you go as tight as every minute on paid plans; every 15 minutes is plenty for most apps). Same truth as Zapier: the schedule is the trigger, because there's no review event to hook.
- 2
Step 2 — HTTP module + Iterator
Use the HTTP module to call the reviews endpoint with your bearer token, then an Iterator to split the response into one bundle per review. Make's OAuth2 support handles Google's service-account token gracefully; Apple's JWT signing still needs custom work in a function or a pre-signed token you refresh.
- 3
Step 3 — Search rows to dedup
Before appending, run a Google Sheets 'Search Rows' on the review id and only continue if it returns nothing. Without it, every run re-appends the same rolling window and your Sheet fills with duplicates fast.
- 4
Step 4 — Add a row
Append id, store, stars, language, country, review text, and created date, plus a reply-link column you fill by hand. Now you have a searchable log, but notice it's a log, not a workflow. Nothing here drafts or sends a reply.
Both recipes stop at 'notify' on purpose
A Zap or scenario can carry a review to Slack or a Sheet, but it can't write a good reply for you, and it can't safely publish one back to the store without you hand-building the reply API call, the auth, and the character-limit handling inside a Code step. These recipes solve visibility. The reply, the part that actually moves your rating, is still a human opening a console.
Where these recipes break
None of these are dealbreakers for a hobby app with a handful of reviews a week. At real volume, or across more than one app, each one turns into maintenance you didn't sign up for.
- No native trigger, so you own the poller — a Schedule step plus a Code step doing JWT signing and OAuth token minting is not really no-code. When Apple rotates a key or Google's token expires, the Zap fails silently, and you find out when someone asks why Slack went quiet.
- Polling burns tasks/operations — a Zap that runs every 15 minutes fires ~2,880 times a month whether or not a review came in. On usage-metered plans you pay for the empty checks, and tighter polling multiplies the bill.
- Google only returns ~the last 7 days — reviews.list surfaces roughly the past week. If your scenario is paused, over quota, or erroring for a weekend, that weekend's reviews are gone from the feed and can't be backfilled.
- The 350-character reply cap is yours to enforce — Google Play hard-caps developer replies at 350 characters. Extend a recipe to post replies and your Code step has to truncate or reject over-length text, or the API rejects the call. Fitting a real answer in that budget is its own skill — see [how to write a 350-character review reply](/blog/write-a-350-character-review-reply).
- Apple's reply limit is undocumented — Apple publishes no official character limit; community testing suggests a few thousand characters. A recipe handling both stores can't rely on one number, so you're guessing on one side.
- Two schemas, forever — Apple's fields and Google's fields never line up, so anything claiming to handle "all my reviews" is a normalization layer you build in a Code step and maintain on both sides as the APIs drift.
A quiet Zap is worse than no Zap
The failure mode that hurts most isn't a loud error. It's a scenario that stops fetching and doesn't tell you. Because Google's window is only ~7 days, silent downtime doesn't degrade your review data, it deletes it. If you build the no-code path, add a heartbeat: a separate alert that fires when the Zap hasn't run, so you catch a gap in minutes instead of finding a hole in your history a week later.
The shortcut: watch, draft, and alert without the plumbing
If the whole reason you're reaching for Zapier is "tell me when a review lands so I can reply fast," you can skip the poller entirely. [ReplyArgus](/features) already runs the fetch-dedup-persist loop for both the App Store and Google Play — correct cadence per store, both auth flows handled, every review saved so Google's 7-day window never eats your history. That's steps one through four of both recipes, run for you, with the monitoring a hand-built Zap almost never gets.
And it does the two things a Zap structurally can't. It drafts an on-brand reply in the reviewer's own language the moment the review is detected, grounded in your past approved replies and store listing, already inside the 350-character cap where the store requires it. And it fans the alert out to Slack, Discord, Telegram, email, or an outbound webhook — the same destinations your recipe was reaching for, minus the Code step (full list on the [integrations page](/integrations)). Speed is the point: since Google I/O 2019 both stores weight recent reviews more heavily and Google reported developers who respond see an average +0.7 stars, so the gap between "caught in an hour with a reply ready" and "caught Monday" is real rating — which is why [how fast you reply](/blog/how-fast-should-you-reply-to-app-reviews) matters as much as whether you reply.
Update broke Face ID login. Have to type my password every single time now. Super annoying.
Typing your password on every open is exactly the friction Face ID is supposed to remove, so we get why this is grating. We found the bug in the last build's auth flow and the fix is already in review. Update once it ships this week and Face ID should stick again. If it doesn't, reply here and we'll look at your setup directly.
That reply landed while the review still mattered, because an alert reached a person with a draft already waiting, instead of sitting in row 412 of a spreadsheet nobody opened. If your team lives in an assistant, there's an even lower-code path: ReplyArgus exposes reviews through an [MCP connector](/agentic-tools), so you can ask Claude or ChatGPT "any new 1-stars in the last hour?" against the live cross-store feed — no scenario to build, no token to refresh.
Frequently asked
- Does Zapier have an App Store or Google Play reviews trigger?
- No. Neither Zapier nor Make offers a native trigger that fires on a new App Store or Google Play review, because neither store publishes a review event. You build the equivalent with a Schedule trigger that runs on an interval plus a Code or HTTP step that calls the store's reviews API and diffs the results against what you've already seen.
- How do I connect App Store reviews to Slack with Zapier?
- Use Zapier's Schedule by Zapier trigger to run on an interval, a Code step to sign an ES256 JWT (Apple) or mint an OAuth token (Google) and fetch reviews, a Filter step to dedup on the review id via Zapier Storage, then a Slack Send Channel Message action. It works, but you own the auth and the dedup — or a purpose-built tool like ReplyArgus posts new reviews to Slack with no Zap.
- How often can Zapier or Make check for new reviews?
- As often as your plan's polling interval allows — lower tiers check less frequently, higher tiers more. That interval, not the store, sets how fast a review reaches you. Tighter polling catches reviews faster but burns more tasks/operations, since the Zap fires on every scheduled run whether a review arrived or not.
- Can Zapier post a reply back to an app review?
- Only if you hand-build it. There's no native 'reply to review' action, so you'd POST to Google's reviews.reply or Apple's customerReviewResponses endpoint from a Code step, handle the auth, and enforce Google Play's hard 350-character limit yourself. Most teams use Zapier only to notify, and reply from the console or a dedicated tool.
- What's the character limit on an app review reply?
- Google Play hard-caps developer replies at 350 characters. Apple publishes no official limit; community testing suggests a few thousand characters, so treat it as generous but unstated. Any recipe that posts replies must enforce Google's 350-character cap in code or the API rejects the response.
- Is a Zapier recipe or a dedicated review tool better?
- A Zap is fine for one small app where you just want a Slack ping and don't mind maintaining the auth and dedup yourself. Across multiple apps, at volume, or if you want AI-drafted replies in the reviewer's language and reliable persistence past Google's 7-day window, a purpose-built tool removes the plumbing the no-code path only hides.
Build the Zap if you want to learn the APIs and own the pipe. For one app it's enough. If what you actually want is every review the moment it lands, in the channel your team already uses, with a reply drafted in the reviewer's language waiting for a thumbs-up, skip the schedule step and the JWT signing. [Start free — no card](/signup): connect your App Store and Google Play apps and Argus watches both stores, alerts your team, and has the reply ready before the reviewer moves on.
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