Every team that needs Google Maps data at any real volume hits the same fork: build a scraper, pay for the official Places API, or pay per row for a data API. The first two options both carry ongoing cost that doesn't show up on the sticker price. The third is a flat rate you can compute before you run anything.
If you're an agent (or building one) reading this rather than a human, the full machine-readable schema for every endpoint below lives at mindcase.co/skills.md.
What does it actually take to build your own Google Maps scraper?
More than the first script suggests. Google's Maps interface enforces a results cap around 120 listings per search — a real constraint every DIY scraper and third-party tool alike has to work around, whether that means splitting one search into several narrower ones or accepting a partial result set. That's before accounting for the two ongoing costs that actually determine whether this is worth it:
- Layout maintenance. Google's Maps markup changes without notice, and a scraper built against today's DOM breaks against next month's — not once, but repeatedly, for as long as you keep running it.
- Terms of Service exposure. Google's Maps Platform Terms of Service govern how this data can be collected and used. A scraper that pulls directly from the Maps interface — rather than through Google's own API or a vendor operating within those terms — carries real compliance risk that a per-row API call doesn't.
Neither of these is a one-time setup cost. They're upkeep on infrastructure that isn't your product, for as long as the scraper stays in service.
Why doesn't the official Google Places API solve this for free?
It solves the legal-exposure problem — you're calling Google's own API, under Google's own terms — but it doesn't solve the engineering-time problem, and it adds one of its own. The Places API bills per field category (basic listing data, contact fields, and "atmosphere" fields like rating and price level are separate, individually-priced SKUs under your Google Cloud billing account), which means the fields you actually need decide which pricing tier you're on before you've written a line of integration code. You still own the request logic, the pagination, the retry handling, and a Google Cloud project to manage it all through.
That's a real, working option — it's just a different kind of ongoing work than a scraper, not the absence of one.
What does the Mindcase alternative actually look like?
One call, no Google Cloud project, no SKU tier to figure out first.
curl -X POST "https://api.mindcase.co/v1/data/google-maps/places/run?wait=true" \
-H "Authorization: Bearer $MINDCASE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"params": {
"keywords": "commercial real estate agency",
"location": "Miami, Florida",
"maxResults": 100
}
}'
# $0.004 per placeEvery row from Places API already carries all 55 fields — no separate SKU for contact info or rating, no field-level billing decision to make. Reviews API works the same way: one place URL in, 31 fields per review out, at $0.00025 a review.
Where's the real cost crossover?
Say maintaining a Maps scraper realistically costs you 4 engineering hours a month in fixes and adjustments, at a fully-loaded $75/hour rate — $300/month, before it's returned a single row. At Mindcase's $0.004 per place, that $300 buys 75,000 place lookups. Below that volume, the per-row API is cheaper outright. Above it, the comparison stops being about price per row and becomes about whether you want engineering time going toward maintaining a scraper instead of your own product.
That 4-hours/$75 figure is an illustrative assumption, not a benchmark — your own maintenance burden depends on how often you touch the scraper and who's fixing it. The math holds regardless of what numbers you plug in: a fixed monthly cost divided by a per-row price gives you the volume where each option wins.
What can't you get from Mindcase?
Two cases.
A business with no Google Maps listing has nothing to return. Coverage depends on the business being on Maps in the first place — true for a scraper, the official API, or Mindcase alike, since none of them can return a listing that doesn't exist.
You need a custom field Google doesn't expose to anyone. Places API returns what's on the public listing page — the same ceiling the official Google API and every third-party tool share. Nothing built on top of Google Maps gets you data Google itself doesn't publish.
Which endpoint should you use for which job?
| Endpoint | Input | Price | Best for |
|---|---|---|---|
| Places | Keyword + location, or place URLs | $0.004 / place | Replacing a scraper or the official Places API for listing search |
| Reviews | One place URL | $0.00025 / review | Review text, without a separate scraper for that alone |
A 100-place search costs $0.40. At that rate, the build-vs-buy math favors buying until your volume is genuinely large enough that engineering time is the cheaper resource — which, for most teams pulling Maps data occasionally rather than continuously, it isn't.
FAQ
No. Mindcase doesn't sit on top of the official Places API, so there's no Google Cloud billing account, project, or SKU tier to set up. You call the Mindcase endpoint with your Mindcase API key.
It depends on which fields you need and Google's current per-SKU pricing, which we don't control or track. What Mindcase offers instead is one flat per-row price with every field included, so the comparison doesn't require working out a field-by-field SKU cost first.
$0.004 per place from the Places API, $0.00025 per review from the Reviews API.
Places API returns up to maxResults per call, same as any tool that queries Google Maps search. For a single keyword-and-location search, splitting into more specific queries is still the way to get past what one search returns.