Google Places API Pricing Explained (Plus Cheaper Alternatives)

How Google Places API pricing is structured

The official Places API is billed per request, in units of 1,000 requests, with a different price for each SKU. A SKU is not an endpoint. It combines the request type (Text Search, Nearby Search, Place Details, Autocomplete) with the group of fields you asked for. Cheap groups cover identifiers and coordinates; expensive groups cover contact details, opening hours, ratings and reviews.

The prices are published on Google's pricing page and change from time to time, so this article does not repeat them. The shape is what matters: identifier-level requests cost a few dollars per 1,000, detail-level SKUs cost tens of dollars per 1,000, and a monthly free allowance is applied per SKU. The usage and billing page is the authoritative reference; read it before estimating.

Why field masks decide what a Place Details request costs

Every request to the newer version of the Places API carries a field mask, a list of the fields you want back. The most expensive field in the mask sets the SKU for the whole request. Ask for the name and the coordinates and you pay the entry-level rate; add the phone number or the website and the request moves up a tier; add opening hours, rating or reviews and it moves up again.

This has two consequences for anyone estimating a places api cost. First, a Place Details request that returns a complete business record is always billed at the top of the scale, because a complete record needs fields from the top tier. Second, savings come from asking for less, not from calling less, and most business-data projects cannot ask for less. A lead list without a phone number or a website is not much of a lead list.

Text Search and Nearby Search follow the same logic: the mask applies to every place in the response, so a search that returns 20 places with contact-level fields is billed once at the contact-level rate for the search, and each place you then open in Place Details is billed again.

A worked example: 1,000 business records in requests

Suppose you want 1,000 restaurants in one city with name, address, phone, website, rating and opening hours. The table counts requests rather than dollars, because the request counts stay true when the prices change.

To put a figure on the left column, multiply the current per-1,000 price of the detail-level SKU by the 1,000 details requests, add the search requests at their own rate and subtract whatever free allowance remains that month. On the right, 2,000 credits sits inside the Basic plan at $9 a month; the pricing page lists the credits each plan includes. Before running the job, GET /v1/places/count with the same query is free and tells you whether the first page was full (at_least: true) or the whole answer (exact: true).

The cost that is not on the invoice: caching and storage limits

The per-request price is half of the total. The Google Maps Platform terms restrict what you may do with the content once you have it: place IDs may be stored indefinitely, but most other fields may only be cached for a limited period, after which they must be fetched again. For a consumer map that shows a business when a user taps it, that rule is harmless. For a directory, a CRM import, a lead list or a change-detection job, it means paying for the same record on every refresh cycle.

There is also an attribution requirement and a rule against using the data to build a competing places database. This is not legal advice; the terms change, so read the current version before designing anything that stores results. The general question of what you may collect and keep is covered in the article on whether web scraping is legal.

When the official Places API is the right choice

The official API is the right choice in four cases, and switching away from it in any of them costs more than it saves.

• You are showing places to end users inside a map or an app, with Google attribution, and the data never leaves the session. That is exactly the licensed case.
• You need Autocomplete as a user types, with latency measured in tens of milliseconds. No scraping-based service matches that.
• Your volume fits inside the monthly free allowance. A small internal tool that looks up a few hundred places a month may never see a bill.
• You need a contractual SLA and enterprise support, or procurement requires a vendor of that size.

The cases that do not fit are the bulk ones: prospect lists, market surveys, directory builds, and anything that needs an email address, a social profile or a WhatsApp number, which the official API does not return at any price.

Google Maps API alternatives, and how to compare them

The alternatives fall into three groups. Compare them on four questions: what fields come back, whether you may keep them, how the vendor gets the data, and what a full record costs once every add-on is included.

When you compare scraper-style vendors against each other, add up the add-ons. Many price the base record cheaply and charge separately for contact enrichment, emails or extra fields, so the advertised per-1,000 figure is rarely the figure you pay. Price a complete record from each vendor's pricing page, not a base one. Then check how they collect the data: a vendor that describes working around blocks or challenges is describing a service that can disappear without notice, and Locomint's own rule is that a 403 or a challenge page ends the request.

What the same records cost on Locomint

Locomint bills in credits with one price per operation, and enrichment is part of the details call rather than an add-on. A search costs one credit per place returned. A details call costs one credit and returns everything the record has: all seven days of hours, description, photo_urls, attributes, and an enrichment block with emails, socials, whatsapp and website_status read from the business website. Unknown IDs return 404 and cost nothing. The free plan gives 200 credits a month with no card; paid plans are Starter at $19, Growth at $59 and Scale at $149.

The search step for the worked example, as a single request:

curl "https://api.locomint.io/v1/places/search?q=restaurant&location=Manchester,%20United%20Kingdom&limit=50" \
  -H "X-API-Key: $LOCOMINT_KEY"

The same job in Python with httpx: page through the search until next_page is null, then fetch full records, and stop when the monthly quota is reached. The API reserves the request's worst-case cost before doing any work, so the 402 quota_exceeded arrives before anything is charged.

import httpx

API = "https://api.locomint.io/v1"
headers = {"X-API-Key": "lm_free_your_key_here"}
records = {}

with httpx.Client(base_url=API, headers=headers, timeout=30) as client:
    page = 1
    while True:
        r = client.get("/places/search", params={
            "q": "restaurant",
            "location": "Manchester, United Kingdom",
            "limit": 50,
            "page": page,
        })
        if r.status_code == 402:
            break
        body = r.json()
        for summary in body["data"]:
            records[summary["place_id"]] = summary
        if not body["pagination"]["next_page"]:
            break
        page += 1

    for place_id in list(records):
        r = client.get(f"/places/{place_id}")
        if r.status_code == 402:
            break
        full = r.json()
        records[place_id] = full
        print(full["name"], full.get("phone"), full["hours"],
              (full.get("enrichment") or {}).get("emails"))

The search reference lists the other parameters, including language for localised names and lat, lng, radius for coordinate search. Always write the location as "City, Country": in our canary runs a bare "Warsaw" resolved to Warsaw, Indiana, and every place on that page would have cost a credit. meta.geocoded_location on the first response shows what the search resolved to.

Where to start this week

Count the businesses you need, decide which fields you cannot do without, and note how long you need to keep the records. If the fields fit in a cheap field mask, the volume fits in the free allowance and the data is only displayed to users, use the official API.

If you need contact fields, need to keep the records, or need thousands of them, run the same city through Locomint's free plan and compare the results by eye. Two hundred credits covers a 100-place search plus 100 full records, enough to see the field coverage and the enrichment yield for your market. The status page shows the daily canary success rate and latency for the source; read it before committing to a plan.

Frequently asked questions

Does the Google Places API have a free tier?

Yes. Google grants a monthly free allowance that is applied per SKU, so a small prototype or a low-traffic app can run without a bill. Bulk jobs use it up quickly, because a single pass over one city can mean hundreds of search requests and a details request per business. Check the current allowance on Google's pricing page, because it has changed shape more than once.

Can I store Google Places API results in my own database?

Only within the limits of the Google Maps Platform terms. Place IDs may be stored indefinitely; most other content may only be cached for a limited period and then has to be refreshed from the API. That rule is what makes the official API expensive for directories, lead lists and change tracking, where keeping the record is the whole point. Read the current terms before you design your storage.

Is Locomint a Google product or affiliated with Google?

No. Locomint is an independent service that reads public, logged-out business listings and enriches them from the business's own website. It is not affiliated with or endorsed by Google. It does use the same place identifiers, so a record from Locomint and a record from the official API refer to the same business and can be joined on place_id.