intelligent.pageDocs

Zepto

Indian quick commerce retailer that buys stock from brands: no public seller API, so integration is a brand portal, POs, GRN and payments.

Zepto is an Indian quick commerce platform that delivers groceries and household goods in minutes from a network of dark stores. The single most important fact for a connector is that Zepto is not a marketplace. A brand does not create a listing, set a price and ship to the customer. Zepto buys inventory from the brand, owns it, prices it and sells it. The brand's relationship with Zepto is therefore a vendor relationship built on purchase orders, appointments, goods receipt notes, fill rate and payment reports, not on an orders API. No public developer portal or seller API exists.

At a glance

What it is

Zepto operates in the Indian quick commerce segment alongside Blinkit and Swiggy Instamart. It runs dark stores in metro and tier one cities, stocked from larger fulfilment centres, and promises delivery in roughly ten minutes. The assortment is grocery led but has widened into personal care, home, general merchandise and, in some cities, electronics and apparel adjacents.

The commercial model is wholesale retail, often called a 1P or inventory model. Zepto's buying team raises a purchase order against a brand's SKUs at an agreed cost price. The brand delivers into a Zepto warehouse. Zepto then decides the selling price, the dark stores that carry the SKU and the promotional calendar. A brand's revenue from Zepto is the value of goods Zepto receives, net of trade terms, not the value of what consumers buy.

Warning

Do not model Zepto as a sales channel in orders. A Zepto purchase order is a B2B sale from the brand to Zepto. Loading it alongside marketplace consumer orders will double count revenue if the same stock also appears in a distributor or D2C line, and it will make per-order economics meaningless because there is no end customer, no shipping fee and no cash on delivery.

API access

There is no Zepto developer portal, no API reference, no SDK, no Postman collection and no sandbox in the public domain. A direct fetch of zeptonow.com on 2026-09-21 returned no readable content, because the site is a client-rendered application that serves an empty shell to a non-browser fetcher. Probes of the obvious vendor subdomains did not resolve. That is a fetcher limitation rather than proof of absence, but no mirror, partner page or third-party reference to a Zepto vendor API was found either.

What does exist, from aggregator documentation:

  • Unicommerce lists Zepto in its published integrations catalogue, describing it as a quick commerce app delivering online groceries.
  • Unicommerce's dedicated page for the comparable Blinkit connector states the mechanism plainly: it describes "an innovative email parsing solution, automating the journey from PO receipt to order creation", with the flow given as purchase order received by email, auto forwarded to Unicommerce, order created. The same page groups Blinkit, Zepto and Swiggy Instamart together as the quick commerce partners it covers.
  • EasyEcom markets a quick commerce operation but its public pages describe outcomes such as node allocation and inventory sync rather than naming the mechanism per channel.

Read together, the evidence says that as of 2026-09-21 the industry-standard way to automate Zepto is to parse the purchase order document, not to call an endpoint. If Zepto has since issued API credentials to selected vendors, it has not documented them publicly.

How a brand gets onboarded

Onboarding is a commercial conversation, not a developer signup. In outline, and unverified against a Zepto-published source: reach a category buyer or account manager, usually through an existing distributor, a broker or a trade contact; sign a vendor agreement covering cost price, margin, listing fees, marketing spend, returns liability and payment terms; complete vendor master registration with GSTIN, PAN, bank details and a registered address per state of supply; then receive brand portal credentials for purchase orders and reports.

Authentication

Not published. Access to the brand portal is a username and password issued to the brand's account contact. No OAuth application, no API key issuance process and no token lifetime is documented. Multi-brand or multi-entity handling, which matters when one company supplies Zepto under several GSTINs, is also undocumented.

Objects we can read

No object is available through a documented interface. What follows is the object set a vendor sees in the portal and in email, named in the vendor vocabulary rather than in invented field names.

Purchase orders

The core object. A Zepto purchase order carries a PO number, an issue date, an expiry or delivery-by date, a destination warehouse, and line items with the brand's SKU code, a Zepto item code, ordered quantity, cost price and tax. It arrives as a document, typically PDF or spreadsheet, by email and in the portal. No JSON schema is published, so no sample response is given here.

Appointments, goods receipt and payments

Delivery into a Zepto facility normally requires a booked appointment or slot. On receipt Zepto records received quantity against ordered quantity; the gap is short supply, and the ratio across a period is the fill rate the buying team manages the brand against. Rejections for damage or short shelf life land here too. Payment advice or remittance reports then reconcile invoices against receipts, less deductions for trade terms, damages and marketing. Format and cadence are set in the vendor agreement, not published.

What is not available

Consumer order lines, end customer identity, per dark store stock on hand and listing status are not given to vendors through any documented route. Sell-out data, city and dark store level, is sold separately as an analytics product rather than exposed as vendor data. A product named Zepto Atom is widely referred to as that analytics offering, but its site did not respond to a fetch on 2026-09-21 and nothing about its contents, pricing or export capability is asserted here.

Writing back: listings, price and stock

Not available, and not applicable. Zepto owns the listing. The brand has no price control beyond the negotiated cost price, and no stock to publish because Zepto holds the inventory it bought. Catalogue changes, new SKU introductions and image or content updates go through the category manager and the portal's item setup process.

Webhooks and notifications

None. The practical notification channel is email: purchase orders and reports arrive in a mailbox. The workable design is a dedicated mailbox with a parser, which is exactly what Unicommerce built for this segment. Poll that mailbox continuously rather than on a schedule, since a purchase order has a delivery-by date and late detection costs fill rate.

Rate limits and pagination

Not applicable. Portal exports are manual downloads. If an aggregator sits in the middle, its API limits govern.

Mapping to the unified model

The unified model has no purchase order table, which is the real gap here. Two options, both of which should be decided once and applied consistently.

Gaps and open questions

  • zeptonow.com returned no content to the fetcher because it is client rendered, and vendor subdomain probes did not resolve. Nothing on this page comes from a Zepto-published source. Confidence is low and the page should be revisited with a browser-based fetch.
  • Whether Zepto has begun issuing API credentials to large vendors is unverified. Ask an aggregator sales engineer; they will know before it is documented.
  • The purchase order document format, PDF or XLSX or both, is unverified.
  • Zepto Atom's scope, pricing and whether it offers a data export could not be checked; its domain refused a connection. Web search was unavailable, so no news coverage was reviewed.

Sources