# Restaurant and hospitality listings as JSON 2026-08-21 > Yelp and Google Maps listings and reviews. Not reservations. Not delivery. Not OpenTable. - Index: https://fetcher.sh/blog.md - This page (HTML): https://fetcher.sh/blog/restaurant-hospitality-listings-as-json ![A diner eating a steak in a restaurant](https://images.unsplash.com/photo-1414235077428-338989a2e8c0?auto=format&fit=crop&w=1600&q=80) Photo by Jay Wennington on [Unsplash](https://unsplash.com/?utm_source=fetcher_sh&utm_medium=referral). If you need restaurant listings as data, the public objects are already on Yelp and Google Maps: rating, review count, location, categories. [yelp.fetcher.sh](https://yelp.fetcher.sh) and [google-maps.fetcher.sh](https://google-maps.fetcher.sh) return those as JSON. This catalog does not sell DoorDash, OpenTable, Resy, or reservation APIs. Listings and reviews only. Instagram food photos are not the product. A geotag on a Reel is not a table. Hospitality teams still ask for “the restaurant API.” What they usually mean is: search a city by cuisine, sort, read reviews, keep categories straight. That is Yelp search plus Maps as a second opinion. [Local SEO](/blog/local-seo-maps-yelp-review-monitoring) is the same pair when the restaurant is *yours* and you are watching it. This note is the pair when you are writing about *other people’s* kitchens — guides, research, competitive sets. ## The vertical slice of local places Search ramen in a city, sort by rating, pull reviews. Same paths as the Yelp and Maps access notes. The difference is the question: “restaurant reviews API,” not generic Places. `curl -H 'Authorization: Bearer bby_live_…' 'https://yelp.fetcher.sh/api/search?query=ramen&location=San+Francisco&sortBy=rating'` Categories on Yelp are listing metadata, not a reservation inventory. `sortBy=reviewCount` surfaces the places a city has already argued about. `sortBy=rating` surfaces the shiny ones. Use both, then read. On Maps, `query=ramen in brooklyn` or a pin plus `query=ramen` if you already have a point. Store fids. Do not expect Yelp ids to work on Maps. Hours in a listing are a snapshot, not a live wait-time. Closed-for-renovation will show up in reviews before it shows up in a structured field you can trust. Read the text. ## What a city guide actually needs A guide is not a database of every kitchen. It is a shortlist with reasons. The reasons live in review sentences: “worth the wait,” “too salty,” “went downhill after the chef left.” Star ratings without text are how every listicle looks the same. Keep delivery apps out of the model. A high DoorDash rating and a high Yelp rating are not the same object, and we do not return DoorDash. Keep reservation availability out. If the editor needs a table tonight, they need OpenTable or a phone, not this JSON. If a kitchen is also a brand on Instagram, that is a different host and a weaker substitute for a rating. Pretty plating is not a hygiene score. ## A case: a city guide that refuses to scrape the UI An editor is updating a ramen guide. They search the city, sort by rating, pull reviews, and keep categories so “late night” does not mix with “omakase.” They do not call OpenTable. They do not estimate wait times. They publish listings and what reviewers said. Last year’s number three has a new one-star cluster about a menu change. That is in the JSON. The Maps listing still looks fine in a screenshot because nobody on the team opened Yelp. Dual corpus, or you publish a ghost. They store ids so next quarter’s update is a diff, not a from-scratch search. New openings show up when they search again; old ids that 404 or look abandoned get a human pass. ## A case: a hotel concierge desk with a spreadsheet A front desk used to keep a Google Doc of “places we send guests.” It rotted. They now keep Yelp ids and Maps fids, refresh reviews monthly, and flag anything that picked up a health-department story in the text. They still recommend with human taste. They just do not recommend a place that has been on fire in the reviews since March. No delivery ETA. No “we booked you a table.” Listings and reviews as a briefing, then the phone. Seasonal menus show up in Yelp categories slowly and in review text immediately. “Omokase” misspellings, “late night,” “vegetarian omakase” — grep the text; do not wait for a category to appear. Maps reviews will talk about wait time in a way Yelp will talk about parking. Dual corpus, or the guide is one-eyed. Chains need extra confirmation on the id. “Joe’s” in a city is a trap. Handle lookup from a URL the restaurant itself tweets is safer than search by name. [Yelp without Fusion](/blog/yelp-business-search-reviews-without-fusion) is that lookup. A guide editor’s quarter: search, both sorts, reviews on the shortlist, store ids, diff against last quarter. Opening-week watches belong on [local SEO](/blog/local-seo-maps-yelp-review-monitoring) if the restaurant is yours. This note is other people’s kitchens. Reservations still are not JSON we sell. Call the restaurant. ## What we do not sell No delivery ETAs. No reservations. No inventory. No POS. Listings and reviews. Stay here when the reader is hospitality, not a generic local pack, and when the output is a guide or a watch — not a booking flow. Docs on the two hosts. Pay per GET or a key from [/topup](/topup). If you needed the merchant tools to *reply* as the restaurant, you want Yelp and Google as the owner, not this catalog.