Yelp business search and reviews without Yelp Fusion
Businesses and reviews as JSON. Not Yelp Fusion. Not the merchant dashboard.
Yelp Fusion is the official partner API. Keys, partner status, the Fusion docs. yelp.fetcher.sh is not Fusion. Search by query and location, resolve a handle, fetch a place and its reviews, as JSON. Public listing data. Not the owner dashboard, not delivery, not Waitlist, not advertising.
Restaurants are the same objects with a vertical label. Maps is the other review corpus. Local SEO is the combined watch.
Four paths: search, handle lookup, place by id, reviews on a place. Search requires both query and location. Sort is recommended, rating, or reviewCount. That is enough to build a shortlist. It is not a reservation system.
Business, handle, reviews
Query plus location, sorted by rating or review count. Resolve a handle. Fetch a place and its reviews.
curl -H 'Authorization: Bearer bby_live_…' 'https://yelp.fetcher.sh/api/search?query=ramen&location=San+Francisco&sortBy=rating'
Handle lookup is how you go from a Yelp vanity URL to a place id. Maps remains a second corpus, not a fallback parameter on this host. Fusion keys and the merchant dashboard are different products.
Do not send latitude and longitude as Yelp’s location. That field is a city or area string — San Francisco, Austin, TX — not a Maps pin. The text vs coordinates note is a Maps note. Mixing the two hosts’ search shapes is the usual 400.
Page through search with page when the first screen is not enough. Store the place id before you fetch reviews. A handle can change; the id is what reviews hang off.
How a listing actually gets used
Editors want categories, rating, review count, and whether the place is obviously a chain. Ops people want the newest unhappy reviews. Neither group wants to log into the merchant dashboard, because they are not the merchant.
Categories on Yelp are listing metadata. They are not an inventory of tables. “Late night” vs “omakase” is a filter you apply after search, in your own code, using the category fields. sortBy=rating is not “best for a date.” It is a sort key. Read the reviews before you publish a recommendation.
If the same block of street also matters on Google Maps, pull both. The text will not match. The ratings will not match. That disagreement is the signal, not a bug.
A case: ramen in San Francisco, sorted by rating
A travel editor needs a shortlist, not a reservation. They search ramen in San Francisco, sort by rating, and pull reviews on the top three. They do not need Fusion. They do not need the owner dashboard. They need categories, rating, and what the last dozen reviewers actually said.
They keep “tourist trap” and “worth the wait” as phrases they grep for. They drop a 4.9 with twelve reviews if the 4.6 with two thousand reads as a real restaurant. Sort-by-rating without a review-count floor is how city guides go wrong. The JSON makes that floor easy: you have both numbers.
If they also pull Maps reviews for the same block, they have moved into local SEO monitoring. If they need OpenTable, they are outside this catalog.
A case: a handle from a press email
Someone on the team forwards a Yelp link and asks “is this us?” The URL has a handle, not an id. Search by name would return cousins and chains.
They hit /api/place/handle/{handle}, store the id, then fetch the place and the reviews. If it is them, they add the id to the monitoring list. If it is a different shop with a similar name, they have not accidentally subscribed to the wrong reputation feed.
Fusion would have done the lookup too, with a partner key. This host does it as public JSON. The merchant dashboard still exists for responding to reviews as the owner. That is not this API.
sortBy=reviewCount is the other featured example for a reason. A travel editor who only sorts by rating will publish the 5.0 with nine reviews. The most-reviewed ramen shop is the one the city has already argued about. Pull both sorts, take the intersection, then read. Pagination with page is how you get past the first screen without pretending search returned the whole city.
Delivery and Waitlist remain Yelp products you log into as a diner or a merchant. JSON listings will not tell you whether a table is free at 8pm. If the editor’s pitch was “we book for you,” they need a reservation API we do not sell.
Fusion vs public listings
Use Fusion if you are a partner and you need what only Fusion gives partners. Use this host if you want public business and review JSON without that key. Docs on the host; pay the GET or send a key from /topup.
Yelp the consumer site is still the UI. We are not a reskin of yelp.com. We return the listing objects as data so you can watch them, rank them for a guide, or diff them on a schedule.