Turning Blinkit and Zepto Prices into a Live Feed

A product's price on Blinkit, Zepto, or Instamart isn't one number. It's whatever a specific dark store was showing at the moment you asked — list price, discount, and stock, all tied to a pincode. Two stores five kilometers apart can legitimately show different prices for the same SKU at the same time. There's no public feed for this. If you want it, you pull it yourself, per store, on a schedule.

If you're an agent (or building one) reading this rather than a human, the full machine-readable schema for every endpoint below lives at mindcase.co/skills.md.

What makes quick-commerce price data hard to get any other way?

No web-scraping blog covers this. Apify and Monid — the two largest scraping-tool blogs, between them hundreds of posts on Amazon, Google Maps, LinkedIn, every major social platform — have zero posts on Blinkit, Zepto, or Instamart. That's not an oversight. These are India-specific quick-commerce apps with no public catalog API, no bulk export, and pricing that's meaningless without a store attached to it. A generic e-commerce scraper built for Amazon or Shopify has nothing to plug into here — there's no product-listing page to point it at without a resolved dark store first.

The scale of "resolved" is the actual obstacle. Blinkit alone covers 253 cities and roughly 2,100 dark stores; Zepto covers 82 cities and about 1,200 stores; Instamart covers 145 cities and around 1,200 stores. A national brand isn't watching one price — it's watching however many of those stores actually carry its product, each one a separate call with its own price, discount, and stock answer.

How do you find your product across all three platforms?

Blinkit, Zepto, and Instamart don't share one input shape. Blinkit lets you search by keyword directly. Zepto splits keyword search and direct-URL lookup into two separate endpoints. Instamart's product endpoint is URL-only — there's no keyword search on the assignment used here.

How do you search by keyword?

curl -X POST "https://api.mindcase.co/v1/data/blinkit/products/run?wait=true" \
-H "Authorization: Bearer $MINDCASE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
  "params": {
    "query": "Amul Gold Milk",
    "city": "Bangalore",
    "pincode": "560034",
    "maxResults": 20
  }
}'

# $0.001 per product returned

Zepto Search takes the same shape — query, city, pincode, maxResults — for the same reason: you don't have a product URL yet, only a name.

How do you pull a specific product when you already have its URL?

Instamart Products and Zepto Products both work from a URL instead of a keyword — useful once you've already found the product once and just want a fresh price/stock read:

curl -X POST "https://api.mindcase.co/v1/data/instamart/products/run?wait=true" \
-H "Authorization: Bearer $MINDCASE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
  "params": {
    "urls": ["https://www.swiggy.com/instamart/item/abc123"],
    "city": "Bangalore",
    "pincode": "560034"
  }
}'

# $0.001 per product returned

All four endpoints return the same 25 fields regardless of platform — price, mrp, discount, inStock, stockCount, rating, storeId, and 18 more — so a row from Blinkit and a row from Instamart line up in the same table without any reshaping on your end.

How do you target a specific dark store?

Every one of these calls needs a location. Pass city and pincode together, or lat/lon directly, or skip straight to a known store_id if you're re-checking the same store repeatedly — Blinkit alone has over 2,100 of them mapped. Store-level targeting is the whole point: a citywide average price is useless if you're trying to catch one store quietly discounting below MRP.

How do you turn a snapshot into a live feed?

Each call returns what that store shows right now — there's no history endpoint, no time-series field. You build the feed by re-running the same query on a schedule (hourly is reasonable for quick-commerce, where prices and stock genuinely move that often) and keeping every pull. The price, mrp, and inStock fields are what you diff between runs to catch a discount starting, a stock-out, or a competitor undercutting your own MRP at a specific store.

A concrete version of that diff: say your 10:00am pull for a product at store 34748 returns price: 95, mrp: 100, inStock: true, and your 11:00am pull for the same product and store returns price: 75, mrp: 100, inStock: true. Nothing else changed — the discount jumped from 5% to 25% in an hour. That's a promotion starting, or a reseller undercutting MRP, and you'd know within the hour instead of finding out from a customer complaint. The same diff catches the opposite case: inStock flipping from true to false at one store while staying true at the next one over means that specific store is out, not the product generally — useful to know before you escalate a supply issue that's actually just one dark store's inventory.

What can't you get from Mindcase?

Two cases.

A store you haven't targeted. These are store-scoped by design — there's no "all of Bangalore" call. Covering a city means calling the endpoint once per store or pincode you care about, not once total.

A price from before you started pulling. There's no historical pricing endpoint on any of the three platforms. Your first pull is your earliest data point — the feed only covers what you were actually watching.

Which endpoint should you use for which job?

FAQ