Build India Food Delivery Coverage with Swiggy (2026)

Thirdwatch's Swiggy Scraper makes India food-delivery coverage research a structured workflow — 100-city tier-1/2/3 expansion tracking, restaurant-density analysis, cuisine-diversity benchmarks, new-city detection. Built for India ecommerce expansion research, India F&B investment, food-delivery aggregator builders, and India retail-investment functions.

▶ Skip the setup: Run this as a ready-to-go task on Apify → — pre-loaded with the exact configuration from this guide. No code required.

Why build India coverage with Swiggy

Swiggy is the deepest India food-delivery coverage source. According to Swiggy's 2024 IPO prospectus, the platform operates in 600+ cities with 50% tier-1 + 60%+ tier-2/3 market share — material gap-fill from urban-only platforms like Zomato. For India ecommerce + F&B research teams, Swiggy provides the canonical multi-tier India coverage signal.

The job-to-be-done is structured. An India F&B investment fund maps tier-2/3 expansion velocity for retail-thesis development. A India ecommerce expansion-strategy function studies cross-city dynamics for client expansion-planning. A India food-delivery aggregator builder ingests multi-city Swiggy data for marketplace seeding. A QSR (Quick Service Restaurant) chain plans India tier-2/3 expansion via Swiggy density signals. All reduce to multi-city queries + cross-tier benchmarking.

How does this compare to the alternatives?

Three options for India food-delivery coverage data:

The Swiggy Scraper actor page gives you raw real-time multi-city Swiggy data at materially lower per-record cost.

How to build coverage in 4 steps

Step 1: Authenticate

export APIFY_TOKEN="apify_api_xxxxxxxxxxxxxxxx"

Step 2: Pull tier-1/2/3 city batches quarterly

import os, requests, datetime, json, pathlib

ACTOR = "thirdwatch~swiggy-scraper"
TOKEN = os.environ["APIFY_TOKEN"]

INDIA_CITIES = [
    # Tier 1
    {"city": "Bangalore", "lat": 12.9716, "lng": 77.5946, "tier": 1},
    {"city": "Mumbai", "lat": 19.0760, "lng": 72.8777, "tier": 1},
    {"city": "Delhi", "lat": 28.6139, "lng": 77.2090, "tier": 1},
    {"city": "Hyderabad", "lat": 17.3850, "lng": 78.4867, "tier": 1},
    # Tier 2
    {"city": "Jaipur", "lat": 26.9124, "lng": 75.7873, "tier": 2},
    {"city": "Lucknow", "lat": 26.8467, "lng": 80.9462, "tier": 2},
    {"city": "Nagpur", "lat": 21.1458, "lng": 79.0882, "tier": 2},
    # Tier 3
    {"city": "Indore", "lat": 22.7196, "lng": 75.8577, "tier": 3},
    {"city": "Coimbatore", "lat": 11.0168, "lng": 76.9558, "tier": 3},
    {"city": "Kochi", "lat": 9.9312, "lng": 76.2673, "tier": 3},
]

resp = requests.post(
    f"https://api.apify.com/v2/acts/{ACTOR}/run-sync-get-dataset-items",
    params={"token": TOKEN},
    json={"locations": INDIA_CITIES, "maxResults": 200},
    timeout=3600,
)
records = resp.json()
ts = datetime.datetime.utcnow().strftime("%Y%m%d")
pathlib.Path(f"snapshots/swiggy-india-coverage-{ts}.json").write_text(
    json.dumps(records)
)
print(f"{ts}: {len(records)} restaurants across {len(INDIA_CITIES)} India cities")

10 cities × 200 = 2,000 records per snapshot.

Step 3: Compute per-tier density + diversity benchmarks

import pandas as pd

df = pd.DataFrame(records)
city_to_tier = {c["city"]: c["tier"] for c in INDIA_CITIES}
df["tier"] = df.city.map(city_to_tier)

tier_metrics = (
    df.groupby("tier")
    .agg(
        restaurant_count=("restaurant_id", "nunique"),
        cuisine_diversity=("cuisine", "nunique"),
        avg_rating=("rating", "mean"),
        chain_pct=("is_chain", "mean"),
    )
    .reset_index()
)
print(tier_metrics)

# Per-city restaurant density (assuming 50sqkm coverage radius typical Swiggy zone)
per_city = (
    df.groupby("city")
    .agg(
        restaurant_count=("restaurant_id", "nunique"),
        density_per_sqkm=("restaurant_id", lambda x: x.nunique() / 50),
    )
    .reset_index()
    .sort_values("restaurant_count", ascending=False)
)
print(per_city)

Step 4: Detect new-city launches + expansion velocity

import glob

snapshots = sorted(glob.glob("snapshots/swiggy-india-coverage-*.json"))
all_dfs = []
for s in snapshots:
    df = pd.DataFrame(json.loads(open(s).read()))
    df["snapshot_date"] = pd.to_datetime(s.split("-")[-1].split(".")[0])
    all_dfs.append(df)
combined = pd.concat(all_dfs, ignore_index=True)

city_velocity = (
    combined.groupby(["city", "snapshot_date"])
    .restaurant_id.nunique()
    .unstack(fill_value=0)
    .pct_change(axis=1)
    .iloc[:, -1]
    .sort_values(ascending=False)
)

rising = city_velocity[
    city_velocity >= 0.5
]  # 50%+ restaurant growth quarter-over-quarter
print(
    f"{len(rising)} cities with 50%+ Swiggy restaurant-count growth (expansion-velocity signal)"
)
print(rising.head(10))

Sample output

{
  "restaurant_id": "abc12345",
  "name": "Truffles - Indiranagar",
  "city": "Bangalore",
  "tier": 1,
  "lat": 12.9784,
  "lng": 77.6408,
  "rating": 4.4,
  "cost_for_two": "₹600",
  "cuisine": "Continental, American",
  "is_chain": true,
  "delivery_time": "30-35 min",
  "url": "https://www.swiggy.com/restaurants/truffles-indiranagar"
}

Common pitfalls

Three things go wrong in India coverage pipelines. Lat/lng-zone-coverage variance — Swiggy assigns ~5km service-radius per restaurant; for accurate density research, segment query-radius before benchmarking. Tier-classification drift — India city-tiers shift as cities grow (Pune moved Tier-2 → Tier-1 in 2018); for accurate longitudinal research, use 2024 city-tier baseline. Chain vs local detection — chain-detection requires brand-name mapping (McDonald's, Domino's, etc.); maintain canonical chain-name list with 50-100 known India QSR chains.

Thirdwatch's actor uses HTTP + lat/lng queries with pay-per-result pricing. Pair Swiggy with Zomato (separate actor coming) for Tier-1 cross-platform coverage. A fourth subtle issue worth flagging: Swiggy's "Cloud Kitchen" partner-restaurants (Rebel Foods, Box8) appear as multiple-brand listings from one physical kitchen — for accurate physical-restaurant coverage, dedupe by lat/lng with 100m radius. A fifth pattern unique to India coverage: rural areas (population <100K) have minimal Swiggy presence — for accurate tier-3 research, focus on tier-3 cities with 100K+ population. A sixth and final pitfall: India festival cycles (Diwali, Onam, Durga Puja) drive 30-50% temporary order-volume spikes; for accurate base-rate coverage research, exclude festival windows from longitudinal analysis.

Operational best practices for production pipelines

Tier the cadence: Tier 1 (active expansion-research watchlist, monthly), Tier 2 (broader India coverage, quarterly), Tier 3 (long-tail tier-3 cities, semi-annually). 60-80% cost reduction with negligible signal loss when watchlist is properly tiered.

Snapshot raw payloads with gzip compression. Re-derive density + diversity metrics from raw JSON as your tier-classification logic evolves. Cross-snapshot diff alerts on city-restaurant-count velocity catch expansion-cycle inflection points.

Schema validation. Daily validation suite asserting expected core fields with non-null rates above 80% (required) and 50% (optional). Swiggy schema occasionally changes during platform UI revisions — catch drift early. A seventh pattern at scale: cross-snapshot diff alerts for new-city detection (cities with 0 → 50+ restaurants in 7-day window) catch India expansion-velocity signals before they appear in Swiggy investor calls. An eighth pattern for cost-controlled teams: implement an incremental-diff pipeline that only re-processes records whose hash changed since the previous snapshot. For watchlists where 90%+ of records are unchanged between snapshots, hash-comparison-driven incremental processing reduces downstream-compute by 80-90% while preserving full data fidelity.

A ninth pattern unique to research-grade data work: schema validation should run continuously, not just at pipeline build-time. Run a daily validation suite that asserts each scraper returns the expected core fields with non-null rates above 80% (for required fields) and 50% (for optional). Alert on schema breakage same-day so consumers don't degrade silently.

A tenth pattern around alert-fatigue management: tune alert thresholds quarterly based on actual analyst-action rates. If analysts ignore 80%+ of alerts at a given threshold, raise the threshold. If they manually surface signals the alerts missed, lower the threshold.

An eleventh and final pattern at production scale: cross-snapshot diff alerts. Beyond detecting individual changes, build alerts on cross-snapshot field-level diffs — name changes, category re-classifications, status changes. These structural changes precede or follow material events and are leading indicators of organization-level disruption. Persist a structured-diff log alongside aggregate snapshots: for each entity, persist (field, old_value, new_value) tuples per scrape. Surface high-leverage diffs to human reviewers; low-leverage diffs stay in the audit log.

A twelfth pattern: cost attribution per consumer. Tag every API call with a downstream-consumer identifier (team, product, feature) so you can attribute compute spend back to the workflow that drove it. When a downstream consumer's spend exceeds projected budget, you can have a precise conversation with them about the queries driving cost rather than a vague "scraping is expensive" debate.

Related use cases

• Scrape Swiggy restaurants for India research
• Monitor Swiggy vs Zomato India pricing
• Track India real estate prices with MagicBricks
• The complete guide to scraping food delivery
• All Thirdwatch use-case guides