Zomato is two datasets in one site. The first is the one it started as: public restaurant pages with ratings, reviews, menus and prices, built for a city and a locality, indexed by search engines and read by everyone from diners to analysts. The second is the delivery marketplace built on top, where the storefront for a locality shows which of those restaurants deliver there, at what price and fee, right now. The parent company, renamed Eternal in 2025, reported about 297,000 average monthly active restaurant partners across more than 800 Indian cities in its FY25 annual report (Medianama, July 2025). Both datasets exist per locality, and 800 cities is a lot of localities.
Zomato's front door stayed open in our test on 24 August 2026, which is unusual in this cluster and does not mean the site is easy. What follows treats the Indian free-proxy pool honestly, because that is where most readers of this page will start.
The direct answer
Indian residential proxies pinned to the city of the localities you read, driving a real browser, each locality held in its own session. For a restaurant-partner login, one static ISP proxy per account. The homepage opens for a datacenter exit, as our test showed, and the restaurant and delivery endpoints behind it are where a shared address is throttled.
Zomato as a target
Restaurant pages: name, cuisine, rating, review count, menu with prices, photos, hours, per locality. These are the pages the whole Indian restaurant-analytics market reads, from aggregators and rating trackers to academic studies of urban food economies.
Delivery storefronts: set a locality and the site shows which restaurants deliver, delivery fee, estimate, offers and Gold benefits. Prices here can differ from the menu on the restaurant page.
Blinkit: the quick-commerce arm, priced per dark store, a separate site and app.
Zomato is a JavaScript application on the client side. Restaurant pages render server-side enough for search engines to index them; the delivery view and much of the detail arrive through Zomato's own API calls keyed to the locality in the session.
Jobs a proxy is right for
- Restaurant data at city scale. Ratings, review counts, cuisines, price levels and menus across a city or across 800 cities, on a schedule, for aggregators, analysts and researchers. This is the job the public Zomato scrapers on marketplaces like Apify are built for.
- Delivery price and fee monitoring. What a restaurant charges on delivery versus its menu, plus fees and estimates, per locality. Chains audit their own listings; price-intelligence firms build the dataset.
- Coverage by locality. Which restaurants reach a locality and at what estimate, for site selection and competitor mapping.
- Offer and Gold research. Which offers and membership perks show in which cities and when they rotate.
- Zomato against Swiggy. The same restaurant on both platforms at the same locality, which is the comparison Indian restaurateurs ask for most; the Swiggy side is in proxies for Swiggy.
Jobs a proxy is not for
Delivery-partner accounts. Identity and bank verification.
Reviews. Posting or manipulating reviews from many addresses is fraud, not research, and we refuse it.
Credits farmed across accounts. Accounts are linked by phone, payment and device, and farming credits runs against Zomato's terms.
The door, measured
zomato.com served our German datacenter server its real homepage on 24 August 2026, HTTP 200, no challenge page, no bot-vendor marker we could name. Of 20 elite HTTP proxies from our free proxy list, one call per proxy, 18 were dead on arrival and 2 loaded the homepage. So the door is open, and what defends the site is the metering behind it: restaurant and delivery endpoints that a diner calls a few times and a script calls thousands of times. We have not measured that limit. Log the first rising 403 or 429 rate per exit and treat it as the number; fixing 429 rate limits through a proxy covers the back-off.
The 18 that never connected say something too. Our free pool is thin in India and the addresses that exist there die fast, so a job that starts from free proxies starts from almost nothing. Free India proxy explains the pool honestly.
Indian residential exit
same city
Homepage
open door
Locality set
sticky session
Restaurants, prices, fees
record locality and time
Type by job
| Zomato job | Proxy type | Why |
|---|---|---|
| Restaurant data at city scale | Rotating Indian residential, city-pinned | Reads as a local; survives the metering behind the open door |
| Delivery price and fee monitoring | Rotating Indian residential, sticky per locality | The storefront is built per locality |
| Coverage by locality | Rotating Indian residential, sticky per locality | Each locality is one session |
| Offer and Gold research | Rotating Indian residential, city-pinned | Offers are per city |
| Restaurant-partner login | Indian ISP (static residential) | One fixed, trusted location per account |
| One manual look at one restaurant page | Datacenter, or a fresh free proxy | The homepage answered; a sweep will not survive |
Background: datacenter vs residential proxies.
Free proxies here
Two of twenty, and the eighteen that never connected are the real number. The free pool in India is small and short-lived, so even a single manual look is a matter of luck; the live count on our free proxy list filtered to India tells you the odds before you try. For a city sweep, our Indian residential proxies start at $0.44/GB, pay as you go, no KYC.
Setup
- Indian residential exit, city-pinned. A Bengaluru locality from a Bengaluru exit. The metering keys on the address, and a local address reads like a local diner.
- Real browser for the delivery view, plain fetches for restaurant pages if you must. Restaurant pages render enough to parse; the delivery storefront needs the API calls a browser makes. The Playwright proxy guide covers the launch.
- Sticky session per locality. Set the locality, read the storefronts you track, record locality and timestamp, rotate. Sticky vs rotating proxy sessions explains the difference.
- Pace for a thin pool. Indian residential pools are smaller than US ones, so each exit is reused more; read slower per exit and grow the pool rather than the rate. More in avoiding IP bans while scraping.
Sizing
Restaurant data for 5 cities, refreshed monthly:
restaurant pages per city ~8,000
pages per exit per hour ~40, paced
exits in rotation ~30-40 Indian residential, city-pinned
Delivery price watch, 3 cities, weekly:
localities per city 15
pages per locality session ~10
exits in rotation ~15 Indian residential
Restaurant pages with images blocked are small and bandwidth is the meter, so the page count sets the bill; our pricing carries no subscription and no expiring balance.
Where it ends
What the exit supplies is an Indian address in the right city; it does not verify a delivery partner, it does not make review manipulation into research, and it does not make scraping compatible with Zomato's terms, which prohibit it. With that settled, a city-pinned residential exit lets a legitimate data job read public restaurant pages and delivery storefronts the way diners in each locality see them: one locality per session, human pacing, and a block rate you log.
The other half of the Indian market has a very different door: proxies for Swiggy, where the site answers with a challenge you will not see on Zomato. The rating-and-review side of the job, in a US frame, is in proxies for Yelp.
Sources
- Medianama, July 2025, Eternal FY25 annual report highlights (about 297,000 average monthly active restaurant partners; more than 800 cities; Blinkit; Zomato Gold): medianama.com
- HProxy measurement, 24 August 2026: one direct request from a datacenter server (HTTP 200, homepage) and 20 elite HTTP proxies from our free proxy list (18 no connection, 2 homepage).