Lead Finder by WappBlaster

Places API vs scraping, for lead lists

The Places API is the correct answer to a different question. Here is where the official route genuinely wins, and the arithmetic that explains why list-builders keep ending up off it.

Last reviewed

Where the API wins outright

Building Maps data into a product? Use the Places API and close this tab. It is the licensed route: stable structured responses, documented fields, uptime somebody is paid to defend, and no interface changes breaking you overnight. Every scraper on earth, ours included, trades those guarantees away. For software that ships to users, that trade is wrong, and any scraping vendor who tells you otherwise is selling you a support ticket.

The question this page actually decides is narrower: you want a prospect list in a CRM, worked by people. Three axes settle it.

Axis 1: cost shape

API billing is per request, and a lead list is request-hungry in a specific way: an area sweep needs hundreds of search calls (the grid, see axis 2), then a detail call per business for the fields a list actually needs, phone and website first. Thousands of billable calls per category-metro, times every refresh. The monthly free credit absorbs a test, not a pipeline. Metered cloud scrapers share the shape at lower rates; flat-licence desktop extraction exists as the escape from the shape itself, which is why the three-model comparison keeps reducing to volume arithmetic.

Axis 2: the caps are universal

Nearby Search returns at most 60 results per query, three pages of 20. The public interface manages roughly 120. Neither number is about scraping; place search is depth-limited everywhere, and complete coverage through any route means subdividing the territory and merging. The API difference is that every grid cell is a billable call, so thoroughness, the thing that makes a list complete, is exactly what the meter charges for. Under a flat licence the incentive points the other way, and the incentive difference shows up in the data as coverage.

Axis 3: what you may keep

The quiet decider. Google Maps Platform terms restrict caching Places content beyond limited windows and restrict exporting it into third-party systems, and a prospect list is retained, exported data by definition: it lives in your CRM, gets worked for months, and feeds refresh diffs. Many teams discover this axis after building on the API, at migration cost. Scraping carries its own legal posture (covered honestly here: generally lawful to collect, against Google's ToS as a contract matter, outreach law governing use), but retention of what you extracted is not among its problems.

The decision, compressed

  • Data inside a product or service you ship: Places API. Licensed, stable, correct.
  • A one-off small integration test: Places API on the free credit. It is genuinely good at this.
  • Prospect lists, worked in a CRM, refreshed: extraction. Then the remaining choice is pricing shape: metered cloud if you need scheduling and APIs, flat desktop if a person runs sweeps, per the comparison.
  • Both needs at once: both tools. API in the product, extraction for the pipeline. They are answers to different questions, which is the whole point of this page.

Frequently asked

Is the Places API better than scraping?
For building software, yes, unambiguously: it is licensed, stable, structured and supported, and no scraper offers any of those guarantees. For building prospect lists the calculus inverts on three axes: per-request billing scales with thoroughness, Nearby Search caps at roughly 60 results per query, and the terms restrict retaining and exporting what you fetch, which is the entire point of a lead list. Right tool for products, expensive and legally awkward tool for lists.
What does the Places API cost for lead generation volumes?
Pricing changes, so do the arithmetic with current rates rather than trusting any page, but the shape is stable: place searches and detail requests bill per call, a metro sweep needs hundreds of area queries plus a detail call per business for fields like phone and website, and a single thorough city extraction can consume the monthly free credit on its own. Refreshing quarterly multiplies everything by four. Flat-licence extraction exists precisely because this curve made list-building through the API uneconomic.
Does the API avoid the 120-result limit?
It has a stricter one. Nearby Search returns up to 60 results (three pages of 20), against roughly 120 on the public interface. Complete coverage through the API means the same grid subdivision technique scrapers use, just with each cell costing billable requests. The ceiling is a property of place search generally, not of scraping.
Am I allowed to store Places API data in my CRM?
Read the current Google Maps Platform terms before building anything, because this is the constraint people discover late: the terms restrict caching and retaining most Places content beyond limited windows, and restrict exporting it into third-party systems. A prospect list is by definition retained, exported, worked data. That tension, not the pricing, is often the decisive reason list-builders end up off the API. This page is general information, not legal advice.