Building a Google Review Pipeline with the Business Profile API

You can build a working review pipeline on the Google Business Profile API with three pieces: a Pub/Sub subscription that tells you when a review arrives, a worker that fetches and stores the review, and a reply step that only posts after a human approves. Polling every location on a schedule works too, but notifications keep you inside quota and make alerts close to real time.

This post walks through the endpoints, a minimal Python worker, and the design choices that matter once you have hundreds of locations.

What do you need before you start?

• API access. The Business Profile APIs require an access request to Google before your project can call them.
• An OAuth client with the https://www.googleapis.com/auth/business.manage scope, authorized by an account that manages the locations.
• A Google Cloud Pub/Sub topic, if you want push notifications.
• Account and location IDs for the profiles you manage.

Which endpoints handle reviews?

Reviews still live on the v4 mybusiness.googleapis.com surface:

Action	Method and path
List reviews	GET /v4/accounts/{accountId}/locations/{locationId}/reviews
Get one review	GET /v4/accounts/{accountId}/locations/{locationId}/reviews/{reviewId}
Reply or edit a reply	PUT /v4/accounts/{accountId}/locations/{locationId}/reviews/{reviewId}/reply
Delete a reply	DELETE /v4/accounts/{accountId}/locations/{locationId}/reviews/{reviewId}/reply

The list call supports pageSize, pageToken, and orderBy, for example updateTime desc. Each review includes reviewId, reviewer, starRating as an enum from ONE to FIVE, comment, createTime, updateTime, and reviewReply if you already replied.

Check Google's current reference before you ship. This API family has been split and migrated over the years, and paths do change.

How do you get notified about new reviews?

Use the Business Profile Notifications API. You attach a Pub/Sub topic to the account and choose event types:

PATCH https://mybusinessnotifications.googleapis.com/v1/accounts/{accountId}/notificationSetting?updateMask=pubsubTopic,notificationTypes

{
  "name": "accounts/{accountId}/notificationSetting",
  "pubsubTopic": "projects/your-project/topics/gbp-events",
  "notificationTypes": ["NEW_REVIEW", "UPDATED_REVIEW"]
}

Grant publish rights on the topic to [e-mail], or Google cannot deliver messages to it.

Treat a notification as a hint, not the data. The message tells you which location and review changed. Your worker then fetches the review itself.

What does a minimal worker look like?

Here is a stripped-down Python worker. It fetches the review, upserts it, and flags low ratings for a human.

import requests

API = "https://mybusiness.googleapis.com/v4"
STARS = {"ONE": 1, "TWO": 2, "THREE": 3, "FOUR": 4, "FIVE": 5}

def fetch_review(token, review_name):
    # review_name looks like accounts/123/locations/456/reviews/abc
    r = requests.get(
        f"{API}/{review_name}",
        headers={"Authorization": f"Bearer {token}"},
        timeout=10,
    )
    r.raise_for_status()
    return r.json()

def handle_event(token, review_name, db, alerts):
    review = fetch_review(token, review_name)
    stars = STARS.get(review.get("starRating"), 0)

    db.upsert(
        key=review["name"],
        stars=stars,
        text=review.get("comment", ""),
        updated=review["updateTime"],
        replied="reviewReply" in review,
    )

    if stars <= 2 and "reviewReply" not in review:
        alerts.send(location=review_name.split("/reviews/")[0], stars=stars)

Key the store on the full review name. It is stable, and it makes the upsert idempotent when Pub/Sub delivers the same message twice, which it can.

How should replies work?

Draft automatically, publish manually. Use templates or a language model to draft a reply, store it as pending, and post only after someone approves it:

def post_reply(token, review_name, text):
    r = requests.put(
        f"{API}/{review_name}/reply",
        headers={"Authorization": f"Bearer {token}"},
        json={"comment": text},
        timeout=10,
    )
    r.raise_for_status()
    return r.json()

Replies are public and attached to your brand. An unreviewed automated reply to an angry customer is the kind of mistake that ends up in a screenshot.

What breaks at scale?

A few things, reliably:

• Quota. Backfilling hundreds of locations with list calls burns quota fast. Backfill once, slowly, then rely on notifications.
• Missed notifications. Run a nightly reconciliation that lists recent reviews per location and compares against your store.
• Token ownership. If the authorizing user leaves the company, your refresh token dies with their access. Authorize with an account the business controls.
• Edited reviews. Customers change ratings. Handle UPDATED_REVIEW and keep history if you report on it.

Should you build this or buy it?

Build it if reviews feed your own systems, such as a CRM or data warehouse, and you have engineers to maintain it. Buy if the goal is simply that someone replies well and on time.

On the buy side, the common options each have gaps. Birdeye has a broad suite but can be more than a team needs. Synup covers review monitoring, reply approvals, and scoped permissions, and it offers APIs so you can still pull data into your stack, though a full suite is overkill if reviews are your only use case. Podium ties requests to texting, which is great if you already text customers and less useful if you do not.

FAQ

Can I get reviews without API approval?

Not through the official API. Scraping Google Maps violates Google's terms and breaks often.

How far back can I fetch reviews?

The list endpoint pages through a location's reviews. Backfill once and store them yourself rather than refetching.

Can I reply to reviews on other platforms with this?

No. This covers Google only. Yelp, Facebook, and others have their own APIs and rules.

Should replies be written by AI?

Drafts, yes. Publishing, no. Keep a human approval step, especially for ratings of two stars or below.