A Blinkit price is a dark store price. Move the pin a few kilometres and the shelf, the discount and the promised minutes all change, so we collect the catalogue address by address.
You give us the addresses or pin codes, the categories, brands or product ids, the fields you need and a cadence. We design the schema, build the crawler, run it, watch it and repair it when the storefront moves, and you receive files rather than a repository. Output is CSV, JSON, XLSX, a Google Sheet, a direct database load or a Blinkit API endpoint we host and you call, delivered over email, S3, SFTP or webhook.
Anti-bot handling, proxy rotation and CAPTCHA solving are part of the service and never become your problem. Coverage is planned as a grid of delivery points rather than one call per city, because two pins in one city hit two different dark stores. We stay on public pages, never touch cart, checkout, payment or account areas, honour the paths the site closes to crawlers, and collect no personal data - no customer names, no rider identities, no addresses of private individuals.
The unit of work is a product card resolved against one store. Every card carries a numeric product id, the product name and display name, the brand, the pack unit exactly as printed (200 g, 1 ltr, 6 pcs, 2 x 100 g), the selling price, the MRP it is struck through against, the percentage off, and an integer stock count for that store. Cards also carry a group id that ties pack sizes of one item together, so 100 g, 200 g, 750 g and a twin pack roll up into a single variant family instead of four unrelated rows.
Alongside price we keep the merchant id and merchant type of the store that answered, the eta identifier and the promised minutes, the l0, l1 and l2 category strings, the product type, a rating where one is shown, the availability state, and the per-order cap that limits how many units a card will let you add. Badges are worth carrying too: the count of pack options behind a card, promotional labels such as percentage off, and the nutrition claims that ride on the image, for example a protein-per-100 g flag.
The item page adds the regulated block that Indian retail requires and most feeds skip. Under the details panel a Blinkit product page prints Key Features, Ingredients, a marketing description, Unit, FSSAI Licence, Shelf Life, a Disclaimer, Customer Care Details, Country of Origin, the Manufacturer's Name and Address, the Return Policy, a sugar profile where it applies, plus the Seller and the Seller FSSAI licence. Because the seller is whichever entity fulfils from that dark store, one item can show a different seller and a different licence in two cities. The same page emits schema.org Product, BreadcrumbList and ImageObject blocks, with price, INR currency and availability, which makes the identifier easy to verify row by row.
Blinkit sells far more than groceries, and the extra shelves are where the feed stops looking like every other grocery export. The front page lists shop-by-store entries for toys, books, pets, party, beauty, print, electronics, stationery, kids, pharma and sports. Paan Corner carries cigarettes, cigars, hookah needs, lighters, ashtrays and non-tobacco blends, and it is gated: the storefront sends an age consent flag with each request, so an age-restricted aisle either appears or it does not.
Print Store takes an uploaded file and delivers paper. It quotes Rs 3 a page in black and white and Rs 10 in colour, works only on A4 at 70 GSM, accepts up to fifteen files of fifty MB each, and exposes colour mode, single or double sided, orientation and copy count as settings. Blinkit Ambulance is dispatched through the same layout engine, and its units only resolve for some places - they came back on an NCR address and not on a Mumbai one, exactly the sort of gap a city-by-city crawl is built to catch.
Seasonal merchandising is a separate axis from the permanent taxonomy. Beside the standing category shelves the collection tree holds sets built for the calendar - Rakhi picks, Ganesh Chaturthi, Father's Day - along with e-gift cards and gift packs that appear and vanish with the festival. Category pages also publish a price list block: ten named items with rupee prices and a stamped update date, rebuilt from the same store-resolved catalogue. Brand pages roll a brand's live range together with a similar brands rail, and recipe pages run into the thousands, each a basket of ingredients mapped back to product ids.
Blinkit is the quick commerce business of Eternal, the Indian group that also owns Zomato, District and Hyperpure. The operator on the invoice is Blink Commerce Private Limited, registered in Gurugram, and the Grofers years are still visible in the plumbing: product photography is served from cdn.grofers.com, the Android build id is com.grofers.app, and the storefront loads Zomato's payment kit. On a product page the seller of record is often Zomato Hyperpure Private Limited, printed with its own FSSAI licence under the item, so Blinkit data and the group's supply chain are the same story seen from two ends.
The model is dark store, not warehouse shipping. Every order is picked from a small neighbourhood store and promised in minutes, which means the shelf on screen belongs to one store rather than to the brand. Blinkit's own seller hub currently describes a network of more than two thousand dark stores across more than three hundred cities, and the storefront advertises a range in the tens of thousands of items. A category page names roughly forty delivery cities, from Delhi, Mumbai and Bengaluru down to Bhiwadi, Kharar and Bathinda.
Public URLs are steady enough to plan a run around. A product lives at /prn/name-slug/prid/168, and that trailing prid is also the sku in the page's own Product markup. Categories sit at /cn/slug/cid/4/67, one number for the top group and one for the subcategory. Merchandised shelves use /dc/theme/subcollection carrying a collection uuid and a collection group id. Brands get /brand/slug and recipes get /recipe/ plus a number. The sitemap tree splits the catalogue into thirty-two top level groups and roughly three hundred and ten subcategories, and the robots file closes internal search, cart, checkout and account paths.
Get a Quote
Developers
Customers worldwide
Pages extracted
Hours saved for our clients
€199 / one-time
setup fee - included
€169 / mo
setup fee €499
€229 / mo
setup fee €499
€349 / mo
setup fee €499
€549 / mo
setup fee €799
Blinkit price monitoring only works if every row remembers where it came from. Six coordinates across five cities resolved to six different store ids, and two pins inside Mumbai landed on two different stores under the same city id. In a single chicken subcategory those six shelves held between thirty-five and forty-six items, and only seven product ids appeared on all six. Assortment, not price, is the first thing that moves with the address.
Price moves as well, and it moves by city rather than by store. One Licious pack under a single product id read Rs 359 in the Delhi and NCR stores, Rs 379 in Mumbai, Rs 349 in Bengaluru and Rs 345 in Hyderabad, with the printed MRP tracking the same steps. Discount depth is set locally too: the same cheese slice showed a fifth off in one city and nearly a third off in another on the same afternoon. Sellers control their own listing prices and Blinkit tells them they can change them in real time, so a daily snapshot and an hourly snapshot are different products.
Stock is the third layer and it is per store, not per city. Two Mumbai stores carrying the same pack at the same price reported different counts, and a zero count is a real out of stock at that address, not a delisting. That is what makes the feed usable for share of shelf, out of stock rate, promo depth and pack-price ladders. Against Zepto or Swiggy Instamart the join has to be built on brand plus pack size, because the prid belongs to Blinkit alone - and Blinkit is the storefront that also prints seller, licence and manufacturer under each item.
Learn how to use web scraping to solve data problems for your organization
Leveraging advances in technology, the AI-powered web scraper has skyrocketed in demand and is helping to expand capabilities by automating tedious daily tasks and speeding up data collection from thousands of websites several times over.
Web scraping is a method of obtaining web data by extracting it from pages of web resources with the help of a program, that is, in automatic mode. It is used to syntactically convert web pages into more usable forms.
If you specialize in machine learning, you need to feed large amounts of data to the algorithms. Web scraping is the easiest and the most efficient method of collecting the data from all over the Internet.
ScrapeIt is a managed web scraping agency. We are not a library and not a self-serve tool: we build the crawler, run it on your schedule, monitor it and fix it when the site changes, so you keep a data feed instead of a codebase. A sample lands before sign-off, so you can check pack units, MRP handling and the store id on every row against live pages yourself. Each row carries the delivery point, the dark store it resolved to and the capture time, which is what lets separate deliveries stack into one comparable series. We have no affiliation with Blinkit.
No. There is no documented public Blinkit API and no developer portal on blinkit.com. The site draws its own pages from internal layout endpoints that expect coordinates, a device id and a session key on every call, and those are undocumented and free to change without notice. The seller hub and the partner, franchise, warehouse and delivery pages are onboarding funnels for merchants and riders, not data products. What we supply instead is a Blinkit API endpoint we host: a stable, versioned schema over the public storefront, so a change on their side becomes our repair job rather than yours.
We treat the delivery point as part of the key. You give us pin codes, localities or coordinates, we resolve each one to the dark store that answers for it, and we crawl the catalogue store by store. Every row then carries its store id, city and capture time, so a price is the price at that address rather than a national average. Two pins inside one city can land on different stores with different shelves, so city coverage is planned as a grid of points, never as a single call.
From the listing: product id, name, brand, pack unit, selling price, MRP, percent off, stock count, variant group, category path, product type, rating, promised minutes and store id. The item page adds key features, ingredients, shelf life, FSSAI licence, country of origin, manufacturer address, return policy, seller and seller licence. What does not exist publicly: written customer reviews with names, order history, per-store sales volumes and margin. We do not sign in, so nothing behind an account is in scope.
As often as the job needs. Stock counts and promo tags move through the day, sellers can change listing prices in real time, and the promised window shifts with load, so an hourly run over a watchlist of product ids paired with a daily sweep of full categories is the usual shape. Complete coverage of a large city is slower than a watchlist because it has to be sliced by store, then by category and subcategory. We agree the cadence per job and hold it, and every delivery is stamped so you can diff one run against the last.
We take only pages Blinkit publishes to the open web without a login, and we honour the paths its robots file closes, internal search included. We do not create accounts, do not place orders and do not touch cart, checkout or payment. Personal data is out by default: no customer names, no rider identities, no private addresses. Blinkit's terms of use restrict automated data gathering, so the commercial and legal call is yours to make with your own counsel. What we hold to is the technical discipline - public pages only, polite rates, and a clear record of what was taken and when.
Step 1 - Make a Request
You share your needs, expectations, and desired timeframe. We’ll suggest the best solution based on your request and budget.
Step 2 - Configuring Custom Web Crawlers
Our specialists configure the crawlers and extract a sample dataset for your review before proceeding with the full-scale extraction.
Step 3 - Collect and Deliver
Once you approve the sample, we launch the project and start full data collection. We gather, filter, and structure the data for easy use, delivering it on time in your preferred format.
Step 4 - Maintain and Support
Our team manages ongoing processes, monitors website changes, and supports all data extraction cycles. We can also help integrate data into your systems or create dashboards to simplify analysis.
Scrapeit Sp. z o.o.
10/208 Legionowa str., 15-099, Bialystok, Poland
NIP: 5423457175
REGON: 523384582
