Meesho

Meesho has no public API docs: a v2 supplier API exists behind a merchant id, supplier identifier and secret, orders are pushed, stock is pushed back.

Meesho is the highest order volume marketplace in India, built on value commerce: low price points, deep coverage of tier two and tier three cities, and a zero commission proposition for suppliers. For a seller that changes what the integration has to be good at. Volume per supplier is high, average order value is low, orders are single item by design, and Meesho controls the shipping end to end. There is no public developer portal. A supplier API exists and is on version 2, but it is provisioned by the Meesho team against a request form, and its reference is not published anywhere this research could reach. What follows is the mechanism as the order management vendors that hold working credentials describe it.

At a glance

What it is

Meesho is a pure marketplace with no first party inventory, owned by Meesho Private Limited (formerly Fashnear Technologies), founded in 2015. Its differentiator is commercial rather than technical: Meesho charges suppliers no commission on the sale, taking its margin from logistics and ads instead. That pulls in a long tail of small suppliers and pushes average selling prices down, so a supplier's Meesho catalogue is usually wide and cheap rather than deep and premium.

Two structural facts drive the connector design. First, Meesho arranges the shipping. The supplier never chooses a carrier, never buys a label and never books a pickup through their own courier account: Meesho's logistics network collects from the supplier and the label comes from Meesho. Second, Meesho orders are single item. Unicommerce documents this as a hard constraint: "Only single item orders will be created and Order Splitting (based on quantity) is not allowed." A connector that assumes a many line order and splits it into shipments has nothing to do on Meesho.

There is also a verification step that has no equivalent on Amazon or Flipkart. Orders can sit in an unverified or on hold state while Meesho does its own checks, and the supplier's system should do nothing until that clears.

API access

There is no self serve route. The documented sequence, from Unicommerce's setup page:

  1. Have an active supplier account on the Meesho supplier panel.
  2. Submit the credential request form that Meesho provides to suppliers integrating through an order management system.
  3. Meesho's team issues a merchant id, a supplier identifier and a secret.
  4. Configure those in the integration, set the API version to v2, and map your warehouses to Meesho facilities.

The version in force is v2. Unicommerce's parameter table requires it explicitly and notes a wrinkle when adding a new v2 channel: only the third connector needs real values, the first two accept dummy values. That is a Unicommerce implementation detail rather than a Meesho one, but it tells you the v2 API is a different surface from whatever v1 was, and that the older connectors were kept for compatibility.

No API version deprecation calendar, no changelog, no official SDK and no published Postman collection could be found.

Warning

This page contains no base URL, no path and no request body, because no public Meesho source publishes one. Treat it as a description of the mechanism and the constraints, not as an implementation reference. A direct Meesho connector needs the reference that comes with the credentials, or an integration through EasyEcom, Unicommerce, Vinculum, Browntape or Ginesys, all of which already hold working credentials.

Authentication

Three values, all issued by Meesho:

  • Merchant ID, identifying the supplier account.
  • Supplier Identifier, a second identifier held alongside the merchant id. Why both exist is not explained publicly. The likeliest reading is that one is the legal entity and one is the selling identity, the same split Amazon makes between a merchant token and a seller id.
  • Secret, the shared credential.

There is no published token endpoint, no expiry, no refresh step and no scope model. As with Nykaa, the shape of the vendor setup form is the evidence: a fixed triple entered once and left alone is the signature of a static key, not of OAuth.

Multi account handling is one credential triple per supplier account, plus a facility mapping. Facility wise inventory sync is a configuration flag, so a supplier shipping from more than one warehouse registers those warehouses with Meesho and maps them to internal locations.

The inbound direction needs its own consideration. Meesho pushes orders, so Meesho must authenticate to your endpoint. No public source describes how, which means the callback authentication scheme is the single most important unknown to resolve before building a receiver.

Objects we can read

No endpoint, parameter, pagination model or sample response is published for any object. The operations below are the ones a production integration confirms work.

Orders

Orders are pushed by Meesho, not polled. Unicommerce states that manual order sync is unavailable for exactly that reason. An arriving order can be in an unverified or on hold state while Meesho completes its own verification, and the correct behaviour is to wait rather than to act.

Once verified, the supplier's acceptance preference decides what happens. Three modes are documented:

  • Accept Always, auto accept every order on arrival.
  • Accept by Inventory, accept only if the SKU has stock.
  • Accept Manually, hold every order for a human decision.

That preference is a property of the integration, so a connector needs to expose it as configuration rather than hard coding auto acceptance.

Sample response not published. Field names not published.

Order items

Exactly one item per order. Quantity based splitting is prohibited. Model the line, because the unified schema needs it, but do not build multi line handling.

Products and listings

Catalogue sync is supported, so listings are readable in enough detail to seed a product master and to map Meesho SKUs to internal SKUs. Field names are not published. Meesho's catalogue identifiers, and whether a supplier's listing carries a stable listing id distinct from the SKU, are unresolved.

Inventory

Inventory sync is supported and facility scoped. The setup step is to enable facility wise inventory and select the warehouse facilities that participate, which means Meesho holds a quantity per supplier facility rather than one pooled number. No batch size, cadence or reconciliation endpoint is published.

Shipments and tracking

Shipping and label printing are handled exclusively by Meesho. The supplier does not generate a label, so there is no label API to call and no carrier selection to make. What flows back to the supplier's system is a status, not a tracking event stream. No shipment object, AWB field or event feed is described in any public source.

Returns and cancellations

Meesho has a large return volume, which is inherent to the price point and the category mix, and returns are visible in the supplier panel. No return API, schema or reason code list is published, and no vendor knowledge base this research reached lists returns among the confirmed syncs for Meesho, in contrast to the same vendors' Nykaa and Myntra pages where returns are listed explicitly. Treat return data as panel and report driven until proven otherwise.

Payments and settlements

No settlement or payout API is described. Meesho's commercial model, zero commission with logistics and ad charges deducted, makes the settlement report the only place the true net per order appears, so this is a real gap for margin reporting. Panel reports only.

Customers

Customer name and delivery address arrive with the pushed order, since the supplier packs the parcel. Nothing is published about masking. Treat everything received as PII.

Locations

Meesho facilities, registered during onboarding and mapped to internal warehouses in the integration. No location listing API is described.

Writing back: listings, price and stock

Stock is the confirmed write path: inventory sync pushes quantities per facility. No batch size, rate limit or confirmation model is published.

Price has no described API path. Meesho price changes are made in the supplier panel, and price is commercially sensitive on Meesho because the platform surfaces the cheapest equivalent listing aggressively. Plan for panel driven pricing.

Listings have no described creation or update API. Catalogue upload on Meesho is a panel workflow with a bulk template. Catalogue sync in the vendor integrations reads listings out, it does not write them in.

Webhooks and notifications

Meesho pushes orders to the integration. That is the closest thing to a webhook and it is not optional: there is no pull alternative for orders, which is unusual and has a hard consequence. If your receiver is down, you do not simply fall behind on a poll, you lose the notification and have to reconcile from the panel. Build the receiver to persist the raw body before doing anything else, and be idempotent on the Meesho order identifier.

Subscription, signature verification, retry policy and replay are all undocumented publicly. These are the first four questions for the Meesho integration team.

For everything that is not pushed, there is no documented poll. Inventory and catalogue sync run on the integration's own schedule.

Rate limits and pagination

Not published. No numbers, no headers, no pagination model, no sandbox to measure against. Ask for the limits at the same time as the credentials.

Mapping to the unified model

Gaps and open questions

  • The push authentication scheme is unknown, and it is the blocking unknown. Meesho calls your endpoint and you cannot verify the caller from anything published.
  • No base URL, path, method, header or body is public for any call.
  • What the supplier identifier is, and how it differs from the merchant id, is not explained anywhere.
  • Returns have no confirmed API path, which is a serious gap given Meesho's return rate.
  • Settlements have no API path, which matters more on Meesho than elsewhere because the zero commission headline hides logistics and advertising deductions that only appear in the report.
  • Whether Meesho provisions API credentials to a supplier building their own connector, or only to approved order management vendors, is not stated. Ask first.
  • Meesho v1 and the migration to v2 are undocumented publicly. If an older integration exists, its cutover path is unknown.
  • No rate limit, no sandbox, no changelog.

Sources