build.allanninal.dev

Part 2 of 7 · Review responder series ~4 min read

How a review reaches the responder

Reviews don’t arrive at your business through one door. Google sends an instant notification. Facebook used to push too, but Meta deprecated that webhook in early 2025 — in 2026 you reach Facebook reviews through a third-party aggregator instead. Yelp doesn’t tell you at all — you have to ask. The intake’s job is to fold those three different mechanisms into one queue, drop duplicates, and screen out junk before any AI sees a single word.

Key takeaways

  • Google Business Profile pushes via Pub/Sub the moment a review lands; the cloud receives the notification and fetches the full review by ID.
  • Meta deprecated the Facebook recommendations webhook in January 2025; in 2026 the Facebook lane runs through a third-party aggregator (Birdeye, Yext, ReviewTrackers).
  • Yelp has no push for SMBs, so the cloud polls the Fusion endpoint hourly — well inside the 500-call free daily tier.
  • Reply APIs differ: Google supports public posting; Facebook and Yelp are draft-only in 2026.
  • One Lambda per lane normalizes into a common shape, dedupes by review ID, and runs cheap in-Lambda screens for spam before any AI runs.

Three lanes at the door

Three intake lanes funnel into one queue A diagram with three vertical lane columns at the top and a single unified row at the bottom. Lane one, Google Business Profile: a new review on the listing triggers a Pub/Sub push notification; the cloud receives it, fetches the full review by ID, and emits a normalized record. Lane two, Facebook recommendations: Meta deprecated their own page recommendations webhook in January 2025, so the realistic Facebook lane in 2026 goes through a third-party aggregator (Birdeye, Yext, ReviewTrackers, or similar) that watches the page on your behalf and pushes normalized events; the cloud verifies the aggregator's signature and emits the same normalized record. Reply for Facebook is draft-only — the platform no longer offers a public reply API for recommendations. Lane three, Yelp and other platforms: no push is available to small-business owners, so the cloud polls the public Fusion endpoint on a schedule (every hour, well within the 500-calls-per-day free tier); diffs against the last-seen review ID, queues only what is new, and emits the same normalized record. Reply for Yelp is also draft-only since the Respond-to-Reviews API is enterprise-partner-gated. All three lanes write into one shared queue. Below them, a unified row labelled "Normalize, dedupe, screen" sits across the full width: normalize folds platform-specific shapes into one common review object; dedupe drops review IDs already in the queue (so webhook retries and double-fires are harmless); screen runs free in-Lambda filters for profanity floods, banned spam phrases, and same-author rate limits. An output arrow on the right reads "to responder, in one shape." A note at the bottom: cheap gates first — nothing reaches the AI until the platform-specific noise is stripped. Lane 1 · push Google Business Profile • New review on the listing • Push notification fires to the cloud • Cloud fetches the full review by ID • Emits a normalized record into the queue • Latency: seconds Lane 2 · push (aggregator) Facebook recommendations • Meta deprecated their webhook in Jan 2025 • Aggregator (Birdeye, Yext, …) pushes events • Cloud verifies the aggregator’s signature • Emits the same normalized record • Reply is draft-only Lane 3 · poll Yelp & other platforms • No push for SMBs • Cloud polls each listing on a schedule • Diffs against last- seen review ID • Yelp free tier: 500 calls/day • Reply is draft-only Normalize, dedupe, screen • Normalize: one shape across all sources • Dedupe: skip review IDs already seen (retries, double-fires) • Screen: profanity floods, banned-spam phrases, same-author rate limit → to responder, in one shape
Fig 2. Three lanes, one queue. Push when the platform offers it, poll when it doesn’t. Cheap filters first — nothing reaches the AI until the platform-specific noise is stripped.

Why three different mechanisms

The three platforms make very different choices about how to tell a business their listing got a review, and the intake mirrors those choices honestly instead of pretending they’re uniform.

Google pushes natively, and that’s the easy lane. When a review lands on a Google Business Profile, Google fires a notification through Pub/Sub at a URL the cloud is listening on, and the responder can have the review in hand within seconds. Google is also the only one of the three that offers a public reply API to a regular small-business owner, so this lane is fully two-way: read in, reply out, no human in the middle for the safe cases.

Facebook used to push too, but stopped. Meta deprecated the Page recommendations webhook in early 2025 (Graph API v22.0); the old ratings field no longer fires, and there’s no documented reply API for a recommendation. The realistic Facebook lane in 2026 goes through a third-party aggregator — Birdeye, Yext, ReviewTrackers, or whichever one the business already uses to monitor listings — that watches the page for you and forwards normalized events to a webhook URL you control. The shape of the lane is the same; the source of the push moved from Meta directly to whichever aggregator you connect. Replies on Facebook are draft-only: the responder writes the reply, the human pastes it into the Pages app.

Yelp doesn’t push, and its reply API is enterprise-only. The honest workaround is a polling job that wakes up on a schedule, asks Yelp’s public Fusion endpoint “anything new?”, and queues whatever it didn’t see last time. Yelp’s free tier is 500 calls per day, so hourly polling per listing is well inside the budget. The same polling pattern works for niche platforms (Tripadvisor, Healthgrades, OpenTable, BBB, the platform every industry has its own one of). The rare review that lands at 2:47pm gets processed at 3pm, which is still inside the same business hour for any practical reply. Yelp’s reply path is also draft-only for SMBs — the cloud writes the reply, the human pastes it into biz.yelp.com.

Push is faster, poll is more universal. Auto-reply works on Google today and is draft-only on Facebook and Yelp. Mixing all three in the same intake means the responder doesn’t care which platform a given review came from once it’s in the queue — the downstream code never branches on source, only on content. The auto-vs-draft difference is a single per-source flag the dispatch column reads at the very end.

What “normalize” actually means

Each platform hands the cloud a slightly different shape: Google gives a star rating from one to five and a free-text comment; Facebook offers a binary “recommends/doesn’t recommend” and a comment; Yelp gives a star rating, a comment, and sometimes a photo. Normalization folds those into one common review object — a source name, a stable review ID, a numeric score on the same one-to-five scale (binary recommendations map to 5 or 2 with a flag), the comment text, the author display name, the timestamp, and a small bag of platform-specific extras for the engineering reference.

The reason for putting normalization here, before anything else, is so the rest of the system reads exactly one kind of message. The responder doesn’t have to know what Yelp’s rating field is called; it just reads score and text.

Dedupe and screen, before any AI runs

Two free filters sit between the lanes and the responder.

Dedupe is a one-line check against a small table of review IDs the cloud has already processed. Webhooks retry; platforms occasionally fire the same event twice if their backend gets unsure; and the polling job, by design, asks the same questions on a loop. Without dedupe you’d pay to draft the same reply twice and then have to figure out which copy actually got posted. With it, the second arrival is dropped silently and metrics-only.

Screen handles the obvious junk — banned-words spam (the same crypto-pump comment posted to a thousand businesses), profanity floods (the same review re-posted under different names by an angry ex-employee), or same-author rate-limit hits (one reviewer posting twelve reviews in an hour). The screen runs in plain Lambda code with a small banned-words list and a frequency check; no AI involved. Reviews that fail the screen don’t reach the responder — they’re logged for you to inspect (and report to the platform) but they don’t cost a single model call.

The point of doing both before the AI runs is straightforward: token spend is the only line on the bill that grows fast, and most junk is identifiable without it. Free gates first, paid gates only when the message has already proved it’s a real review.

What this hands to the next post

By the time a review leaves the intake, it’s in one shape, with a stable ID, no duplicates, and no obvious spam. The next post is about what the responder does with that — how it actually reads the review, extracts what the customer is praising or complaining about, and starts to decide which of the four moves applies.

All posts