Legal

Google reviews API: what you can and cannot build

21 August 2026 · JustReview

There are two Google APIs that return reviews and they answer completely different questions. The Places API will tell you about any place on the map, but it hands back a maximum of five reviews and forbids you from storing them. The Business Profile API will give you the full review history with no cap, but only for profiles the signed-in account verifiably owns. Almost every “can I build X” question about Google reviews resolves the moment you work out which of those two you are standing on, so this post walks both, with numbers from the 384,482 Google reviews sitting in our own production database on 2026-08-21.

The five-review cap is not a rate limit, it is the ceiling

Google’s REST reference for the Place resource says it in one sentence: the reviews field is a list sorted by relevance, and a maximum of 5 reviews can be returned. Checked on 2026-08-21, that is still the wording. There is no page token, no offset, no field mask that unlocks more. Five is not what you get per request, it is what exists as far as your integration is concerned.

Developers usually read that and assume it is a mild inconvenience. It is worth putting a number on how mild. Across our production database we hold 384,482 active Google reviews spread over 2,907 accounts. The median profile has 37 of them, the ninetieth percentile has 220, and the largest single profile has 29,145. If every one of those accounts were capped at five, the whole corpus would collapse to 13,800 reviews. That is 3.6% of what we actually hold, and 2,555 of the 2,907 accounts, or 87.9%, would lose reviews.

The time axis is worse than the count. Taking the 1,896 profiles with at least twenty reviews and asking how much calendar time the five most recent ones span, the median answer is 53 days. The median full history on the same profiles runs 1,693 days. So a five-review view of a typical established business shows roughly seven weeks out of four and a half years.

Five reviews is a sample, and samples move

If the five were a fair random draw the cap would at least be statistically harmless. They are not, and the drift is measurable.

On those same 1,896 profiles we compared the average rating of the five most recent reviews against the average across the whole history. The five-review average came out at 4.726 stars, the full average at 4.782. That gap looks trivial until you stop averaging the averages: the mean absolute difference per profile is 0.256 stars, and 296 profiles, one in six, are off by half a star or more.

The direction is not uniform either, which is the interesting part. For 1,027 profiles the recent five read higher than the true average and for 455 they read lower. More businesses look better than they are, but the ones that look worse look much worse, because a single fresh one-star review moves a five-item average by 0.6 to 0.8 stars and there is nothing else in the sample to dilute it. That asymmetry is why the pooled figure lands below the true average even though most profiles individually land above it.

One more thing a five-item sample cannot survive: 124,384 of our 384,482 Google reviews, or 32.4%, carry a star rating and no text at all. Those rating-only reviews are not skewed, they average 4.689 stars against 4.712 for reviews with text, so they are not distorting anyone’s score. They do mean that a third of the raw material is unusable for anything that needs a sentence on screen, and when your entire supply is five items, losing a third of them at random is the difference between a full testimonial section and two quotes.

The rule that actually decides what you can build

Almost nobody reads the Places API policy page before designing around it, and it contains the sentence that ends most projects. You must not pre-fetch, cache or store Places API content beyond the allowed exceptions. The place ID is the one field called out as exempt, and you may store it indefinitely.

Read that against what a reviews widget is. A widget keeps a copy of the reviews so the page renders in milliseconds, so it still works when the upstream API is having a bad afternoon, so you can sort and filter without paying per request, and so you can moderate what appears on your own site. Every one of those properties requires storage. The Places API tells you not to store. The two are not in tension, they are simply different products.

The attribution rules point the same way. Displaying a review obtained through the Places API obliges you to credit the author, to give the reader a route to the original review on Google Maps through the supplied URI, to expose the reporting link for that content, and to state how the reviews are ordered and filtered, since relevance is the default and it is not obvious. None of that is unreasonable. All of it constrains the design of the box on your page far more than any developer expects when they start.

The owner’s API, and what it costs to keep

The Business Profile API is the other side. It has no five-review cap, it returns the full review list with paging, it lets you post replies, and it is gated behind an OAuth grant carrying the business.manage scope from an account that is a verified owner or manager. That gate is the whole design. You can build anything you like about your own reviews and nothing at all about anyone else’s, which is exactly the boundary a review widget should sit on and exactly why every credible one makes you sign in with Google rather than paste a Maps link.

What the documentation does not prepare you for is that the OAuth grant is the expensive part, not the quota. We currently hold 2,210 Google connectors and 1,072 of them, 48.5%, are sitting on a refresh token Google has stopped honouring. Every one of those is a business whose reviews stop updating until a human signs in again.

The error log makes the same point from the other direction. Over the 30 days to 2026-08-21 our cron system logged 925 errors in total. 868 of them came from the Google connector, and of those 868, 670 were refresh-token rejections rather than anything to do with reviews. Only 198 were import failures, and their breakdown is the surprise: 188 were HTTP 503, 8 were HTTP 500, and exactly 3 were quota-related. Google’s review quota, once granted, has been a non-issue for us. Transient 503s and dead OAuth tokens are the entire operational cost.

The trap in the middle: paging you did not know you needed

One failure mode is worth naming because we shipped it ourselves and it is silent.

Before you can read reviews for a location you have to find the location, and the listing endpoints are paged with small ceilings: the accounts list maxes out at a page size of 20, the locations list at 100, and both return a nextPageToken you are expected to follow. Our code requested one page of each and ignored the token. For any customer whose profile sat past the first page, the import found no matching location, imported zero reviews, and raised no error at all, because from the code’s point of view nothing had gone wrong. We fixed it on 2026-07-26 by following the token with a fifty-page safety stop. The lesson generalises: in this API, an empty result is not evidence of an empty profile.

The two routes, side by side

Ordered by how much of a reviews product each one lets you actually ship.

What this means if you just want reviews on your site

If your goal is a reviews section on your own website, the API question was a detour. You need the owner’s route, which means an OAuth grant, token refresh handling, paging through two listing endpoints, a store for the reviews, and something to re-authorise the roughly half of grants that will lapse. That is a maintained service, not a weekend integration, and it is what we sell.

We built JustReview on exactly that route, which is why the numbers above exist to be published: full history rather than a five-item window, reviews held in a database we control so your page never waits on Google’s 503s, and a re-authorisation flow for the day the token dies. You can see what it puts on a page on the Google reviews widget page, check the plans on pricing, or create an account and connect a profile to see your own review count against the five you would have had.

If you would rather write the embedding code yourself, our walkthrough on embedding Google reviews in plain HTML covers the markup side, and the legal footing for republishing reviews is in is it legal to embed Google reviews and the docs on whether scraping reviews is legal.

The caveats, plainly. Every distribution number here describes the businesses that connect a Google profile to a reviews widget, which skews toward companies that already have reviews worth showing, so a brand-new profile will not look like our median. The five-review drift is measured against the five most recent, while Places sorts by relevance, so treat 0.256 stars as the shape of the problem rather than the exact figure for a relevance-ranked five. And Google changes these APIs; every external claim above was read in Google’s documentation on 2026-08-21 and deserves a re-read before you build on it.