Google Places API Limits: 60 Results, 5 Reviews and Pricing

The Google Places API limits that matter for collecting business data come down to four numbers. A Text Search (New) query returns at most 60 places across all its pages. A Nearby Search (New) request returns at most 20 places and has no documented pagination. A place returns at most 5 reviews. And it returns at most 10 photos. Everything else (the per-call pricing, the field masks, the free monthly caps) follows from how those limits interact with the job you are trying to do.

For displaying one place inside your own app, none of those limits is a problem, and the official API is the right tool. For building a list of every dentist in a region, or pulling the full review history of 300 locations, they are the whole problem. This reference sets out exactly what the Places API (New) will and will not give you, what it costs to work around the limits, and when a scraper such as the Google Maps Data Scraper is the better fit. Google's figures below were checked against developers.google.com on 28 October 2026. Prices are as published at the time of writing and subject to change.

Google Places API limits at a glance

None of this is hidden. Google documents each limit, and it notes that the 60-result ceiling is "subject to change", so check the Text Search (New) documentation before you build on any of these numbers. The rest of this article explains what each limit does to a real collection job.

The places API 60 results limit, and why Nearby Search stops at 20

Text Search (New) works like typing a query into Google Maps: "dentist in Leeds", "coffee near 10001". The response holds up to 20 places by default (you can set pageSize anywhere from 1 to 20). When more results exist, it includes a nextPageToken. You pass that back as pageToken to get the next page. After three pages, 60 results in all, the token stops coming, even if the city has 400 dentists.

Nearby Search (New) is stricter. You describe a circle and the types you want, and maxResultCount must be between 1 and 20. No pagination is documented, so each circle gives you at most 20 places.

What the workaround looks like

Developers who need more than 60 results all end up with some version of the same fix, which is to split the area until every piece holds fewer results than the cap.

1. Grid the area. Cover the city with small circles or rectangles, small enough in dense districts that no single cell would return more than 60 (Text Search) or 20 (Nearby Search) matches.
2. Multiply by query variants. "Restaurant" alone misses places listed as a pizzeria or a ramen bar, so you repeat each cell for the sub-categories you care about.
3. Subdivide saturated cells. Any cell that comes back with the full 60 (or 20) probably had more. Split it into four and search again.
4. Deduplicate on the place ID. Adjacent cells and overlapping categories return the same businesses many times. Keep one row per place_id. Our guide to place IDs, CIDs and Google IDs explains which identifier to key on.

This works, and it is how most serious API-based collectors run. It also means you pay for every call, duplicates included, and you have to write and maintain the code that decides when a cell is saturated. A dense downtown might need cells a few hundred metres across. A suburb can use cells ten times bigger. Getting that wrong one way wastes calls, and getting it wrong the other way silently misses businesses.

Five reviews and ten photos: the Place Details limits

The Place resource has two caps that catch people out more than the search ceiling does. According to Google's documentation, "a maximum of 5 reviews can be returned", sorted by relevance, and "a maximum of 10 photos can be returned".

The review limit matters most. A busy restaurant can have 2,000 reviews, and the API gives you five, picked by Google's relevance ordering rather than by date. You cannot ask for the newest five, or for the next five, or for every 1-star review from the last quarter. For displaying a few representative reviews next to a place, that is fine. For reputation monitoring, sentiment analysis or competitor research it rules the API out: you cannot see a trend in five reviews chosen by relevance.

Photos work the same way. Ten photo references per place is enough for a gallery widget, but not for auditing what fifty branches actually look like on their listings. That job needs every image, and a place can have far more than ten.

We cover the review side in more depth in how to scrape all Google reviews past the 5-review limit.

How Places API pricing works

The Places API (New) bills per call, not per business. A Text Search request that returns 20 places is one call. So is a request that returns 3 places, or a third page full of businesses you already have. Place Details is one call per place.

The field mask sets the price of each call. You list the fields you want, and the call is billed at the SKU tier of the most expensive field in the mask. Ask only for basic fields and you pay the lower tier. Add a phone number, website or rating and the call moves up a tier. Add reviews and the whole call is billed as Enterprise + Atmosphere.

Volume discounts apply above 100,000 calls a month. The figures above are the first-band list prices on Google's Maps Platform pricing page, as published at the time of writing. Google has changed this structure before and will again, so confirm the current numbers before you budget.

Two things follow from billing per call. First, the cost of a collection job depends on how many calls your search strategy makes, not on how many businesses you end up with. The more your grid overlaps, the more you pay per unique place. Second, the free monthly caps are per SKU and per billing account. If your production app already uses Place Details, a one-off research pull shares the same free allowance.

A worked cost comparison: 10,000 restaurants

Here is a concrete job. You want every restaurant in a large city, which you estimate at about 10,000, with name, address, phone, website, rating and up to 5 reviews each. All the numbers below are illustrative. Your real call counts depend on the city, the categories and how well your grid fits the density.

Route 1: Text Search to discover, Place Details to enrich

Say covering the city takes 1,500 search cells-and-category combinations, each paged to the full three pages: 1,500 × 3 = 4,500 Text Search Pro calls. That returns about 90,000 raw results, which collapse to roughly 10,000 unique restaurants after deduplication. A ratio of nine raw results per unique place is normal for a tightly gridded dense city.

• Text Search Pro: 4,500 calls × $32 / 1,000 = $144 at list price. All 4,500 fall inside the 5,000 free calls, so it costs $0 if nothing else on your account is using that allowance.
• Place Details with phone, website, rating and reviews is billed at Enterprise + Atmosphere because of the reviews field: 10,000 calls × $25 / 1,000 = $250 at list price. Take away the 1,000 free calls and 9,000 × $25 / 1,000 = $225.
• Total: $394 at list price, or $225 with both free allowances unused.

Route 2: request the rich fields in Text Search directly

You can also put phone, website, rating and reviews into the Text Search field mask. Then every page is billed at Text Search Enterprise + Atmosphere: 4,500 × $40 / 1,000 = $180, or (4,500 − 1,000) × $40 / 1,000 = $140 after the free calls. This is cheaper in this example, but you pay the rich rate for every duplicate on every overlapping page. If your grid overlaps more, the advantage shrinks.

The same job with Livescraper

• Maps rows: 10,000 businesses × $0.002 = $20, with phone, website, rating, review count, opening hours and the rest of the place columns on each row.
• Reviews: with the Google Maps Reviews Scraper capped at 5 per place, 50,000 reviews × $0.002 = $100.
• Total: $120. A new account's first 500 rows are free, one time, with no card required, so the first pull costs slightly less.

The money is closer than many comparisons claim. At this scale the API costs low hundreds of dollars, not thousands. The real differences are elsewhere. Your five API reviews per place are Google's relevance pick, and you cannot go past five at any price. Through the reviews scraper, 5 is just a setting: the API's reviewsLimit defaults to 100, and reviewsLimit=0 collects a place's entire history in newest-first order. If those 10,000 restaurants average 120 reviews each, the full history is 1.2 million reviews, or $2,400 at $0.002 each. That dataset does not exist on the official API. The other difference is engineering time: on Route 1 you write and maintain the grid, the saturation logic, the pagination and the deduplication, while a scraper task takes the category and location and returns deduplicated rows. Our build vs buy cost breakdown covers that trade-off in detail.

Terms: display, caching and attribution

Price and limits are not the only constraints. The Places API comes with the Google Maps Platform terms, and those shape what you may do with the results. In general terms, they require attribution when you display Places content and restrict pre-fetching, caching or storing that content beyond narrow exceptions (place IDs, for example, may be stored). Some uses also come with display requirements, for example around showing results alongside a Google map. Building a permanent internal database of businesses from API responses can therefore conflict with the terms, even when you paid for every call.

Read the current terms for your own use case. This is a summary, not legal advice. Scraped public data has its own questions, covering site terms, data protection and outreach rules, and our practical compliance guide to scraping Google Maps works through them. Neither route removes your obligations under GDPR or similar laws once a field identifies a person, and reviewer names do.

When the official API is the right tool

The fair answer is that the Places API is very good at the jobs it was designed for, and for those jobs a scraper is the wrong choice.

• In-app lookups and autocomplete. A user types an address or a business name in your product and needs a suggestion within milliseconds. That is exactly what the API is built and priced for.
• Real-time display of a single place. Showing opening hours, rating and a handful of reviews on a store page, fetched when the page loads.
• Sanctioned use under Google's terms. If your product shows Google data to end users, or your legal team needs a contract with Google behind every field, the API is the route that gives you that.
• Low, steady volume. A few thousand lookups a month fits inside the free caps and costs nothing.

If your use looks like that, use the API, and use it well: request the smallest field mask that does the job, cache only what the terms allow, and keep your place IDs.

When a scraper is the better Google Places API alternative

A scraper makes sense when the job is collection rather than display. That means bulk lists, full histories, and every result in an area rather than the first 60.

• Bulk business lists. Every plumber in a state, every café in five cities. The Google Maps Data Scraper takes categories and locations and returns rows of the same public data a logged-out visitor sees, across 51 core columns including business_phone, business_domain, average_rating, total_reviews, working_hours, place_id and google_id. Big jobs split into batches automatically, and a single task can run up to 500,000 rows. Our field-by-field guide to Maps data describes each column.
• Full review history. Every review on a place, newest first, with the text, rating, owner reply and dates as 27 columns per review. You can filter by date, rating, language or keyword.
• Every photo. The Maps scraper returns one photo_url and a photos_count per place. The Google Maps Photos Scraper returns the rest, as one row per photo with full-size and thumbnail links, the post date and Google's gallery tags. It returns links, not image files, and reusing someone's photo is a copyright question you have to answer yourself.
• Contacts the listing does not carry. Places has no email field at all. Enrichment visits each business website and adds up to three emails and phones plus social links.
• Predictable per-row cost. You pay $0.002 per row returned, and the pre-flight estimator shows the cost before a run starts, so the cost tracks rows returned rather than pages requested.

Developers who want this from code rather than a dashboard can use the Livescraper REST API. You send GET /api/v1/task/map with up to 15 queries per request, using search terms, place IDs or CIDs, with deduplication across queries on by default. For a longer comparison of both routes, see free Google Maps scraper vs API.

How to choose: a five-question checklist

1. Is the data shown live to an end user, or stored for analysis? Live display points to the API. A stored dataset points to collection, and you should check the API's storage terms before choosing it.
2. Do you need more than 60 results per area? If yes, the API needs a gridding system, and you should compare the cost of building it with the cost of not building it.
3. Do you need more than 5 reviews or 10 photos per place? If yes, the API cannot supply them at any price.
4. What will the job cost, per call versus per row? Model both with your own numbers. Use the illustrative arithmetic above as a template and the Livescraper pricing page for the per-row side.
5. Who maintains it? API pricing and limits change, and so does a home-built grid. Decide who keeps the pipeline working next year.

Plenty of teams use both. The API powers the address box in their product, and a scraper builds the prospect list or the review dataset behind it. A shared place ID joins the two. If you have a list of names and need IDs, the free Place ID Finder looks them up.

Conclusion

The Google Places API limits are clear once they are laid out. Text Search stops at 60 results, Nearby Search returns 20, and each place gives you 5 reviews and 10 photos. Every call is billed at the tier of the most expensive field you request, and that call-based billing turns overlapping searches into extra spend. For lookups, autocomplete and live display of a single place, those limits rarely matter and the API is the right, terms-sanctioned choice. For bulk lists, complete review histories and every business in an area, they are the job itself, and a scraper does it more directly. The Google Maps Data Scraper returns deduplicated place rows at $0.002 each, and the reviews and photos scrapers go past the 5-review and 10-photo caps. The first 500 rows on a new account are free, so you can test it on your own market before you commit to either route.

Related reading: Google Maps Data Fields Explained: Every Column and Its Quirks, How to Export 10,000 Google Reviews for AI Analysis, How to Clean and Deduplicate Google Maps Data.