You've got an API key, you've enabled the Places API, you call Place Details with the reviews field, and back comes a tidy JSON array. You scroll down expecting hundreds of reviews and find… five. You check the docs, look for a pageToken, and there isn't one. This isn't a bug or a quota you can raise. It's a hard product decision, and it traps almost everyone the first time.
The maximum number of review bodies Place Details will ever return for a place — even when user_ratings_total says the place has 4,000 reviews. There is no pagination cursor. The sixth review is simply not reachable through the official API.
Why the cap exists, and why it can't be tuned
Google positions the Places API as a way to summarize a place inside your own app — a thumbnail of reputation, not a firehose. The five reviews it returns are a rotating, "most relevant" sample, not the newest and not the complete set. There's no parameter to ask for more, no billing tier that unlocks it, and the reviews_sort option (newest vs. most relevant) only reorders the same five. If your use case is reputation monitoring, competitor analysis, or anything where you need every review, the official API is structurally the wrong tool.
That leaves one route: read the public Maps listing the way a browser does, scroll the reviews panel, and parse what loads. Done right, that returns the full review history sorted however you want.
Official API vs. scraping the listing
| Capability | Places API | Scraping the listing |
|---|---|---|
| Reviews per place | 5, fixed | Full history, paginated for you |
| Sort by newest | Reorders the same 5 | True newest-first, all of them |
| Review text language | Often auto-translated | Original + translation both available |
| Owner responses | Not included | Included as a child field |
| Per-call cost | Billed per Place Details call | Billed per result extracted |
The review fields you actually get
A scraped Maps review is more useful than the API's five because it carries the things reputation teams need:
- rating — 1 to 5 stars.
- text — the original review, plus textTranslated when the reviewer wrote in another language. Don't store only the translation; the original often carries the specific product or staff name.
- publishedAtDate — an absolute timestamp, not Google's fuzzy "3 months ago". Essential for trending.
- reviewerName / reviewsCount / isLocalGuide — a one-review reviewer and a 400-review Local Guide are not equal weight.
- responseFromOwner — whether and how the business replied. The single best signal of whether a location is actively managing its reputation.
- reviewId — your dedup and "is this new?" key.
Monitoring new reviews, because there's no webhook
Google has no "new review" webhook. If you want to catch a fresh 1-star the day it lands — before it sits unanswered for a week — you build the alert yourself with a scrape-and-diff loop. The pattern is simple and reliable:
Scrape newest-first, shallow
You don't need the whole history on every run. Pull the 20 most recent reviews per location, sorted by newest. That's fast and cheap even across hundreds of locations.
Diff against stored review IDs
Keep a set of reviewIds you've already seen. Anything in today's pull that isn't in that set is a brand-new review. No timestamp math, no off-by-one timezone bugs.
Route by rating and location
New review with rating <= 2 at the Denver store? Ping the Denver manager's Slack instantly. New 5-star? Drop it in the testimonials queue. The location field is what makes this work at chain scale.
The scrape call for that monitoring loop, sorted newest-first:
curl -X POST "https://api.apify.com/v2/acts/renzomacar~google-maps-reviews/run-sync-get-dataset-items?token=<APIFY_TOKEN>" \
-H "Content-Type: application/json" \
-d '{
"placeUrls": ["https://maps.app.goo.gl/<YOUR_PLACE>"],
"sortBy": "newest",
"maxReviews": 20
}'sortBy: "newest", both the API and an unconfigured scrape return Google's "most relevant" ordering — which is stable for weeks and will make your diff loop think nothing changed while bad reviews quietly pile up. For monitoring, always force newest. Save "most relevant" for the one-time deep pull where you want the reviews buyers actually read.Multi-location: the real reason teams scrape
A single coffee shop doesn't need any of this; the owner reads their reviews. The pain starts at scale: a franchise with 80 locations, an agency managing reputation for 30 clients, a brand auditing every dealer. There, the five-review cap isn't an inconvenience, it's a wall — you can't even tell which location is bleeding stars.
Feed a list of place URLs or place IDs in one run and you get back a single dataset keyed by location. From there the analysis everyone wants falls out naturally:
- Average rating per location, ranked — instantly surfaces the worst performer.
- Response rate per location — which managers ignore their reviews.
- Recurring complaint keywords clustered by store — "slow", "rude", "cold" mapped to addresses.
- Star trend over 90 days — catch a location sliding before it cracks 4.0 and falls out of the local pack.
Get every review, not just five
Our Google Maps Reviews Actor pulls full review history across as many locations as you list, with owner responses, original-language text and absolute dates already parsed — ready for a monitoring diff. Free Apify credits to start.
Run the Reviews Actor → Or get local business leadsOne honest caveat
Reviews change. People edit them, delete them, and Google removes ones it flags as fake. A review you stored last month may not exist today. If you're computing a rating trend, snapshot the full set periodically rather than assuming your stored history is immutable — otherwise a wave of removed fake reviews will look like a sudden reputation drop that never actually happened.
Disclosure: links to Apify on this page are affiliate links, marked rel="sponsored". If you create a paid account through them we may earn a commission at no extra cost to you. We build and maintain Actors on Apify ourselves, including the Google Maps Reviews Actor linked above.