A 120-location HVAC brand has no shortage of review activity. The problem is control. A five-star review lands on the wrong branch queue. A complaint waits behind routine praise. A central team approves a reply, but no one confirms that Google published it. The dashboard looks busy while the customer-facing record remains uncertain.
The Google Business Profile Reviews API can remove much of that manual retrieval work. An approved integration can collect reviews by location, retrieve reviews for multiple verified locations, publish or replace a reply, and delete the business's reply. In 2026, Google also added fields that make reply moderation and public readback easier to observe.
That does not turn the API into an automatic response machine. It turns review handling into an accountable queue.
Important
Treat each review as a location-bound public record. Retrieve centrally, route it to the operator who knows the job, require an authorized decision, and verify the reply after publication.
If your review operation still loses the connection between branch, employee, customer interaction, and public response, book a Cheers demo. The integration work only pays off when the operating record is reliable.
What the reviews API gives a multi-location team
Google documents methods to list all reviews for one verified location, get a specific review, retrieve reviews across multiple verified locations, update a reply, and delete a reply. The multi-location method accepts up to 50 location resource names per request and supports pagination and ordering.
For a 120-location portfolio, that means at least three location batches before review pagination. The exact number of API calls depends on review volume and page size. A sound job runner records the locations requested, page token, completion time, and failure state so one interrupted batch does not create a silent coverage gap.
The review resource contains the location's resource path, review ID, reviewer display information, star rating, comment, timestamps, and any business reply. Google added reviewReplyState in April 2026, policyViolation in July, and reviewReplyUrl later that month. Those fields matter because a request can leave the reply pending, rejected, or approved. A rejected reply may include a policy reason, while the reply URL gives the team a direct public readback path.
The API documentation also tells clients to handle future enum values. Do not write a workflow that treats every unfamiliar status as approved. Route an unknown state to an exception queue until the integration understands it.
Start with access and location identity
Business Profile API access is not open by default. Google requires an approved Google Cloud project, enabled Business Profile APIs, OAuth credentials, and user authorization through the business.manage scope. Google says there is no sandbox environment, so test work can affect real profiles.
The authenticated user must have access to the locations the integration requests. Before touching review data, build a canonical location crosswalk with the Google account, location resource name, Business Profile ID, Place ID, internal branch ID, brand, market, and accountable owner. Do not match a review to a branch from the display name alone.
The Business Profile access guide for multiple locations covers the owner, manager, business group, and agency structure behind that crosswalk. The API does not repair orphaned profiles or give an agency authority that the business has not granted.
Use one verified test location with low operational risk. Confirm list access, pagination, updateReply, deletion, and public readback before adding another market. Since there is no sandbox, a test reply should be a real, approved response to a real review, not placeholder text on a live profile.
Build an ingest and routing queue
Google's Notifications API can send Pub/Sub events when a new review arrives or an existing review changes. Notification settings are configured at the account level. The event carries the review and location resource names, which lets the worker fetch the current review rather than trusting a stale copy.
Notifications still need a scheduled catch-up job. A subscription can be misconfigured, paused, or delayed. Run a bounded reconciliation against the locations in the crosswalk and compare retrieved review resource names with completed workflow events.
For each item in the operating queue, capture only what the workflow needs:
- Identity: location resource name, review resource name, rating, and received or updated time
- Ownership: branch, regional owner, service line, and person responsible for the decision
- Risk: routine, factual question, service complaint, or sensitive escalation
- Decision: no reply, approved reply, or specialist review, with the authorized approver and time
- Readback: reply state, policy violation when returned, public reply URL, and final verification time
The queue key should be the Google review resource name plus the location mapping. Make writes idempotent so a repeated notification updates the same workflow item instead of publishing a second response.
The field record matters more than fluent copy. If a review says the technician replaced a compressor but the job record shows a capacitor repair, the reply owner should not repeat either claim until the location resolves the discrepancy.
Separate draft, consent, and publish
Google's Business Profile API policy draws a hard boundary around automated replies. A client may not automate or trigger review responses without the user's prior specific and express consent. General acceptance of software terms is not a substitute for approval of a public response.
Design three distinct states: draft created, authorized person approved, API publication attempted. Store who made the decision and which text they approved. If the draft changes after approval, send it back through approval rather than treating consent as permanent.
Routine praise can have a faster lane, but it still needs the consent model required by Google's policy. Complaints need the local incident owner. Reviews involving safety, discrimination, clinical outcomes, insurance, legal threats, employees, or personal information need a specialist lane.
The Gemini review reply workflow explains how to use AI for drafting without surrendering the local decision. The negative-review response guide covers fact checks and service recovery when the public reply is only one part of the work.
Google's updateReply method creates a reply when none exists and replaces the current reply when one does. That makes version control important. Show the approver the live reply before replacement, then read the review again after the write. A stale draft should never overwrite a newer response from the branch.
Next step
Is AI recommending your business?
Find out how visible you are across ChatGPT, Gemini, Perplexity, and AI Overviews.
Read the moderation result after the HTTP response
A successful API request proves that Google accepted the request. It does not prove that the reply is publicly visible and final.
After updateReply, retrieve the review again. Read the reply text, update time, reviewReplyState, and reviewReplyUrl. If the state is pending, keep the item open. If it is rejected, inspect policyViolation and route the response for correction. Google documents reasons such as prohibited content, advertising or solicitation, personal information, off-topic content, and account restrictions.
Do not automatically rewrite and retry a rejected reply until it passes. The right response may be to remove a solicitation, cut private details, investigate an account restriction, or decide not to reply. Repeated blind attempts hide the operating problem and can create a worse public record.
The public URL is the final check. Open it as a normal customer would and confirm the correct profile, review, and response. If the API state and public surface disagree, keep the exception open instead of reporting the reply as complete.
Keep private service facts out of the payload
Google's API policy limits how Business Profile content may be stored and used. It requires secure handling, restricts aggregation, and says temporary stored content must be refreshed or deleted within the allowed period. Build retention controls before saving raw review text in a warehouse or sending it to another model.
The public response has a separate privacy boundary. Google reminds businesses that replies are public and recommends keeping them useful, polite, and concise. The customer may mention an address, medical treatment, insurance loss, employee allegation, or access condition. The business should not confirm that detail merely because it appeared in the review.
A hotel manager can acknowledge that the stay fell short and offer a direct resolution path without confirming room number, dates, companion details, or a payment dispute. A restoration company can do the same with a property loss. The workflow should preserve the internal case while exposing only the minimum useful public response.
Use the review compliance playbook to separate response governance from review collection rules, incentives, employee reviews, and suppression risk.
Measure the queue without inventing a ranking claim
The reviews API is an operating tool, not a documented ranking tactic. Google says reviews and positive ratings can help local ranking, but it does not say an API integration or individual owner reply provides a direct boost.
Measure the system on controls it can actually improve: retrieval coverage by active location, time to an authorized decision, wrong-location assignments, sensitive-review escalations, stale-draft conflicts, rejected replies, and failed public readbacks. Keep customer-resolution measures in the service system that owns them.
Review generation is a separate job. The API described here manages review data and business replies after reviews exist. It does not replace a frontline program that asks eligible customers at the right moment, attributes the interaction to the employee, and gives leadership a location-level view of participation.
Roll out the integration in four weeks
The following schedule is a Cheers operating recommendation, not a Google requirement:
- Week 1, identity and access: approve one production project, connect one accountable user, map ten verified locations, and prove read-only retrieval and pagination
- Week 2, routing: connect new and updated review notifications, add the scheduled catch-up, assign risk lanes, and measure location coverage without publishing
- Week 3, controlled replies: require express approval, publish a small set of routine responses, test replacement and deletion, and verify every public URL
- Week 4, exceptions and expansion: test pending and rejected states, document policy and account escalations, then add the next location batch only if readback is complete
Stop the rollout when the system cannot prove which location owns a review, who approved the exact reply, or what a customer can see now. Those are not minor logging gaps. They are the controls that make portfolio-scale review operations trustworthy.
Sources
- Google Business Profile APIs: work with review data. Review listing, retrieval, multi-location batching, reply, and deletion methods
- Google Business Profile API: batchGetReviews. The 50-location request limit, pagination, ordering, verified-location requirement, and authorization scope
- Google Business Profile API: Review resource. Review fields, reply states, policy violations, public reply URL, and unknown enum handling
- Google Business Profile API: updateReply. Creating or replacing a reply for a verified location
- Google Business Profile APIs: basic setup. Project approval, API enablement, OAuth credentials, and the lack of a sandbox
- Google Business Profile APIs: OAuth setup. The business.manage scope and user authorization flow
- Google Business Profile API policies. Authorized use, express consent for automated replies, security, retention, and aggregation restrictions
- Google Business Profile API: Notifications. Account-level Pub/Sub settings and new or updated review notifications
- Google Business Profile APIs: usage limits. Quota access, request limits, and RESOURCE_EXHAUSTED handling
- Google Business Profile APIs: latest updates. The 2026 review reply state, policy violation, and reply URL additions
- Google Business Profile Help: read and reply to reviews. Public reply behavior, privacy guidance, and Google's recommendation to respond when necessary
Amadeus Peterson is the CTO and Co-Founder of Cheers, the local search platform for multi-location service businesses.