How to Scrape Zomato and Swiggy Data (Menus and Prices)

Open the same restaurant page from two pins four kilometres apart and you get two different pages. Not slightly different. Different delivery fee, different delivery estimate, sometimes a different set of live items, sometimes no listing at all. Both platforms treat the delivery coordinate as a primary input to pricing and catalog assembly, not a display detail.

Four things move underneath you.

The delivery pin. Distance drives the base delivery fee and the long distance surcharge, and it drives serviceability: a restaurant three kilometres out shows up, the same brand's outlet nine kilometres out does not. In a dense metro like Bengaluru or Mumbai, two pins in the same postal code can hit different outlets of the same chain, with different menus and different prices.

The clock. Menus are time gated. Breakfast items disappear at 11:00 IST, restaurants toggle open and closed, and surge or rain fees appear at peak dinner hours and through monsoon. India runs a single time zone, Asia/Kolkata at UTC+05:30 with no daylight saving, one of the few things here that makes life easier. Store timestamps in UTC, derive IST for analysis, and take the zone from the IANA time zone database rather than hardcoding an offset.

Promotions. Percentage off banners, free delivery thresholds, bank card offers and membership tiers all rewrite the visible price. Strike through price and effective price can differ by 60 percent on the same item at the same moment.

Session state. A logged out guest, a session with a delivery membership, and a session carrying a first order coupon see three different fee stacks. Scrape as an anonymous guest and stay consistent, or your series mixes populations no amount of cleaning separates later.

A price captured without the pin and the capture time is not a data point. It is an anecdote. Everything below exists so you never store one.

Restaurant names, addresses, cuisine tags, menus, item prices, fee components, delivery estimates and offer banners are commercial information about a business. Collecting them from public pages for price research or competitive tracking is the ordinary use case, and the one this guide covers.

Reviewer names, profile photos, profile links and order histories are a different category in India. The Digital Personal Data Protection Act, 2023 governs digital personal data about identifiable individuals, and the implementing rules notified in late 2025 phase the operational obligations in over the following months. The Act carries no broad research or journalism carve out of the kind people assume from GDPR habits, and consent is the default lawful ground. Harvesting reviewer identities at scale to build profiles is exactly what that framework targets.

So draw the line in the schema, not in a policy document nobody reads.

• Collect restaurant, menu, price, fee and availability attributes. Those describe a business.
• Do not create a reviewer identity column. No reviewer_name, no reviewer_id, no reviewer_url, no avatar URL. For sentiment, store the aggregate rating and rating count, which the platforms publish as business metadata, and stop there.
• If you genuinely need review text, store it detached from any identifier and truncate it. Free text still carries names, so treat it as a hazard rather than a free field.
• Both platforms prohibit automated collection and publish crawl directives. Read swiggy.com/robots.txt, zomato.com/robots.txt, the Zomato terms and the Swiggy terms first. Public accessibility is not permission. Two questions, two answers.
• Never place, hold or cancel an order as part of a scrape. Reading a published fee is research. Pushing a cart through checkout to reveal one puts real cost on a restaurant.

One legitimate non scraping source deserves a mention. ONDC, the Open Network for Digital Commerce, defines an open protocol for catalog and price discovery across Indian commerce including food, and participating sellers expose catalogs through it by design. If you need catalog coverage rather than what Zomato and Swiggy specifically charge, that network is the cleaner input, with no bot wall in front of it.

This is engineering guidance, not legal advice. If the output feeds a commercial product, have an Indian data protection lawyer read the schema first.

Decide the key before writing a parser. The composite key for a food delivery observation is (platform, restaurant_id, pin_id, captured_at), with item rows hanging off it. Two tables keep item prices and fees from contaminating each other.

-- Item level: what the menu said, at this pin, at this moment.
CREATE TABLE menu_observation (
  observation_id      BIGSERIAL PRIMARY KEY,
  platform            TEXT NOT NULL,          -- 'swiggy' | 'zomato'
  restaurant_id       TEXT NOT NULL,          -- the platform's own id
  outlet_label        TEXT,                   -- e.g. 'Indiranagar'
  pin_id              TEXT NOT NULL,          -- your pin registry key
  pin_lat             NUMERIC(9,6) NOT NULL,
  pin_lng             NUMERIC(9,6) NOT NULL,
  captured_at         TIMESTAMPTZ NOT NULL,   -- store UTC, render IST
  daypart             TEXT NOT NULL,          -- 'breakfast'|'lunch'|'snack'|'dinner'|'late'
  item_id             TEXT NOT NULL,
  item_name           TEXT NOT NULL,
  item_category       TEXT,
  is_veg              BOOLEAN,
  variant_label       TEXT,                   -- 'Half' / 'Full' / NULL
  base_price_inr      NUMERIC(10,2),          -- list price, before offers
  effective_price_inr NUMERIC(10,2),          -- after item level discount
  in_stock            BOOLEAN,
  menu_hash           TEXT NOT NULL           -- fingerprint of the whole menu
);

-- Order context: the fee stack, once per restaurant per pin per capture.
CREATE TABLE order_context (
  observation_id    BIGSERIAL PRIMARY KEY,
  platform          TEXT NOT NULL,
  restaurant_id     TEXT NOT NULL,
  pin_id            TEXT NOT NULL,
  captured_at       TIMESTAMPTZ NOT NULL,
  is_open           BOOLEAN,
  eta_minutes       INT,
  distance_km       NUMERIC(6,2),
  delivery_fee_inr  NUMERIC(8,2),
  surge_fee_inr     NUMERIC(8,2),
  packaging_fee_inr NUMERIC(8,2),
  platform_fee_inr  NUMERIC(8,2),
  tax_inr           NUMERIC(8,2),
  discount_inr      NUMERIC(8,2),
  offer_text        TEXT,
  min_order_inr     NUMERIC(8,2),
  fssai_licence     TEXT,                     -- published on the menu, business data
  aggregate_rating  NUMERIC(3,2),
  rating_count      INT
);

Notice what is absent. Neither table has a reviewer column. aggregate_rating and rating_count are restaurant properties the platforms publish as business metadata, and that is where the personal data boundary sits. A constraint your loader cannot physically cross beats a rule in a wiki page.

Two more choices worth defending. base_price_inr and effective_price_inr stay separate because a discount is an event, not a price change, and collapsing them destroys any measure of promotional intensity. menu_hash fingerprints the sorted (item_id, base_price, in_stock) tuples, answering "did the menu change" without diffing thousands of rows.

Take the fssai_licence column. Indian food businesses display an FSSAI licence number and both platforms surface it on the menu page, which makes it the most reliable join key between a listing and a real legal entity. Better than fuzzy matching outlet names, and almost nobody collects it.

Both targets sit behind commercial bot management and per IP rate limits, and both punish a foreign exit IP. The SparkProxy Scraping API takes a target URL, routes it through a rotating proxy with optional browser rendering, and returns the response. Five parameters carry this job:

• country_code=IN: exit through an Indian IP. Both platforms are India centric, and a US exit gets you a redirect, a stripped payload or a challenge. This is the single most important parameter here.
• premium_proxy=true: residential IPs. Datacenter ranges draw challenges quickly on both targets.
• render_js: false for the internal JSON endpoints, the fast and cheap path, and true only where a page has to bootstrap a session.
• cookies: pre inject the location and session cookies carrying the delivery pin. This is what makes location control possible without running a browser.
• forward_headers: attach the CSRF token and the app style headers the internal APIs expect.

The base endpoint is https://scrape.sparkproxy.io/api/v1 and auth is a single X-API-Key header. A minimal call:

curl -G "https://scrape.sparkproxy.io/api/v1" \
  -H "X-API-Key: YOUR_API_KEY" \
  --data-urlencode "url=https://www.swiggy.com/dapi/restaurants/list/v5?lat=12.9784&lng=77.6408&page_type=DESKTOP_WEB_LISTING" \
  --data-urlencode "premium_proxy=true" \
  --data-urlencode "country_code=IN" \
  --data-urlencode "render_js=false"

The full parameter list and credit costs are in the Scraping API docs. Everything below reuses one helper:

import json, requests

API = "https://scrape.sparkproxy.io/api/v1"
API_KEY = "YOUR_API_KEY"

def fetch(url, render=False, cookies=None, headers=None, timeout=90):
    params = {
        "url": url,
        "render_js": "true" if render else "false",
        "premium_proxy": "true",
        "country_code": "IN",
    }
    if cookies:
        # list of {"name", "value", "domain"} objects
        params["cookies"] = json.dumps(cookies)
    if headers:
        params["forward_headers"] = json.dumps(headers)
    r = requests.get(API, params=params,
                     headers={"X-API-Key": API_KEY}, timeout=timeout)
    r.raise_for_status()
    return r.text

def fetch_json(url, **kw):
    return json.loads(fetch(url, **kw))

Cost matters at panel scale. A premium request costs 25 credits rendered and 10 unrendered, and a 200 restaurant panel across 8 pins is 1,600 calls per sweep. Bootstrap with rendering once per pin, run the JSON endpoints without it, and the sweep gets roughly 2.5x cheaper.

A pin registry is a small, version controlled table of the coordinates you sample. Treat it like a survey panel definition, because that is what it is. Pick pins that mean something: a dense restaurant cluster, a residential belt three to five kilometres out, and an edge of serviceability pin where fees turn interesting.

PINS = {
    "blr-indiranagar": {"lat": 12.9784, "lng": 77.6408, "city": "bengaluru"},
    "blr-whitefield":  {"lat": 12.9698, "lng": 77.7500, "city": "bengaluru"},
    "blr-jayanagar":   {"lat": 12.9250, "lng": 77.5938, "city": "bengaluru"},
    "mum-bandra-w":    {"lat": 19.0596, "lng": 72.8295, "city": "mumbai"},
    "mum-powai":       {"lat": 19.1176, "lng": 72.9060, "city": "mumbai"},
    "del-hauz-khas":   {"lat": 28.5494, "lng": 77.2001, "city": "delhi"},
    "hyd-gachibowli":  {"lat": 17.4401, "lng": 78.3489, "city": "hyderabad"},
}

Six decimal places is roughly 0.1 metre of precision, more than enough and, more usefully, reproducible. Never let a scraper discover its own coordinates from an IP geolocation lookup. The exit IP moves, the panel silently redefines itself, and every dashboard keeps rendering as if nothing happened.

Swiggy exposes a two step place resolution flow mirroring the address picker in the app. Send a text query, get a place identifier, exchange it for coordinates. Useful when pins are defined by locality name rather than hand picked coordinates.

from urllib.parse import quote

def swiggy_resolve(query):
    """Locality text -> {lat, lng, formatted_address} via Swiggy's own picker."""
    ac = fetch_json(
        "https://www.swiggy.com/dapi/misc/place-autocomplete?input=" + quote(query)
    )
    preds = ac.get("data", [])
    if not preds:
        return None
    place_id = preds[0]["place_id"]
    detail = fetch_json(
        "https://www.swiggy.com/dapi/misc/address-recommend?place_id=" + quote(place_id)
    )
    row = detail["data"][0]
    geo = row["geometry"]["location"]
    return {"lat": geo["lat"], "lng": geo["lng"],
            "formatted_address": row.get("formatted_address")}

Response shapes on these internal endpoints shift between app releases. Open DevTools, filter the network tab by dapi, and confirm key names against a live response before trusting any parser. That habit separates a pipeline that survives a deploy from one that quietly returns empty lists.

Swiggy's web app talks to /dapi/ endpoints and renders the result. Call those endpoints directly and you get something faster, cheaper and far more stable than a React DOM parser. The coordinate is a query parameter, so location control is explicit rather than session dependent, which alone makes Swiggy the easier target.

The listing call returns every serviceable restaurant for a coordinate:

LIST = ("https://www.swiggy.com/dapi/restaurants/list/v5"
        "?lat={lat}&lng={lng}&page_type=DESKTOP_WEB_LISTING")

def swiggy_listing(pin_id):
    p = PINS[pin_id]
    doc = fetch_json(LIST.format(lat=p["lat"], lng=p["lng"]))
    out = []
    for card in doc.get("data", {}).get("cards", []):
        grid = card.get("card", {}).get("card", {}).get("gridElements", {})
        for r in grid.get("infoWithStyle", {}).get("restaurants", []):
            info = r.get("info", {})
            sla = info.get("sla", {})
            out.append({
                "restaurant_id": info.get("id"),
                "name": info.get("name"),
                "area": info.get("areaName"),
                "cuisines": info.get("cuisines", []),
                "aggregate_rating": info.get("avgRating"),
                "rating_count_text": info.get("totalRatingsString"),
                "eta_minutes": sla.get("deliveryTime"),
                "distance_km": sla.get("lastMileTravel"),
                "is_open": info.get("availability", {}).get("opened"),
                "offer_text": (info.get("aggregatedDiscountInfoV3") or {}).get("header"),
                "fee_details": info.get("feeDetails"),
            })
    return out

The nesting looks absurd because Swiggy ships a generic card layout engine and the restaurant list is one card type inside it. Iterate defensively with .get() at every level instead of indexing: card ordering changes between releases, and an index based parser dies on a layout experiment nobody tells you about.

The menu call takes the same coordinates plus the restaurant id, and complete-menu=true returns the whole catalog rather than the first screen:

MENU = ("https://www.swiggy.com/dapi/menu/pl?page-type=REGULAR_MENU"
        "&complete-menu=true&lat={lat}&lng={lng}&restaurantId={rid}")

ITEM_CARD = "type.googleapis.com/swiggy.presentation.food.v2.ItemCategory"
NESTED    = "type.googleapis.com/swiggy.presentation.food.v2.NestedItemCategory"

def swiggy_menu(pin_id, restaurant_id):
    p = PINS[pin_id]
    doc = fetch_json(MENU.format(lat=p["lat"], lng=p["lng"], rid=restaurant_id))

    groups = []
    for card in doc.get("data", {}).get("cards", []):
        gmap = card.get("groupedCard", {}).get("cardGroupMap", {})
        groups += gmap.get("REGULAR", {}).get("cards", [])

    items = []
    for g in groups:
        c = g.get("card", {}).get("card", {})
        buckets = []
        if c.get("@type") == ITEM_CARD:
            buckets = [(c.get("title"), c.get("itemCards", []))]
        elif c.get("@type") == NESTED:
            buckets = [(sub.get("title"), sub.get("itemCards", []))
                       for sub in c.get("categories", [])]
        for category, cards in buckets:
            for ic in cards:
                info = ic.get("card", {}).get("info", {})
                # Swiggy sends paise. Divide by 100 or publish a 27,900 rupee dosa.
                base = info.get("price") or info.get("defaultPrice") or 0
                final = info.get("finalPrice") or base
                items.append({
                    "item_id": str(info.get("id")),
                    "item_name": info.get("name"),
                    "item_category": category,
                    "is_veg": info.get("isVeg") == 1,
                    "base_price_inr": round(base / 100, 2),
                    "effective_price_inr": round(final / 100, 2),
                    "in_stock": info.get("inStock", 1) == 1,
                })
    return items

That paise comment is not a joke. Swiggy returns integer paise, Zomato returns rupees, and mixing the two in one warehouse table is the most common bug in food delivery datasets. Normalize at ingest, never at query time, and assert that no item over 5,000 rupees reaches a dashboard.

Variants need a decision. A dish with Half and Full portions arrives as a variantsV2 structure with its own price ladder, and the top level price may cover the base variant only. Flatten each variant into its own row with variant_label set, or record only the base and accept the undercount. Flattening earns its rows, because portion mix hides a lot of real pricing behaviour.

Zomato is stricter. The consumer brand is still Zomato, though the listed parent renamed itself Eternal Limited in 2025, which matters only if you join this data against financial filings.

Two things make Zomato harder. The delivery location lives in a cookie rather than a query parameter, so a session bootstrap has to happen before any data call means anything. And the internal webroutes endpoints expect a CSRF token the page mints, so a cold request without one is rejected.

Bootstrap once per pin, then reuse:

import re, json

def zomato_session(pin_id):
    """Render the homepage once to mint cookies, then pin the location."""
    p = PINS[pin_id]
    html = fetch("https://www.zomato.com/", render=True)

    m = re.search(r'window\.__PRELOADED_STATE__\s*=\s*JSON\.parse\(\s*"(.+?)"\s*\)',
                  html, re.S)
    state = json.loads(json.loads('"%s"' % m.group(1))) if m else {}
    csrf = state.get("pageData", {}).get("csrf") or state.get("csrf")

    # The location cookie is what makes every later response location aware.
    locus = json.dumps({
        "addressId": 0, "lat": p["lat"], "lon": p["lng"],
        "cityId": 0, "ltv": 0, "lty": "", "fetchFromCookie": False,
    }, separators=(",", ":"))

    cookies = [
        {"name": "locus", "value": locus, "domain": ".zomato.com"},
        {"name": "zl",    "value": "en",   "domain": ".zomato.com"},
    ]
    headers = {"x-zomato-csrft": csrf} if csrf else {}
    return cookies, headers

Field names inside __PRELOADED_STATE__ and the exact cookie payload move between releases, so verify both in DevTools against a live session rather than trusting the snippet blind. The structural point survives the churn: Zomato encodes the delivery pin in a cookie, so nothing you fetch means anything until it is set, and the same URL without it returns a city default belonging to nobody's real pin.

With a session in hand the page payload comes back as JSON:

def zomato_page(path, cookies, headers):
    url = "https://www.zomato.com/webroutes/getPage?page_url=" + path
    return fetch_json(url, cookies=cookies, headers=headers)

def zomato_menu(res_path, pin_id):
    cookies, headers = zomato_session(pin_id)
    doc = zomato_page(res_path + "/order", cookies, headers)

    order = doc.get("page_data", {}).get("order", {})
    menus = order.get("menuList", {}).get("menus", [])

    items = []
    for menu in menus:
        for grp in menu.get("menu", {}).get("categories", []):
            cat = grp.get("category", {})
            for it in cat.get("items", []):
                info = it.get("item", {})
                items.append({
                    "item_id": str(info.get("id")),
                    "item_name": info.get("name"),
                    "item_category": cat.get("name"),
                    # Zomato sends rupees, not paise.
                    "base_price_inr": float(info.get("display_price")
                                            or info.get("price") or 0),
                    "in_stock": not info.get("is_disabled", 0),
                })
    return items

If a Zomato path resists a direct JSON call, render the page with render_js=true and pull __PRELOADED_STATE__ out of the HTML instead. It costs 25 credits instead of 10, but it survives a webroutes change because the browser fires whatever the current call happens to be. The general technique is in How to Scrape Hidden JSON API Endpoints, and the cookie mechanics in Handle Cookies and Sessions in Web Scraping.

Here is the mistake that wrecks food delivery analysis. Someone scrapes item prices, sees a stable 249 rupee biryani for six weeks, and reports flat pricing. The real cost to the customer moved 40 rupees, because delivery fee, platform fee and a surge charge all shifted underneath. Item price is one line in a stack, and the stack is where the movement lives.

Swiggy puts a fee breakdown on the restaurant object inside the listing response, the cheapest place to get it, because one listing call covers every restaurant at that pin:

FEE_MAP = {
    "BASE_DELIVERY": "delivery_fee_inr",
    "BASE_TIME": "delivery_fee_inr",
    "BASE_DISTANCE": "delivery_fee_inr",
    "ANCILLARY_SURGE_FEE": "surge_fee_inr",
    "SURGE_FEE": "surge_fee_inr",
    "RAIN_FEE": "surge_fee_inr",
}

def parse_fee_stack(fee_details):
    """Swiggy feeDetails -> normalized rupee columns. Unknown names are kept."""
    stack = {"delivery_fee_inr": 0.0, "surge_fee_inr": 0.0, "other_fees": {}}
    if not fee_details:
        return stack
    for f in fee_details.get("fees", []):
        rupees = round((f.get("fee") or 0) / 100, 2)
        col = FEE_MAP.get(f.get("name"))
        if col:
            stack[col] += rupees
        else:
            stack["other_fees"][f.get("name")] = rupees
    stack["total_fee_inr"] = round((fee_details.get("totalFee") or 0) / 100, 2)

    known = stack["delivery_fee_inr"] + stack["surge_fee_inr"]
    known += sum(stack["other_fees"].values())
    stack["reconciles"] = abs(known - stack["total_fee_inr"]) < 0.51
    return stack

Keeping unrecognised fee names in other_fees instead of dropping them is the whole trick, and the reconciles flag makes it actionable. Both platforms add line items without notice, and a parser that silently discards what it does not recognise reports a total that stops matching its parts. Alert on reconciles == False and you hear about a new fee the day it launches, not the quarter after.

Two India specific realities belong in your notes. Since 1 January 2022, tax on restaurant services supplied through these platforms is paid by the platform rather than the restaurant, under the e-commerce operator provisions administered by the CBIC, which is why the tax line behaves like a platform charge. And listed menu prices exclude the platform's fee stack, so the number on a card is never the number paid. Proxies for Grocery and Delivery Prices covers quick commerce, where the same fee logic applies to a different catalog.

Restaurant menus are not documents that occasionally get edited. On these platforms they are live inventory. Items go out of stock mid service and return an hour later, categories appear at breakfast and vanish by noon, and a catalog rework changes forty item ids at once.

Full snapshots every sweep answer every question but cost rows. Diffs alone lose the ability to reconstruct a menu as of a date. The compromise that holds up: snapshot every item row every sweep, and compute a menu_hash so unchanged sweeps are trivial to detect and cheap to compress later.

import hashlib

def menu_hash(items):
    """Stable fingerprint of a menu's priced, in-stock shape."""
    tuples = sorted(
        (str(i["item_id"]), f"{i['base_price_inr']:.2f}", str(i["in_stock"]))
        for i in items
    )
    blob = "|".join(":".join(t) for t in tuples)
    return hashlib.sha256(blob.encode()).hexdigest()[:16]

Then classify what moved, so a reprice never gets confused with a stockout:

def diff_menu(prev, curr):
    p = {i["item_id"]: i for i in prev}
    c = {i["item_id"]: i for i in curr}
    events = []
    for iid in c.keys() - p.keys():
        events.append(("added", iid, None, c[iid]["base_price_inr"]))
    for iid in p.keys() - c.keys():
        events.append(("vanished", iid, p[iid]["base_price_inr"], None))
    for iid in p.keys() & c.keys():
        if p[iid]["base_price_inr"] != c[iid]["base_price_inr"]:
            events.append(("reprice", iid,
                           p[iid]["base_price_inr"], c[iid]["base_price_inr"]))
        if p[iid]["in_stock"] != c[iid]["in_stock"]:
            kind = "back_in_stock" if c[iid]["in_stock"] else "out_of_stock"
            events.append((kind, iid, None, None))
    return events

The event is vanished rather than removed on purpose, because a missing item is ambiguous: delisted, hidden because the kitchen is closed, or absent because your capture landed on a daypart that does not serve it. Never write a "menu shrank" conclusion from one sweep. Require absence across three sweeps at the same daypart and pin before calling it a delisting, which is why daypart is a column rather than something derived later.

Cadence that has held up: menus once or twice daily per pin, order context every 60 to 120 minutes during service hours, plus a peak sweep between 19:30 and 21:30 IST where surge pricing shows itself. Sampling only at 03:00 because the servers are quiet gives you a beautifully clean dataset about a time when nothing is open.

The failure mode is rarely a CAPTCHA on request one. It is a panel that quietly degrades, returning empty lists for one pin while the others look fine, unnoticed for a fortnight because the job keeps exiting zero.

Practices that keep a panel honest:

• Assert pin variance in CI. After every sweep, check that at least two pins report different delivery fees for the same chain. If every pin agrees exactly, location control has stopped working and every row from that sweep is suspect. This one assertion catches more silent breakage than all your parser unit tests combined.
• Sample restaurants, do not crawl the universe. A tracked panel of 150 to 400 restaurants answers pricing questions at a fraction of the request volume of enumerating every listing.
• Stagger by pin. Fire all seven pins in the same second from the same subnet and you look exactly like what you are. Randomize pin order, leave 3 to 8 seconds between calls.
• Sticky exit per pin. Hold one exit IP per pin for a whole sweep so the cookie, the coordinates and the IP tell a consistent story. What Does Geo Targeting Mean in Proxies covers the mechanics.
• Archive a raw sample. Keep the unparsed JSON for one restaurant per pin per sweep. When a parser breaks three weeks later, that archive names the release that changed the shape.
• Fail loudly. A sweep returning under 60 percent of the expected restaurant count should raise, not log a warning nobody reads.

The discipline transfers. How to Scrape OpenTable Data covers the reservation availability equivalent, and How to Scrape Yelp Business Data the review aggregator side, where the personal data boundary is the one drawn above.