Quick-Commerce Data API for Blinkit, Zepto, and Instamart

A quick-commerce data API for Blinkit, Zepto, and Swiggy Instamart must answer a location-specific question: what could a shopper see at a known place and time? CPG and data teams use that record to study price, availability, promotions, assortment, and search visibility. A nationwide product list without fulfillment context is not an adequate substitute.

Define the API contract before collection

Evaluate an API on location resolution, catalog and search coverage, field definitions, source identifiers, timestamping, refresh behavior, delivery reliability, normalization, product matching, and retained evidence. Decide whether the unit of observation is a product page, a search result, or a category placement; each answers a different business question.

Why location is part of the primary key

Zepto’s official product pages explicitly say availability depends on stores serving the shopper’s location and ask users to enter a delivery address; see its milk listing. Swiggy says Instamart orders are processed through dark stores on itsofficial business page. Its FY2026 AGM filing says Instamart reached 1,143 stores across more than 125 cities, reinforcing that the network is geographically distributed; see the official filing.

Blinkit’s official milk category pageshows price, pack size, discounts, options, and stock labels and lists delivery cities. These pages demonstrate visible commerce fields, but they do not constitute public developer-API specifications. This guide describes the schema a managed dataset should provide, not an official API offered by those marketplaces.

Normalized quick-commerce observation

{
  "marketplace": "blinkit",
  "source_product_id": "…",
  "source_url": "https://…",
  "location": {
    "input_type": "postal_code",
    "input_value": "560001",
    "resolved_area": "Bengaluru",
    "fulfillment_node": null
  },
  "observed_at": "2026-08-19T09:30:00Z",
  "product": {
    "brand": "…", "title": "…", "pack_size": 500, "pack_unit": "ml"
  },
  "offer": {
    "currency": "INR", "list_price": 48, "selling_price": 46,
    "promotion_text": "₹2 OFF", "in_stock": true
  },
  "placement": {
    "surface": "search", "query": "milk", "organic_rank": 4,
    "sponsored": false
  },
  "delivery": { "eta_text": "…" },
  "evidence": { "capture_id": "…", "parser_version": "…" }
}

A platform may not expose a dark-store identifier. In that case, store the tested address or postal code and the platform-resolved area; do not invent store-level precision. Keep display text beside normalized values so analysts can audit coupons, bundles, and ambiguous stock labels.

Collection method

1. Create a stable location panel representing target cities and neighborhood types.
2. Resolve each location in a fresh, controlled session and record the displayed area.
3. Collect product, category, and keyword surfaces at scheduled timestamps.
4. Normalize units and offers while preserving source-native labels and captures.
5. Match exact and variant SKUs across platforms with reviewable attribute evidence.
6. Run completeness, duplicate, drift, and cross-refresh anomaly checks before delivery.

What teams can calculate from the observation layer

• On-shelf availability: in-stock observations divided by eligible observations, by SKU and location.
• Price and promotion consistency: compare like-for-like packs across platforms and neighborhoods.
• Share of search: brand placements divided by captured placements for a defined keyword panel.
• Assortment gaps: matched products present on one service but absent from another at the same location.
• Refresh-to-refresh changes: additions, removals, price moves, and stock transitions with timestamps.

Each metric needs an explicit denominator. “Availability” can mean listed anywhere, listed at a tested address, or purchasable at collection time. “Rank” can mean an organic position or a visual slot including sponsored items. Publish these definitions alongside the API so dashboards do not quietly compare different concepts.

What a POC must prove

Limitations

Availability, price, promotions, rank, and ETA can change with address, inventory, time, account state, and experimentation. App-only content may differ from public web pages. Sponsored labels can change. A POC cannot guarantee continuous future collection, and delivery-node identity should remain unknown unless directly observed. Refresh rates must match the decision: hourly monitoring is unnecessary for some assortment studies and insufficient for some campaign audits.

Request a three-platform sample dataset

Review PLOTT’s pages for Blinkit, Zepto, and Instamart; inspectgeographic variation fields; and see theCPG brand use case. Request a sample covering the same 25–50 SKUs and keywords across representative locations on all three services, with timestamps, raw evidence, normalized records, and match labels. That dataset is the right starting point for an API decision.