Platform · Blinkit

Blinkit Data Scraping Services

Q: What is the listed versus in-stock distinction?

The most important field decision in quick commerce data. listed means the SKU is ranged in that zone at all — a commercial decision. in_stock means it is purchasable where listed — a replenishment issue. Merging them creates a single unavailability figure mixing both. We have seen brands escalate a 40% unavailability number to supply chain and spend weeks discovering most of it was zones where the SKU was never ranged.

Q: What does Blinkit collection cost?

We quote individually, driven almost entirely by pincodes times SKUs times frequency. Those three multipliers compound quickly, which is why zone design matters more here than in any other platform we cover. A focused SKU set across a well-chosen zone sample at several-times-daily refresh sits at the lighter end. Large SKU sets across many zones at hourly refresh sits considerably higher. One scoping call, a free pilot on your own SKUs and zones within 24 hours, then a fixed monthly quote. Request a quote.

Collected per pincode, because there is no national Blinkit catalogue to collect.

Blinkit data scraping is the automated collection of publicly visible Blinkit data at pincode level — per-zone pricing, assortment and availability with listed and in_stock as separate fields, delivery promise and fee structure, and category shelf position with sponsored placement flagged.

Blinkit has no national catalogue. Dark store ranges are selected locally, so assortment, price, stock and delivery promise all vary by the pincode a shopper is standing in. National figures for Blinkit are not simplifications; they are wrong.

Get a free sample See sample data

Free pilot on your own Blinkit list, returned in 24 hours. No card, no trial clock — and you keep the sample data either way.

blinkit_pincode.jsonl LIVE FEED

{"blinkit_product_id":"bk-4471028", "pincode":"560034", "listed":true,"in_stock":false, "price":162.00,"mrp":199.00, "discount_pct":18.6, "pack_size":"500 g", "unit_price_computed":32.40, "handling_fee":9.00,"surge_fee":0.00, "delivery_fee":25.00, "delivery_promise_min":12, "shelf_position":4,"sponsored_flag":false} {"blinkit_product_id":"bk-4471028", "pincode":"110024", "listed":false, "listed_reason":"never_ranged_in_zone", "in_stock":"null"}

2 of 6,881,400 sku-pincode rowspincodes: 212 · listed vs in_stock separated · schema v4.5

Independence and trademarks. Actowiz Solutions is not affiliated with, endorsed by or connected to Blinkit or its owners. Blinkit and related marks belong to their respective owners, used here only to name the publicly accessible source this service collects from.

Our Data Powers

B2C Marketplace

amazon

D2C + Marketplace

NYKAA

D2C + Marketplace

Walmart

FMCG Marketplace

udaan

Food Delivery

Uber Eats

Quick Commerce

blinkit

Taxi Aggregator

Uber

E-Commerce

Tmall

Blinkit at a glance

How we handle Blinkit specifically

Platform-specific handling, not a generic retail template pointed at a different domain.

Platform: Blinkit across Indian metro and tier-2 delivery zones
Granularity: Pincode level, because dark store catalogues are locally selected
The critical split: listed vs in_stock as separate fields, never merged
Delivery: Displayed promise in minutes, handling and surge fees captured
Shelf position: Category ordering with sponsored placement flagged
Pack sizes: Quick-commerce exclusive pack sizes parsed and unit-normalised
Refresh: Hourly on priority zones and SKUs; several times daily as standard
Region: India

Platform specifics

What makes Blinkit data different from web retail

These are the reasons a Blinkit dataset needs its own handling rather than a shared retail schema.

listed and in_stock must stay separate

This is the single most consequential field decision in quick commerce data, and getting it wrong sends teams chasing problems that do not exist.

listed means the SKU exists in that dark store's range at all. If it is absent, that is a commercial ranging decision.
in_stock means it is purchasable where it is listed. If it is false, that is a replenishment issue.

Merging them produces a single "unavailability" figure that mixes the two. We have seen brands escalate a 40% unavailability number to their supply chain team and spend weeks discovering most of the gap was zones where the SKU was never ranged — a category conversation, not a replenishment one.

Availability percentages are computed only across the listed population, so an availability figure means what the phrase actually means. Range gaps surface as their own separate metric.

Pincode is the unit of analysis

Everything varies by zone simultaneously, and each of these is a separate commercial signal:

Assortment. A SKU ranged in one zone is genuinely absent in the next.
Price. Zone-level pricing reflects local competition and dark store economics.
Stock. Dark stores hold hours of cover, so stock-outs are frequent, short and zone-specific.
Delivery promise. Displayed minutes shift by zone and by hour of day.
Fees. Handling and surge fees vary by zone, time and basket value.
Shelf position. Category ordering and sponsored placement differ per zone, so share of shelf is a local metric.

Cost scales with pincodes multiplied by SKUs multiplied by frequency, so zone design matters enormously. We sample one pincode per dark store cluster to remove redundancy, weight toward revenue concentration, deliberately include income-tier variation, and add a rotating low-frequency sweep to validate the dense sample. That design conversation happens before we quote, and it usually cuts the initial ask substantially.

Quick-commerce pack sizes and fee structure

Quick commerce carries pack sizes that do not exist in general trade — smaller formats built for immediate consumption and basket economics. Comparing a quick-commerce pack against a supermarket pack on price alone is meaningless.

We parse pack size and unit and compute unit price on a consistent basis, so cross-channel comparison works. Where a SKU is quick-commerce exclusive, that is worth knowing in its own right.

Fee structure is the other half of the price. Handling fees, surge fees and delivery charges vary by zone, hour and basket value, and a product-price comparison that ignores them understates the real cost difference against a supermarket. We capture displayed fees alongside product prices, plus the delivery promise in minutes, which is itself a competitive signal — a zone consistently promising 22 minutes is operating differently from one promising 10.

Scope

What we collect on Blinkit, and what we do not

The right column matters more than the left. Anyone can list fields; the limits are what tell you whether the dataset will hold up.

✅ What we collect

Pincode-level pricing, assortment and availability with zone on every record
listed and in_stock as separate fields, with availability computed on the listed population
Delivery promise in minutes as displayed, per zone and time
Handling, surge and delivery fees as displayed
Pack size parsed with unit price computed on a consistent basis
Quick-commerce exclusive pack identification
Category shelf position with sponsored placement flagged
Stock-out timing and duration on the hourly tier
New SKU appearance and delisting detection per zone

❌ What we do not, and why

Customer accounts, order history or personalised pricing
Dark store inventory quantities, which are not published
Blinkit partner or seller systems of any kind
Availability revealed only by adding items to a basket
Reviewer or customer personal data of any kind

Core Blinkit fields

The full dictionary is agreed during scoping. These are the fields specific to this platform.

Field	What it is on this platform
blinkit_product_id	The platform identifier, used as the join key
pincode / zone_id	The delivery zone the record reflects, mandatory on every row
listed	Whether the SKU is ranged in this zone at all — a commercial signal
in_stock	Whether it is purchasable where listed — a replenishment signal
price / mrp / discount_pct	Selling price, printed MRP and computed discount
pack_size / pack_unit / unit_price	Parsed pack architecture and computed unit price
is_qc_exclusive	Whether the pack format is quick-commerce specific
delivery_promise_min	Displayed delivery time in minutes at observation
handling_fee / surge_fee / delivery_fee	Displayed fees, which are part of the real price
shelf_position / is_sponsored	Category ordering and whether the placement was paid
oos_since / oos_minutes	Stock-out start and duration, on the hourly tier

Use cases

What teams do with Blinkit data

Separating range gaps from replenishment failures

listed and in_stock are held separately with availability computed on the listed population, so a category ranging decision is never reported as a supply chain problem.

Zone-level price and availability benchmarking

Per-pincode collection reveals price and availability variation that a national view flattens, across a zone set designed around revenue concentration and income tiers.

Share of shelf by zone

Category ordering with sponsored placement flagged gives share of shelf as a local metric, since shelf position differs per zone rather than nationally.

True cost comparison against general trade

Unit-normalised pricing plus displayed handling, surge and delivery fees give the real cost difference against supermarket channels rather than a product-price-only comparison.

The 24-hour sample — run on your sources, not ours

Send us a Blinkit item or category list. We run real collection against it and return the output within 24 hours, with the platform-specific fields populated so you can check them yourself rather than take our word for it.

Real extraction from your actual sources
Returned inside two business days
Coverage and QA note included
You keep the data either way
No card, no trial clock
Named engineer on the call

Get my free sample Book a 20-min scoping call Reply within one business day. Reference calls available under NDA.

How we engage

Three ways to engage us

Same collection pipeline and QA underneath. The difference is who holds the schedule and how the data reaches you.

Managed service (most common)

We own the collection, the QA and the delivery. You receive clean data on a schedule and never touch a scraper.

Dedicated engineer assigned to your account
Site changes fixed by us, not reported to you
Scheduled delivery to your warehouse or S3
Named contact on Slack or email

Best fit: Teams who need the data, not the infrastructure.

API access

The same collection pipeline exposed as an authenticated REST endpoint your systems query directly.

On-demand and scheduled endpoints
Rate limits agreed to your load profile
Sandbox keys for integration testing
Versioned schema with deprecation notice

Best fit: Product and engineering teams building on live data.

One-time or project extraction

A defined pull for a specific question — market sizing, diligence, a pitch, a one-off audit.

Fixed scope agreed in writing upfront
Single delivery with full QA report
Methodology documented for your records
Converts to managed if you want continuity

Best fit: Research, strategy and diligence work with a deadline.

Pricing

Every engagement is quoted individually, because the honest answer depends on your scope: how many sources, how many records, how often, and how the data reaches you. We scope it with you, run a free pilot on your own sources, and then quote a fixed monthly figure — no per-request metering and no overage billing when volumes move. Request a quote and you will have a number after one call.

Blinkit is usually collected alongside its competitors

Almost nobody buys a single platform in isolation. Blinkit data becomes useful when it sits next to the competitor set on one schema, refreshed on one schedule, so a price index or availability comparison is genuinely like-for-like.

That is what quick commerce data covers, and a Blinkit-only engagement can be expanded into it without rebuilding. If you already know you need several platforms, start there instead — it is the same pipeline and usually the better scoping conversation.

FAQ

Blinkit data scraping: frequently asked questions

Platform-specific questions, including what cannot be collected here.

Because dark store ranges are selected locally, so there is no national catalogue to collect. Assortment, price, stock, delivery promise, fees and shelf position all vary by zone simultaneously.

National figures for Blinkit are not simplifications, they are wrong. Every record carries the pincode or zone it reflects.

The most important field decision in quick commerce data. listed means the SKU is ranged in that zone at all — a commercial decision. in_stock means it is purchasable where listed — a replenishment issue.

Merging them creates a single unavailability figure mixing both. We have seen brands escalate a 40% unavailability number to supply chain and spend weeks discovering most of it was zones where the SKU was never ranged.

Fewer than most clients first assume. Cost scales with pincodes times SKUs times frequency, so 500 SKUs across 1,800 pincodes hourly is roughly nine times the cost of the same SKUs across a well-chosen 200.

We sample one pincode per dark store cluster to remove redundancy, weight toward revenue concentration, include income-tier variation deliberately, and add a rotating low-frequency sweep to validate the dense sample.

Yes — handling, surge and delivery fees as displayed, plus the promise in minutes. Fees vary by zone, hour and basket value and are genuinely part of the price.

A product-price comparison against supermarket channels that ignores them understates the real cost difference materially. The delivery promise is also a competitive signal in itself: a zone consistently promising 22 minutes operates differently from one promising 10.

No. Inventory quantities are not published by Blinkit or any quick commerce platform, and nobody collecting public pages can supply them.

What we do provide on the hourly tier is stock-out start times and durations, which lets you quantify lost-sales windows. That is a measurement of availability transitions rather than an inventory count, and we are explicit about the difference.

We quote individually, driven almost entirely by pincodes times SKUs times frequency. Those three multipliers compound quickly, which is why zone design matters more here than in any other platform we cover.

A focused SKU set across a well-chosen zone sample at several-times-daily refresh sits at the lighter end. Large SKU sets across many zones at hourly refresh sits considerably higher. One scoping call, a free pilot on your own SKUs and zones within 24 hours, then a fixed monthly quote. Request a quote.

See real Blinkit data before you commit to anything

Send us an item or category list. We return the output within 24 hours with the platform-specific fields populated.

Get a free sample Talk to an engineer

Free pilot, no card, no obligation. If we cannot collect a field you need on this platform, the sample shows you that too.

Hear It Directly from Our Clients

Watch how businesses like yours are using Actowiz data to drive growth.

▶

1 min

★★★★★

"Actowiz Solutions offered exceptional support with transparency and guidance throughout. Anna and Saga made the process easy for a non-technical user like me. Great service, fair pricing!"

Thomas Galido

Co-Founder / Head of Product at Upright Data Inc.

▶

2 min

★★★★★

"Actowiz delivered impeccable results for our company. Their team ensured data accuracy and on-time delivery. The competitive intelligence completely transformed our pricing strategy."

Iulen Ibanez

CEO / Datacy.es

▶

1:30

★★★★★

"What impressed me most was the speed — we went from requirement to production data in under 48 hours. The API integration was seamless and the support team is always responsive."

Febbin Chacko

-Fin, Small Business Owner