intelligent.pageDocs

Blinkit

Blinkit is a vendor purchase-order channel, not a seller marketplace API: POs arrive by EDI to an approved OMS, ASN and invoice go back, no public developer portal.

Blinkit (formerly Grofers, owned by Eternal Ltd, previously Zomato Ltd) is India's largest quick commerce platform, delivering groceries, personal care, electronics and general merchandise from dark stores in roughly ten minutes. For a brand, Blinkit is not a marketplace in the Amazon or Flipkart sense. Blinkit buys stock from you. You are a vendor, Blinkit raises purchase orders against your warehouses, you ship into their dark stores or city hubs, and Blinkit owns the listing, the price shown to the shopper and the consumer relationship. That changes what a connector can do: there are purchase orders, advance shipping notices, invoices and short-payment claims to read, and essentially no listing, price or stock write path.

At a glance

What it is

Blinkit operates a dark-store network across Indian metros and tier 2 cities and sells on an inventory-led model. Brands supply Blinkit under a vendor agreement; Blinkit's category and supply planning teams issue purchase orders per city or per fulfilment location. Onboarding runs through a brand or vendor relationship, usually with a category manager, and vendors are given access to a seller hub where POs, appointments, ASNs, invoices, GRN results and short-payment claims are visible. Blinkit separately runs an ads product at brands.blinkit.com ("Blinkit Ads"), which is a distinct surface from the supply-side vendor portal and is not a source of order data.

Because Blinkit is inventory-led quick commerce, the operational cadence is very different from a marketplace: PO frequency is high, lead times are short, appointment slots at the fulfilment centre matter, and fill rate against the PO is the metric the category team manages you on.

API access

There is no self-serve developer programme. The integration that exists in practice is between Blinkit and a small set of order management systems. The clearest published description is EasyEcom's, which states plainly that Blinkit purchase orders are received by EDI integration, that EDI is enabled by default for their clients, and that "the EasyEcom webhook must be enabled in the Blinkit account to complete the API integration. This is handled by the Blinkit team."

Practical consequences for anyone building a connector:

  • You cannot obtain credentials by signing up. Enablement is a request from the vendor to their Blinkit contact, naming the OMS.
  • The only identifier the vendor supplies to the integration is a Vendor ID, also called a Receiver Code, which Blinkit's team issues.
  • Unicommerce also offers Blinkit, but by a completely different mechanism: its integration page describes "an innovative email parsing solution, automating the journey from PO receipt to order creation", replacing a manual flow of "PO Received via Email, Forwarded to Accounts Team, Manually Uploaded, Order Creation" with "PO Received via Email, Auto Forward to Unicommerce, Order Creation". Unicommerce's page does not mention an API, EDI or ASN at all.
  • No official SDK, Postman collection or public GitHub repository for a Blinkit vendor API was found.

That difference is the most important thing on this page. One approved OMS says purchase orders arrive over an enabled webhook; the other says it parses them out of email. Both cannot be the only path, so either Blinkit runs two delivery mechanisms and gives different vendors different ones, or one vendor's connector predates the other's. Do not assume the webhook is available to you.

Warning

Do not design a Blinkit connector as a direct integration until you have confirmed partner status. The realistic v1 is to read Blinkit purchase orders out of the vendor's existing OMS (EasyEcom, Unicommerce) or out of seller hub exports, and to treat Blinkit as a purchase-order source rather than a sales channel.

Authentication

Not published. No token endpoint, header name or signature scheme for a Blinkit vendor API is available from any source we could read. What is documented is the setup handshake on the OMS side:

  1. The vendor asks Blinkit to enable the webhook for their account against the chosen OMS.
  2. Blinkit issues a Vendor ID / Receiver Code.
  3. In the OMS, the vendor adds Blinkit as a channel and enters the Vendor ID / Receiver Code, chooses a payment mode, and picks the sales channel that Blinkit orders map to.
  4. The vendor maps Blinkit delivery pin codes to their own warehouses, one to one or one to many, so the OMS can route each PO to the right stock location.

The pin code to warehouse mapping is entered as a plain object of warehouse token to pin codes, in this shape:

{
  "location1": [12346, 54648],
  "location2": [12346, 54648, 45099, 8806],
  "location3": [560103]
}

Multi-account handling is not documented. Assume one Vendor ID per legal entity per Blinkit account, and that a brand selling under two entities needs two channel configurations.

Objects we can read

Orders

Blinkit purchase orders arrive as B2B orders. They are pushed to the integrated OMS rather than pulled, and they are dated by the PO date carried on the Blinkit PO, not by receipt time. Key behaviours documented by EasyEcom:

  • Orders are only imported if the product SKU is already mapped. Unmapped SKUs are silently not imported, which is the single most common cause of a "missing PO".
  • A PO can import fully or partially. Partially imported POs cannot be processed at all; partially processed orders are split automatically.
  • Whether a PO lands in an open queue or an approval queue depends on whether the OMS auto-assigns inventory for B2B orders at import.

No endpoint, request or response schema is published. Sample response not published.

Order items

PO lines are keyed on the product UPC, which is the identifier Blinkit uses. On the OMS side the same UPC has to be entered as the SKU, listing reference number, GUID and identifier when the Blinkit listing set is uploaded, which tells you the Blinkit side carries little more than an item code, a quantity and a price per line. Field names are not published.

Products and listings

There is no readable Blinkit catalogue API. Listings are created on the OMS side by uploading a template sheet with the Blinkit UPCs and selecting Blinkit as the marketplace, purely so that incoming PO lines can be matched. This is a local reference table, not a mirror of Blinkit's live catalogue, so it will not tell you the price shown to shoppers, availability by dark store, or whether a product is currently listed.

Inventory

Not readable. Blinkit owns the stock once it is received, and dark-store level availability is not exposed to vendors through any documented feed.

Shipments and tracking

Outbound only, and from your side. Advance shipping notices are supported for Blinkit vendors. EasyEcom requires an allocation rule based on Exact MRP to be enabled on the account before the ASN flow can be turned on, and the ASN flow itself has to be enabled by a support ticket. Inbound tracking of the truck to the fulfilment centre, appointment slots and GRN results are seller hub surfaces, not documented API objects.

Returns and cancellations

Not published. In an inventory-led model the relevant events are PO cancellation, short receipt at GRN and quality rejection, none of which have a documented feed.

Payments and settlements

Not published. Vendors reconcile against invoices and short-payment claims in the seller hub. Treat settlement as a manual export for now.

Customers

None. Blinkit is the merchant of record to the shopper. No customer data reaches the vendor.

Locations

Blinkit fulfilment locations appear indirectly, as the delivery pin codes on the PO. The connector's job is to translate those pin codes into your own warehouse identifiers using the mapping above.

Writing back: listings, price and stock

Not available. A Blinkit vendor cannot create a listing, change the shopper-facing price or set stock through any documented interface. Catalogue creation, MRP and margin are negotiated with the category team and entered by Blinkit. The writes that do exist are operational responses to a PO, and they go through the OMS: confirm or short the PO, generate the invoice, raise the ASN, book the appointment.

If you need "auto-updating listings" semantics for Blinkit, the honest answer is that the lever is fill rate against the PO, not a price or stock endpoint.

Webhooks and notifications

There is a webhook, and it is the primary delivery mechanism for purchase orders, but it is not self-serve. Blinkit's team enables the webhook on the vendor's Blinkit account, pointed at an approved OMS endpoint. Event types, the signature or shared secret used to verify the call, and the retry policy are all unpublished.

If you are not the approved endpoint, there is nothing to poll on Blinkit directly. Poll your OMS instead: a fifteen minute cadence against the OMS order list is enough given PO frequency, and reconcile daily against a seller hub export.

Rate limits and pagination

Not published. No quota headers, burst limits or page size are documented. Since the traffic is push-based and low volume relative to a marketplace, rate limits are unlikely to be the binding constraint; SKU mapping completeness is.

Mapping to the unified model

Gaps and open questions

  • The two approved OMS vendors describe incompatible mechanisms. EasyEcom documents an enabled webhook and calls it both "EDI integration" and "API integration" in consecutive lines. Unicommerce documents email parsing of the PO and mentions no API. Settle this with Blinkit directly before designing anything; it is the difference between a push integration and a mailbox parser.
  • Whether Blinkit's vendor API, where it exists, is genuinely EDI (X12 or EDIFACT over AS2 or SFTP) or a JSON webhook loosely labelled EDI.
  • The exact webhook request body, and whether it is signed.
  • Whether a vendor can get their own webhook endpoint approved, or only a listed OMS.
  • Whether short-payment claims, GRN results or appointment slots have any machine-readable export.
  • Blinkit's own seller and partner pages could not be read: blinkit.com/partner, blinkit.com/sell-on-blinkit and seller.blinkit.com all returned HTTP 403 from Cloudflare on 2026-09-21. Everything above that concerns Blinkit's own surfaces is therefore second-hand.

Sources