You wire up the Google Places API, request a place with the reviews field, and get back a clean JSON response — with exactly five reviews in it. The place has 1,400. You check your quota, you check your billing tier, you search for the page token. There isn't one. This post explains what the Google Places API reviews limit actually is, why the obvious workarounds do not work, what Google's other review API can and cannot do, and the three routes that do produce a complete review dataset.
The limit, precisely
Google's Place Details documentation describes the reviews field as returning up to five reviews for the place. Not five per page — five, full stop. There is no next_page_token on the reviews array the way there is on Text Search or Nearby Search results, no offset parameter, and no field mask that unlocks more. The same ceiling applies to the newer Places API surface as to the legacy endpoint.
Three properties of that cap catch teams out:
- It is not a quota. Raising your daily request limit, enabling billing, or contacting sales does not change it. Every call returns at most five reviews.
- It is not a rate limit. Calling the endpoint a hundred times returns the same handful of reviews a hundred times, so retry logic just burns money.
- Sorting does not defeat it. You can influence which five you get — most relevant versus newest — but the two sets overlap in ways you cannot predict, and stitching them yields a dozen reviews at best, not fourteen hundred.
It is also worth being clear about what the API does give you well: the place's overall rating and its user_ratings_total. If all you need is "what is this place's current average and how many reviews does it have", Place Details is an excellent, cheap answer, and one call gets it. The trouble starts the moment you need the review text in bulk.
Why the cap exists
Google has never published a rationale, so this is inference rather than doctrine, but three factors clearly shape the design.
Reviews are user-generated content that Google actively moderates. Its contributed-content policies mean reviews get removed for policy violations, and reviewers can edit or delete their own writing at any time. A capped, freshly computed sample keeps redistributed copies from turning into a permanent archive of content Google intended to be able to take down.
The field is also positioned as a display feature. The intended use case is an app or site showing a place card — name, hours, rating, and a few recent reviews to give a flavour. Five is enough for a card and not enough to reconstruct a competitor's feedback corpus.
And review corpora are a genuinely valuable asset. Complete review histories power reputation products, sentiment tooling and pricing research. Handing them over through a per-call API would make that asset trivially copyable.
The other API: Business Profile
Google does have an API that returns every review — with pagination, roughly 50 per page — as part of the Business Profile APIs. The catch is in the authorisation model: it returns reviews only for locations your authenticated Google account has verified ownership of.
That makes it exactly right for one job and useless for the rest. If you manage 40 clinics and want a warehouse of your own review history with replies, ratings and timestamps, this is the correct, free, fully supported path. Budget for the setup: you must request API access, get approved, complete OAuth, and map your location IDs before the first row lands. Teams typically measure that in days, not hours.
What it will never do is show you a competitor. Ownership verification is the whole point of the endpoint. So the moment your question is comparative — "why does the place across the street have 4.7 when we have 4.2?" — this API is the wrong door.
What people try instead, and how each fails
Calling Place Details repeatedly
The first instinct is a loop. It does not help: there is no offset to advance, so every iteration returns the same five reviews with a fresh bill attached. Google's usage and billing page shows that requesting the reviews field puts the call in a higher-priced SKU than a basic-fields request — so this particular mistake is more expensive than most.
Rotating the sort order
Requesting most-relevant and then newest genuinely can return different reviews. But you get two overlapping samples of five, no way to know what fell between them, and no guarantee of stability between calls. As a sampling strategy for a rating trend it is unusable, because the sample is neither random nor complete.
Writing your own scraper
Reading the same public review feed the Maps interface loads is the technically correct approach, and it is what every complete-review product ultimately does. Doing it yourself is a bigger project than it looks: the feed is a cursor-paginated internal endpoint whose parameters change without notice, the place identifier has to be extracted from whichever of several Maps URL formats the user pasted, reviews arrive with the original language plus a separately provided translation, star-only reviews have null text that naive parsers drop, and owner replies are attached to their parent rather than listed separately. Building it takes a week; keeping it working is a permanent, unglamorous maintenance job. We wrote about the same trade-off for social platforms in free vs paid comment scrapers, and the conclusion transfers cleanly.
Buying a full-database vendor
Enterprise reputation platforms will sell you complete review data with dashboards and alerting attached. If you manage hundreds of locations and need workflow tooling, that is a reasonable purchase. For a single analysis — "export these four places, tell me what the complaints are" — an annual contract and an onboarding call is the wrong shape of solution.
The three routes that actually work
Route 1 — Your own locations: the Business Profile API
Verified owner, need your own history, comfortable with OAuth: use it. Free, official, complete, paginated, and it includes your replies. Pull nightly into a warehouse and every rating question about your own estate becomes a SQL query.
Route 2 — A place-link exporter: any place, no API key
For competitor research, prospect audits, or a one-off "why did the rating drop" investigation, an exporter that takes a Maps place link is the shortest path. Copy the link with Share → Copy link, paste it into the Google Reviews exporter, and download CSV, Excel or JSON. There is no Cloud project, no OAuth, no key, and no five-review ceiling — it paginates until the reviews run out.
The file gives you what the API sample cannot: star rating as a sortable number, the original review text plus Google's English translation, real publish timestamps rather than "3 months ago", owner reply and reply date, photo URLs, review URL, and reviewer credibility signals like lifetime review count and Local Guide level. The first 100 reviews of any place are free with no signup; beyond that it is $1 per 100 reviews, or a $14 3-Day Pass for unlimited places up to 10,000 reviews each. A step-by-step walkthrough is in how to export Google reviews to CSV.
Route 3 — Places API for the aggregates only
Do not throw the API away. It is the cheapest way to track the two numbers that matter most at a glance: rating and user_ratings_total. A daily job storing those two fields for a set of place IDs gives you a rating-and-velocity time series for pennies. Use the API for the aggregate signal, and export the full review text only when the signal moves and you need to know why. This hybrid is what most teams land on after they stop fighting the five-review cap.
Choosing between them
Answer three questions and the choice makes itself.
Do you own the location? If yes and you need a permanent feed, Business Profile API. If yes but you need an answer this afternoon, the exporter is still faster than the access-request process.
Do you need review text, or just the score? Score and count: Places API, daily, cheap. Text: you need a complete export, because the interesting content is in the tail, not in the five reviews Google chose to surface.
Is this recurring or one-off? One-off competitive audits and pitch research are exporter jobs. A permanent multi-location monitoring system for locations you own justifies the API integration.
What five reviews actually hides
It is tempting to treat the five reviews as a sample and reason from them. Do not. They fail the two conditions that make a sample useful.
They are not random. The default ordering is relevance, which is Google's own ranking of what a prospective customer should read — weighted toward longer, better-written, photo-carrying reviews from established contributors. Whatever selection logic sits behind that, it is not a coin flip, so any proportion you compute from those five is biased by an unknown amount in an unknown direction.
Five is too few even if it were random. Suppose a place has 900 reviews and 12% of them are 1-star. In a genuinely random sample of five you would expect 0.6 one-star reviews, meaning the most likely single outcome is that you see none at all and conclude the place has no complaints. The standard error on a proportion at n=5 is roughly 15 percentage points, so a 95% interval around your estimate spans almost the entire plausible range. You cannot detect a rating trend, a complaint theme, or a seasonal dip with that. Every interesting signal in review data lives in the tail, and a five-row sample has no tail.
This is the practical reason the cap matters. It is not that five is a small number of rows to work with; it is that five rows cannot answer any of the questions people export reviews to answer.
Does the newer Places API change anything?
No. Teams migrating from the legacy Place Details endpoint to the newer Places API surface often assume the field masks and the redesigned response shape come with a higher review allowance. They do not. The reviews field is still a capped sample, still without a page token, and the migration changes only how you request fields and how the call is billed. If a five-review response is blocking your project, an API migration will not unblock it — the constraint is a product decision, not an endpoint version.
Two smaller differences are worth knowing. The newer surface lets you request narrower field masks, so the aggregate-only pattern below gets cheaper: ask for the rating and total count and nothing else, and you pay the lower-tier price. And the response carries the reviews' original language alongside a translation flag, which matters for tourist-heavy locations where a majority of reviews are not in the local language.
A hybrid architecture that works
The setup most teams settle on after they stop fighting the cap has three layers, each doing what it is actually good at:
- Daily, cheap, automated: Place Details for
ratinganduser_ratings_totalonly, across every place ID you track. Two numbers a day per place gives you a rating time series and a review-velocity series — enough to detect that something changed and when. - Monthly or on-trigger, complete: a full review export per place, run on a schedule or fired when the daily series moves more than your threshold. This is the layer that answers why the number moved, because it has the text.
- Owned locations, continuous: the Business Profile API feeding your warehouse with your own reviews and replies, so response rate and reply latency are queryable without any export step.
The division of labour matters because it keeps costs proportional to value. Aggregates are cheap and answer "did something change". Full text is more expensive and answers "what changed". Running the expensive layer only when the cheap layer flags something is what makes ongoing monitoring affordable across dozens of locations.
Staying on the right side of the rules
Two boundaries are worth stating plainly. Analysing public reviews is standard market research, but redistributing them as though they were your own testimonials is not — the review belongs to its author, and Google's content policies govern what may be republished on the platform. Reviewer names, avatars and profile links are personal data under GDPR and similar laws; if your analysis does not need them, drop those columns after export and keep only the rating, text, date and language.
And whatever you learn, do not act on it by manipulating reviews. Google's prohibited and restricted content policy forbids fake, incentivised and gated reviews, and enforcement against listings is real. The legitimate play is the boring one: find the complaint that appears in 40 reviews, fix it, and watch the next quarter's reviews stop mentioning it.
Summary
The Google Places API returns five reviews per place by design, and no quota, budget or pagination trick changes that — it is a display sample, not a data feed. The Business Profile API returns everything, but only for locations you have verified ownership of. For any other place, the working route is to read the public review feed: paste the Maps share link into the Google Reviews exporter and take the CSV, keeping the Places API for the cheap daily rating-and-count signal. Related reading: how to export Google reviews to CSV · free vs paid comment scrapers · how to analyze Facebook comments.