intelligent.pageDocs

Myntra

Myntra MMIP PPMP and Omni v4 APIs: merchant id plus secret key issued by Myntra, reads reconciliation data, writes inventory, discounts and listings.

Myntra is India's largest fashion and lifestyle marketplace, owned by the Flipkart group and therefore ultimately by Walmart. It matters to a seller because it is the default destination for apparel, footwear, accessories and beauty in India, and because its integration model is unlike Amazon's or Flipkart's: Myntra pushes orders at you rather than letting you poll for them, and the full API reference lives behind a login on the Myntra Marketplace Integration Platform (MMIP). There is a real, versioned REST API on v4, a public developer centre that describes the workflow, and a set of reconciliation APIs added in 2021 for pulling state back. What is not public is the endpoint reference itself, the authentication sequence and the sample bodies. Those arrive with the credentials, through an account manager or an OMS migration ticket.

At a glance

What it is

Myntra is a pure marketplace for fashion, beauty and lifestyle, operating only in India. It sits inside the Flipkart group and shares group logistics, but its seller systems are entirely separate from seller.flipkart.com and the two integrations share no code. Category access is restricted: apparel, footwear, fashion accessories and beauty are on the platform, general merchandise is not.

Three seller models matter to a connector, and they are different integrations rather than different flags on one integration:

  • PPMP, Pure Play Marketplace. The seller owns the stock, holds it in their own warehouse, packs against a Myntra generated invoice and label, and hands over to Myntra's logistics. This is the model most third party order management systems support.
  • Omni. Stock sits in the seller's physical retail stores and orders are routed to a store for fulfilment. The Omni v4 API adds a Reassign Store call that PPMP does not have.
  • Myntra stocked models, where Myntra buys or holds the inventory and fulfils from its own warehouses. These are commercial arrangements with no seller side fulfilment API surface, because Myntra is doing the fulfilling.

The identifiers to know: Myntra works in styles and SKUs, a style being the product and a SKU being the size variant. Communication is keyed on the Myntra order id, the Myntra order line id and the seller's own SKU code. After the seller marks a line ready to dispatch, Myntra returns a packet id, and from that point the packet id is the unit for labels, invoices, shipped and delivered updates, and returns.

API access

There is no open developer registration. The documented route is:

  1. Have an active Myntra seller account on PPMP or Omni.
  2. Raise an OMS migration or integration ticket through the seller dashboard, or ask the Myntra account manager, stating which order management system will integrate.
  3. Myntra's team issues a merchant id and a secret key, and activates one or more warehouse ids or store codes.
  4. The seller or their OMS generates a token for the inbound direction and shares it back with Myntra on the same ticket, so Myntra can authenticate when it pushes orders.
  5. Myntra confirms the channel is live, typically after a single SKU inventory sync and a test order.

The version in force is v4. v3 still exists for sellers who were never migrated, and Myntra migrates sellers from v3 to v4 on request rather than on a deadline. The migration is not cosmetic. Increff's migration note records two breaking differences: v4 orders can contain multiple lines where v3 orders were single line, and the v4 channel order id is an encrypted 36 character string rather than the 14 character order release id that v3 used. Any column sized for 14 characters will break. The same note records that Myntra cannot push returns for a v3 channel after a seller has been migrated, so returns straddling the cutover have to be uploaded by hand.

There is no official Myntra SDK in any language, and no published Postman collection.

Warning

The public pages at mmip.myntrainfo.com/documentation are workflow documents, not an API reference. They name the calls, describe the order of operations and give the business rules, but they do not give base URLs, HTTP methods, header names or request bodies. Everything in the Authentication and Objects sections below that is marked "not published" needs to come from the reference behind the MMIP dashboard login. Do not plan an implementation estimate on the public pages alone.

Authentication

The credential pair is a merchant id and a secret key, both issued by Myntra. Every integration guide from the order management vendors asks for exactly those two fields plus a warehouse id, which is strong evidence that the scheme is a static shared secret rather than OAuth. Unicommerce's setup form asks for "Merchant Id", "Secret Key" and a JSON map of Myntra warehouse codes to its own warehouse codes. Vinculum's asks for merchant id, secret key, warehouse id and a fulfilment SLA in days. Base's asks for a store code, merchant id, client secret and warehouse id.

What is not published anywhere public:

  • the token endpoint, if there is one, or whether the secret key is sent directly
  • the header names carrying the merchant id and the signature
  • whether the secret key signs the request body (HMAC) or is transmitted as a bearer value
  • token lifetime and refresh
  • any scope or role model

One header is published, in the PPMP v4 workflow document, for the discount path: x-partner-store must be set to myntra when pushing discounts. That is the only header name this research could confirm from an official Myntra source.

Multi account handling is straightforward in shape even if the mechanics are gated: one merchant id per seller entity, and one or more warehouse ids or store codes under it. A connector managing several sellers stores a credential row per merchant id and a warehouse mapping table beside it, because inventory is pushed facility by facility.

The inbound direction is a second credential. Myntra calls the seller's system to create and update orders and returns, and authenticates with a token the seller generated and handed over on the migration ticket. Treat this as a webhook secret: it is long lived, it is shared by ticket, and rotating it means another ticket.

Objects we can read

Myntra's read surface was thin until the reconciliation suite landed in 2021. The design assumption is that the seller's system already holds the truth, because Myntra pushed the orders to it, and the reconciliation APIs exist to repair drift rather than to be the primary feed.

Orders

Orders arrive by push. Myntra calls the seller's Create Order endpoint with a multi line construct: customer details at order level, charges at line level. Updates arrive on the same path as status changes.

For pulling, the Order Reconciliation API lets a seller fetch order data and resolve status mismatches over a time period. The changelog dates it to 30 September 2021 and restricts it to PPMP warehouse sellers, not Omni. Method, path, window size and pagination are not published.

Documented fields, from the workflow text rather than a schema: Myntra order id, Myntra order line id, seller SKU code, packet id and tracking id (both returned by the ready to dispatch call), and the encrypted 36 character channel order id. Customer name and shipping address are present in the pushed order body and are PII. The v4 document also refers to an encrypted UIDX parameter on the order construct. Sample response not published.

Order items

Lines are first class in v4. A single order carries several SKUs and quantities, ready to dispatch operates at line level, and charges are attached per line. There is no separate order items endpoint: lines come inside the order body.

Products and listings

There is no product or SKU pull API. Vinculum states this plainly for both PPMP and Omni: "SKU Pull is not available in Myntra PPMP as Myntra do not have any API for this." The practical consequence is that the listing catalogue has to be seeded from a file. Base's guide describes the standard route: download the Operational Listing Report from the Myntra seller panel and import it, then match to internal inventory on product name, SKU and EAN.

What does exist on the read side is the Catalog Reconciliation APIs, live per the changelog, for automated lookup of product listings and SKU details, plus Task Status and Style Status endpoints that report progress on listings submitted through the upload APIs. Paths and response shapes are not published.

Inventory

The Inventory Reconciliation API retrieves inventory levels across warehouses and stores in batches of up to 40 SKUs. Vinculum's implementation schedules it once per day, which is a reasonable hint at what the quota tolerates. Inventory is held and reported facility by facility, so a read has to be issued per warehouse id or store code.

Shipments and tracking

There is no shipment search API. Shipment state flows in both directions on the packet id: the seller's ready to dispatch call returns a packet id and a tracking id, and Myntra pushes shipped and delivered status back onto that packet id. The Update Order call also accepts a Lost status, added 15 September 2021, for orders lost inside Myntra's logistics leg.

Labels and invoices are pulled, not pushed: Download Invoice and Download Shipping Label both operate on the packet id in v4, where v3 operated on the order release id.

Returns and cancellations

Returns are pushed by Myntra. A return request arrives with a type of COURIER_RETURN for a return to origin or CUSTOMER_RETURN for a return to vendor, and a status of Confirmed. The packet id doubles as the return id. The seller acknowledges progress with Update Return, moving it to READY_FOR_PICKUP while in transit and then to DELIVERED or DECLINED at close. A returnWarehouseCode parameter was added so returns can be routed to a specific warehouse rather than the default.

The Return Reconciliation API fetches and reconciles returns over a time period, dated 30 September 2021 in the changelog.

Cancellation is bidirectional in the vendor integrations: Myntra can cancel a line and the seller can reject one, with rejection gated by an account level setting that is off for PPMP by default.

Payments and settlements

No settlement or payout API is documented on the public pages, and none of the vendor integration guides expose one. Settlements are taken from the seller panel's payment reports. Treat this as file based until a partner conversation proves otherwise.

Customers

Customer name and delivery address arrive inside the pushed order body and are PII. There is no customer lookup endpoint. Whether the phone number is masked or virtualised is not stated in any public source.

Locations

Warehouses and stores are registered by sharing a warehouse master with Myntra during onboarding, and Myntra returns the warehouse ids or store codes to use. There is no self serve location API. Omni adds a Reassign Store call, which moves an order to a different store when the assigned one cannot fulfil.

Writing back: listings, price and stock

Three write paths exist and they are not equivalent.

Stock. The seller pushes facility wise incremental inventory through the inventory push API. The published limit is precise: "One call can contain a batch size of 10 with a limit of 100 requests per minute." That is 1,000 SKU updates per minute per account at the ceiling. v4 also supports an Inventory v2 API for absolute inventory rather than incremental deltas, which is what you want for a connector driven from a warehouse system of record, because deltas drift the moment a call is lost.

Price. Base price is set in the catalogue, and the v4 workflow document states that pricing is uniform across sizes within a style. Discounts are the moving part and they are pushed through the Update Discount API, with x-partner-store: myntra as a mandatory header. So the writable price lever on the API is the discount, not the MRP.

Listings. The Listing Upload APIs cover submission of catalogue uploads, retrieval of task status for a submission, and style status reporting on cataloguing progress. The changelog marks these live. Beyond submission, Myntra's own developer centre describes a separate Listing Management area for creating listings, managing images, updating attributes and controlling activation. The public workflow document contradicts this slightly by saying catalogue updates are manual through the DIY portal, which suggests the API covers bulk submission while some attribute edits stay in the panel. Resolve this with the gated reference before committing to a listing writer.

Confirmation of writes is by task status polling on the listing side. For inventory and discounts the workflow document does not state whether the response is synchronous or a job id.

Webhooks and notifications

Myntra is push first, which is unusual for an Indian marketplace. The events Myntra sends to the seller's registered endpoint are Create Order, Update Order, Create Return and Update Return, plus the status pushes for shipped, delivered and lost on the packet id.

Subscription is manual. The seller's system generates a token, the seller shares both the callback URL and the token with Myntra on the integration ticket, and Myntra's team configures it. There is no self serve endpoint registration and no published way to list or rotate subscriptions.

Signature verification, retry policy, delivery ordering and replay are all undocumented publicly. Build the receiver defensively: idempotent on Myntra order id plus line id, tolerant of out of order status, and persisting the raw body.

For anything not pushed, poll the reconciliation APIs. Observed vendor cadence is once per day for inventory reconciliation and periodic for order reconciliation. Base runs order fetching every ten minutes, which reflects a poll of its own queue rather than of Myntra.

Rate limits and pagination

The only published number is the inventory one: batch size 10 per call, 100 calls per minute. Inventory reconciliation takes up to 40 SKUs per request, which is a batch bound rather than a rate.

No quota headers are documented. No pagination model is published for the reconciliation APIs, though they are described as time period queries, which usually means a date window plus a page or offset. Assume a date window, verify against the gated reference, and design the reader to checkpoint on the window end so a failed page can be replayed.

A practical cadence that fits the published limits: inventory push continuously at up to 100 calls per minute with absolute quantities; inventory reconciliation once daily per warehouse; order reconciliation hourly over a rolling window that overlaps the previous run; return reconciliation daily.

Mapping to the unified model

Gaps and open questions

  • The entire authentication sequence is unverified. Whether the secret key is a bearer credential or an HMAC signing key changes the credential store design. Get this from the gated reference before estimating.
  • No base URL is published for the seller facing calls. mmip.myntrainfo.com and securemmip.myntrainfo.com are documentation and dashboard hosts, not confirmed API hosts.
  • No sample request or response body for any call is public, so every field name in this page beyond the ones quoted is a name from prose, not from a schema.
  • The public workflow document says catalogue updates are manual through the DIY portal, while the developer centre advertises Listing Management APIs for creating listings and controlling activation. These two statements conflict. Assume both are partly true, with bulk submission on the API and some attribute edits in the panel.
  • Sandbox: none is advertised. Confirm whether one exists, because testing order push against production means real orders.
  • Webhook signature verification and retry policy are unknown, which is a correctness risk for the order receiver.
  • Settlement data has no confirmed API path at all.
  • The 100 calls per minute inventory limit is quoted without a date in Myntra's own document. Treat it as approximate and re-verify.

Sources