Google Places API vs scraping: costs, limits and legality
Updated July 22, 2026 · 6 min read
This comparison gets muddled because the two things aren't competitors. The Places API is an ingredient for building software. Scraping is a way to obtain a dataset. People compare them because both start with “get places from Google”, and then get surprised when the API doesn't do what they wanted.
Here's the difference laid out honestly, including the parts that favour the API.
Result limits
Text and nearby searches on the Places API have historically returned a capped number of results per query — traditionally 60, across paged requests. Google Maps' own results feed caps out at roughly 100–120 places for a single search. Both numbers are far below the real count of, say, restaurants in a mid-sized city.
The workaround is identical either way: subdivide geographically and run many queries. That's what zip-code splitting does, and it's why the number of API calls — and therefore the bill — climbs quickly on any market-wide pull.
Fields you get and fields you don't
The API gives you clean, structured place data: name, address, coordinates, phone, website, rating, review count, hours, place ID. That's genuinely good data, better formatted than anything scraped.
What it does not give you is an email address, because Google doesn't hold one. No API tier changes that. If email is the reason you're building the list, the API is a dead end on its own — you'd still need to crawl each business's website afterwards, which is the harder half of the job. The email-enrichment guide covers what that involves.
Cost shape
The API bills per request, by SKU, with details costing more than basic search results and a monthly credit that absorbs light usage. The practical consequence: cheap for an app that looks up a handful of places per user session, expensive for one team pulling tens of thousands of rows once. Check Google's current pricing page before budgeting — the SKUs change.
A scraping tool bills the other way round: per business delivered, not per request. In Hubertino that's 1 credit = 1 business, unused reservations auto-refunded, and the website-crawled email and socials are included rather than a separate line item. Which shape is cheaper depends entirely on whether you're building a product or a list.
Terms and risk
This is the part worth reading carefully rather than taking from a blog post. Google's Maps Platform terms restrict what you may store and for how long, and generally do not contemplate exporting place data into a marketing database. That restriction is contractual — it's about your agreement with Google, which is a different question from whether collecting public business information is lawful in your jurisdiction.
Scraping sits outside that contract but inside general law: public business contact details, used for relevant B2B outreach, with opt-outs honoured. The GDPR guide goes into the European side in more detail. Neither of these is legal advice, and if the dataset is central to your business, ask a lawyer who reads your actual contracts.
Which to pick
- 1
Building a feature for your users
Use the Places API. Autocomplete, a store locator, a map inside your product — it's designed for this, it's supported, and the terms are the terms you already agreed to.
- 2
Building a prospect or market list
Scrape. You need completeness, export, and emails, and the API delivers none of the three.
- 3
Both
Common and fine. Product surfaces run on the API; the sales team's territory lists come from a scrape.
Common questions
Is the Places API's data more accurate?
It's more consistently structured, which is not the same thing. Both reflect the same underlying listings, so both are as stale as the business's own profile — see the guide on how fast local data goes stale.
Can I get 5,000 restaurants in a city from the API?
Only by running many geographically subdivided queries and paying per request, and you'll still have no emails at the end of it.