Zomato restaurants as JSON, with dining and delivery rated separately

Because Zomato publishes two ratings for the same restaurant and they disagree. One venue measured in this build scored 3.9 for dining from 6,851 reviews and 3.1 for delivery from 21. Any single blended number would be wrong for one of those two audiences, so this API returns rating_dining, rating_dining_count, rating_delivery and rating_delivery_count and lets you choose. rating_delivery is null when a restaurant does not deliver, which was the case for half the detail sample.

No, and the API says so rather than guessing. Zomato does not show dish prices to a signed-out reader: the dish records carry no price at all and the page itself sets a flag saying prices are held back until you sign in. Across 1,690 dishes read from 13 restaurants, not one carried a price. So restaurant/menu returns price_inr as null on every dish, sets prices_published to false and includes a price_note explaining it. What you do get is the complete catalogue: every menu, its categories, and each dish with its name, its description and its veg or vegan tags — 36 to 365 dishes per restaurant in the sample. The restaurant's own cost-for-two figure is separate and is returned in full, as both printed text and a rupee number.

One search returns up to 9 restaurants, and it does not page. That is the source's own ceiling, not a setting: eight different paging approaches were tested against the same listing and every one returned the identical nine restaurants. The count you see in source_total_results is how many restaurants match in that city — 25,603 in Delhi NCR — not how many you can retrieve. Coverage comes from breadth instead of depth: vary the city, the cuisine, the locality and the collection, and each combination returns its own nine. Each response tells you what happened in stop_reason.

Up to 25, the newest first. Zomato serves five pages of five reviews to a signed-out reader and asks for a login after that, measured identically on three different restaurants. The response carries reviews_truncated so you know more exist, and source_number_of_pages, which is Zomato's own page count for a signed-in reader and will be much larger. Each review comes with its text, its star rating, whether it is a dining or a delivery review, its age, the like and comment counts, and the reviewer name and profile link exactly as the public page prints them.

Some of them are ads, and the API flags them. On a plain city listing every one of the nine rows was a paid placement in every city measured. Curated collections were the opposite — a collection listing returned nine rows with no paid placements at all — and delivery listings were mixed at six of nine. Every row carries is_promoted, and each response carries promoted_count and organic_count so you can filter before displaying. Promotional banner tiles that sit inside the grid have no restaurant behind them; they are removed and counted in dropped_tiles.

Pass the city slug Zomato uses in its own URLs: ncr for Delhi NCR, plus mumbai, bangalore, hyderabad, chennai, kolkata, pune, jaipur and the rest. The cities are genuinely separate inventories, not one list filtered: the eight cities measured returned 6,260 to 25,603 matching restaurants each, and all 28 pairwise comparisons of their results shared zero restaurants. If you are not sure what to pass for a neighbourhood, locations/search turns a place name into the localities Zomato knows, with coordinates.

It is Zomato's own estimate of what two people spend, and it comes back both ways: price_for_two_text as the site prints it, and price_for_two_inr as a plain rupee number you can sort on. It is an estimate of a typical bill, not a menu price, and for a bar it can be calculated on drinks. The detail record also returns cost_notes, the full list of cost lines the page shows, because a second line is often a different thing entirely such as the price of a pint rather than a meal. It matched the figure Zomato publishes in its own page data on 12 of 12 restaurants checked.

Most do. In a 16 restaurant sample, 13 returned a dish catalogue and 3 did not; all eight taken from delivery listings had one. The three without a catalogue are dine-in only venues that never took online orders, and for those the API returns a clear not-found rather than an empty list. Those restaurants usually still have a photographed menu, and restaurant/detail lists those menu images under image_menus with a label and page count.

Zomato API is a ReefAPI endpoint group for india's restaurant guide: search a city by cuisine, locality or collection, with dining and delivery ratings kept as separate numbers, plus dish catalogues and review text. It returns live JSON through POST requests under /zomato/v1.

Yes. ReefAPI starts with 1,000 free credits, no card required. Zomato calls use the same shared credit balance as every other ReefAPI engine.

No login to Zomato is needed for the API response. You call ReefAPI with your x-api-key header, and the playground can run live examples before you create a production key.

The page example is captured from a live search call, and production requests fetch live data through ReefAPI rather than a static sample.

Zomato actions currently cost 1-3 credits per successful call. Failed or blocked calls are free. All APIs draw from one credit pool.

Yes. Connect ReefAPI once through MCP and your assistant can call zomato actions with the same key, credit pool and JSON envelope used by normal REST requests.