Zepto Scraper - Extract Product, Price and Stock Data

Fields a Zepto product feed can carry, from MRP to seller licence

Every row starts with three separate identifiers, and confusing them is the usual way a Zepto scraper breaks. The pvid in the address is the product variant: one pack size of one product. Behind it sits a base product id that ties the 1 kg, 2 kg and 4 kg packs of the same line together. Wrapping both is a store product id, the pairing of that variant with one dark store, and the row that actually carries stock and money.

What we lift for each variant:

• Identity: product variant id, base product id, store product id, product name, brand and brand id, primary category, subcategory and L3 category ids, plus the breadcrumb path such as Cleaning Essentials to Detergent Powder and Bars.
• Pack: the printed pack string like 1 pack (2 kg) or 900 g - 1 kg, numeric pack size, unit of measure (KILOGRAM, PIECE, LITRE), weight in grams, shelf life and storage instructions.
• Money: MRP and discounted selling price, discount amount and discount percent, the Super Saver selling price where that tier applies, a store product discount id and a pricing campaign id. Both arrive as integers in paise, so every value needs dividing by a hundred before it matches a printed shelf price.
• Availability: available quantity, out of stock flag, stockout threshold, allocated quantity and the per-order cap, often two or three units.
• Trust: average rating and total rating count, the discount and attribute badges on the tile, and new, primary and best offer flags.
• Compliance: seller name, seller address and seller licence code, FSSAI licence number, country of origin, manufacturer or marketer name and address, minimum required age for the Paan Corner shelves, and the returnable, replaceable and return window flags.
• Content: the description paragraphs, the highlight table as key and value pairs (product type, key features, fragrance, usage instruction, unit), ingredients where present, and the media list marked image or video.

One gap matters for anyone matching across retailers: no barcode is published. There is no GTIN or EAN on the item page, so matching runs on brand, name and pack size, and we hand back the raw pack string beside our parsed grams so you can audit the join.

Why a Zepto crawl is planned by dark store and delivery point

This is the part that decides whether a Zepto data project works. Serviceability is not a list of pin codes: each dark store carries a geofence, and the app resolves a delivery point to a primary store, sometimes a secondary store behind it, sometimes a night store. Every price and stock row is stamped with the store it came from. Two flats on opposite sides of a road can sit in different geofences and see different catalogues.

The city landing pages look like the answer and are not. The Mumbai page and the Delhi page return an identical feed, because with no address set both fall back to the same default store, a Bengaluru dark store the payload names outright. City pages are search landings; only a resolved delivery point moves the catalogue. So coverage is planned as a grid of points, one per store geofence, and every delivered row carries its store id, store name and capture time.

Each resolved point also returns operational fields worth keeping: store open and close times, live and online flags, whether the store is taking orders, a stand still mode, a raining flag, and an ETA in minutes per store, five on a nearby primary store and twenty one on the backup behind it.

Two more habits of the site shape the crawl. Category feeds have no page numbers: paging runs on a continuous widget cursor, so the crawler follows the feed to an end of page flag instead of incrementing a number. And a variant id that no longer exists does not return a clean error page, it renders a friendly fallback pointing back to the home page, so delisted lines must be detected rather than trusted.