# Google Maps places and reviews without a Places API key 2026-08-18 > Place search, details, and reviews as JSON. Not Places API, not Cloud billing, not Apple Maps. - Index: https://fetcher.sh/blog.md - This page (HTML): https://fetcher.sh/blog/google-maps-places-reviews-without-places-api-key ![A folded paper map spread on a table](https://images.unsplash.com/photo-1524661135-423995f22d0b?auto=format&fit=crop&w=1600&q=80) Photo by cardmapr.nl on [Unsplash](https://unsplash.com/?utm_source=fetcher_sh&utm_medium=referral). Google Places API bills through Cloud. That is the right tool if you are already on GCP and need the official SKU: session tokens, photo billing, the whole console. It is a lot of setup if you only want public place search, details, and reviews as JSON. [google-maps.fetcher.sh](https://google-maps.fetcher.sh) returns those without a Places API key. Public listing data. Not Apple Maps, not Business Profile management, not a geocoding SKU, not driving directions. A “map” here is Google Maps the product, not a hashmap. [Text versus coordinates](/blog/place-search-text-query-vs-coordinates) is how you search. [Local SEO](/blog/local-seo-maps-yelp-review-monitoring) is the job that consumes both Maps and Yelp. [Restaurants](/blog/restaurant-hospitality-listings-as-json) are the same objects with a hospitality label. Four paths, and that is the whole host: search, place by fid, reviews on a place, a single review by id. Enough for a reputation feed. Not enough to replace a navigation SDK. ## Place, rating, review Search by query. Fetch a place by fid. List reviews. Fetch a review by id. `curl -H 'Authorization: Bearer bby_live_…' 'https://google-maps.fetcher.sh/api/place/search?query=coffee+in+brooklyn'` Search by text when a human typed a place name. Pin latitude and longitude when you already have a point. Reviews hang off a place fid — the `0x…:0x…` identifier Maps uses, not a street address and not a Yelp id. Optional `languageCode` and `countryCode` exist on search and on place fetch if you need a specific edition of the listing. We do not manage Business Profiles. We do not return Apple Maps. We do not turn “123 Main Street” into a lat/lng SKU. If you needed routing, you are in a different product. The envelope is the usual `{ status, message, data }`. A missing place is JSON, not a Maps UI empty state. Pay with 402 or a prepaid key from [/topup](/topup), same as every other host. ## How to read a listing without pretending you have Places API What you typically want from a public Maps page: name, rating, review count, address-ish text, and the review bodies. That is enough to decide “is this cafe a problem” or “does this location still exist.” What you do not get: photo billing SKUs, Place Photos as a Google Cloud product, session-token discounted autocomplete, or the ability to write a review as a signed-in user. Those are Places API and consumer Google, respectively. Keep Yelp ids out of Maps paths. Keep Play Store app ids out of place search. The most common integration bug is stuffing a Yelp handle into `fid`. It will not parse. Maps fids look like `0xhex:0xhex`. Search first, store the fid, then fetch details and reviews. If you already have coordinates from a phone, do not force the user to type a neighborhood. Pin the query. That split is the [coordinates note](/blog/place-search-text-query-vs-coordinates). If you already have a city string and a cuisine, Yelp’s `query` + `location` is often the more natural search — and a second corpus, not a fallback parameter on this host. ## A case: coffee near the office, then the reviews An ops lead is picking a cafe for a visiting team. They search `coffee in brooklyn`, pick a fid, and pull reviews. They are not building a maps product. They are not enabling Cloud billing for Places. They want rating, a few review texts, and a decision by lunch. If they already have the office coordinates, they pin the search instead of relying on the neighborhood string. They read the last dozen reviews for “wifi,” “loud,” “closed.” They do not need photos billed per request. They do not need Autocomplete. They need to not send the visitors to a place that has been a one-star pile-on since Tuesday. If they also pull Yelp, they have moved into [local SEO monitoring](/blog/local-seo-maps-yelp-review-monitoring). That is a second host and a second id. Worth it for a shop they own. Optional for a one-off lunch. ## A case: a multi-location brand that only screenshotted Maps A small coffee group used to screenshot Google Maps once a week and paste the rating into a spreadsheet. They missed a week. They missed a review that named an employee. The screenshot workflow does not page. It does not diff. It does not survive vacation. They store a fid per shop. A weekday job hits `/api/place/{fid}/reviews`, keeps the review ids they have already seen, and posts new text to a channel. They still look at the Maps UI when they want the consumer experience. They do not use the UI as a database. Places API would have done this too, with Cloud billing and a key in a project someone has to own. This host does it as public JSON without that project. If they later need official Place Photos at volume, they can graduate to Cloud. The monitoring job does not have to wait for that. A second shop in the group is inside a mall. Text search for the shop name returns the mall, a kiosk, and a similarly named chain in another borough. They pin the mall coordinates plus `query=` the shop name, then confirm the fid against a Maps URL a manager pasted. Pins plus a name beat a name plus a city when the name is common. That is still this host; the [coordinates note](/blog/place-search-text-query-vs-coordinates) is the search-mode deep dive. Reviews in another language edition are a `languageCode` choice, not a different place. If the visiting team reads Japanese, fetch the listing that way. It is not Apple Maps. It is not a translation SKU. ## Places API vs this host Official Places API still exists if you need it. This host is the public JSON path without Cloud. Docs: [google-maps.fetcher.sh](https://google-maps.fetcher.sh). Same 402 or prepaid key as the rest of the catalog. Use Cloud if you are building a maps-heavy product and you want Google’s official SKUs, SLAs, and photo pipeline. Use this host if you want listings and reviews as data and you do not want to stand up billing to get them.