Google Maps API vs Scraping: Limits, Cost and Terms (2026)

The short answer

There is no official Google Maps API for scraping. The official product is the Places API, and it's designed for an app that looks up a handful of places while a user is waiting, then shows them on a Google map. It will return business names, phone numbers and websites, so it looks like a list-building tool. Two properties make it a poor one:

• A text query returns at most 60 places: Twenty per page, three pages. The Google Maps website shows about 120 for the same search.
• Its policies restrict storing the results: Place IDs can be kept. The rest of the content is not meant to be cached or stored, which is exactly what a lead list in a CRM is.

A scraper reads the public Google Maps website instead and gives you a file. It costs more per row and it isn't an official Google product. Which trade is right depends on whether your data ends up inside an app or inside a spreadsheet.

What the official API is, and how a request works

The endpoint that matters for finding businesses is Text Search. You send a query in plain words and a field mask listing exactly which fields you want back. The field mask is required, and it also sets the price, because Google bills the request at the highest tier of any field in it.

curl -X POST 'https://places.googleapis.com/v1/places:searchText' \
  -H 'Content-Type: application/json' \
  -H 'X-Goog-Api-Key: YOUR_KEY' \
  -H 'X-Goog-FieldMask: places.id,places.displayName,places.formattedAddress,places.nationalPhoneNumber,places.websiteUri,nextPageToken' \
  -d '{"textQuery": "dentist in Austin, TX", "pageSize": 20}'

The response holds up to 20 places and a nextPageToken. Send the token back to get the next 20, and once more for the last 20. Each of those three calls is a separate billed request. Because the mask above includes a phone number and a website, all three are billed on the Enterprise tier.

The other search endpoint, Nearby Search, takes a point and a radius instead of text. It returns a maximum of 20 places and has no pagination at all, so it's the weaker of the two for building a list.

Results per query: 60 against 120

Google's documentation states that Text Search returns a maximum of 60 results across all pages. The results panel on the Google Maps website, which is what a scraper reads, keeps loading until roughly 120. Google doesn't document that second number, but it has been consistent for years.

Neither figure is a directory. A large city has more dentists than either ceiling, so both methods return a ranked slice and both need the search split into smaller ones. The difference is how much splitting. With a ceiling of 60 you have to cut a city into roughly twice as many pieces before each piece fits under the cap, and through the API every one of those pieces is code you write: the query list, the pagination, the retry when a page token isn't ready yet, and the deduplication afterwards on place ID.

The splitting method itself is the same either way, and it's covered in detail in the guide to the Google Maps 120 results limit: area first, then category, then keyword.

Cost per 1,000 businesses

This is the part most comparisons get backwards. The Places API is not expensive for search. It's billed per request, a request can carry 20 places, and the figures below are from Google's pricing page as of October 2026. The old $200 monthly credit is gone. Since March 2025 each tier has its own free monthly allowance instead.

A worked example. One category across 400 towns is 400 queries and somewhere between 400 and 1,200 requests, depending on how many towns fill more than one page. At the high end, 1,000 of those are free and 200 are billed at 3.5 cents each: $7. Run a second category in the same month and all 1,200 requests are billed: $42.

Two things move the real number away from the best case. Small towns return short pages, and a page with 4 dentists costs the same as a page with 20. And a filter such as "no website" can't be applied in the request, so you pay for every place and discard the ones you didn't want. Text Search accepts a minimum rating, but it has no parameter for whether a business has a website or a phone number. MapsHarvest applies those filters during the scrape and charges only for rows that pass.

Even so, on price per row the API wins, and it's worth saying plainly. What the subscription buys is not cheaper data. It's the 120 ceiling, the per-city loop already built, and a file you keep. For how MapsHarvest's price compares with other scrapers rather than with Google, see the scraper pricing comparison.

The same fields, and which API tier each one sits in

Both routes return largely the same business data, because both come from the same listings. In the API, the fields are sorted into billing tiers, and the ones a sales team cares about most sit in the more expensive tier.

A name-and-address list stays on the Pro tier at $32 per 1,000 requests with 5,000 free. Add a phone number or a website to the field mask and every request moves to Enterprise. Add the description and it moves again, to $40 per 1,000.

MapsHarvest gates fields by plan rather than by request: 9 core fields on the free plan, 13 on Starter, and all 18 on Growth and above. The 18 include four the API doesn't hand you as such, because they describe the scrape rather than the place: the query that found the row, its city, its state, and when it was scraped.

What you're allowed to keep

For a lead list this is the deciding section, and it's the one developers tend to find after the code is written.

Google's Places API policies say you "must not pre-fetch, cache, or store" Places API content beyond listed exceptions. The main exception is the place ID, which you may store indefinitely. The Maps Platform service terms also allow latitude and longitude to be cached for up to 30 consecutive calendar days. There are display rules as well: results shown on a map must be shown on a Google map, and results shown without a map need the Google logo.

Read against that, the usual lead-generation workflow is the thing the policy describes. Pulling every dentist in a state ahead of time is pre-fetching. Saving their phone numbers to a CRM is storing. The compliant pattern is to keep the place ID and call the API again each time you need the details, which suits an app and doesn't suit a call sheet.

Scraping doesn't get a free pass here either, and you should hear that from a company that sells a scraper. Google's general terms discourage automated access to its website. The difference is the kind of agreement involved: an API key means you signed up to a contract with specific storage rules, while a scraper collects what any logged-out visitor can see. How US courts have treated that distinction, and where GDPR comes in for European contacts, is covered in Is scraping Google Maps legal? None of this is legal advice. If the list matters to your business, read both sets of terms yourself.

Which one to use

If what you were really looking for is an API that returns scraped Google Maps rows, so the list-building runs from your own code, that exists too. On MapsHarvest's Growth plan and above, POST /scrape starts a job for a category and a set of states, GET /jobs/{id} reports progress, and GET /jobs/{id}/download?fmt=json returns the rows. The request and filter parameters are on the Google Maps Scraper API page.

FAQ