PPMP API V4

1. Introduction

This document states the integration workflow for PPMP integration between seller/partner and Myntra.com using Myntra’s V4 version of APIs

Myntra’s V4 API supports multi line order construct as opposed to older version of APIs. This is a configuration at a seller level. However it is a business decision to support multi line order for a particular seller

2. Catalog Integration

Catalog can be manually updated through Myntra’s DIY portal.

Pricing will have to be the same across all sizes for a given style and has to be updated with catalog upload

Using Update Discount API Seller can push discounts (x-partner-store = myntra is mandatory)

-No decimals allowed
-date range can’t have past dates
-difference between start date & end date can’t be more than 6 months

3. Inventory Integration

Seller to share warehouse master
Seller to send facility wise incremental inventory using inventory push API
Inventory number has to be absolute & inclusive of all open orders (available to sell + inventory mapped to Myntra’s active orders) till the order are ready to be dispatched
The frequency can be mutually agreed or can be real time also
One call can contain a batch size of 10 with a limit of 100 requests per minute
This is applicable to any kind of full sync as well as BAU incremental sync.

All communication between seller’s & Myntra’s systems will be on Myntra’s order id, Myntra line id & Seller’s SKU no

4. Order Interaction flow at a glance

5. Order Workflow (Myntra generated invoice & Seller OMS)

6. Order Workflow (Seller generated invoice)

Please note:

1. Seller needs to share an additional API which will render a PDF file for seller’s invoice copy once “Shipped” status update is sent to seller systems

2. Seller systems are supposed to generate manifest in their own systems & get it signed by Myntra’s 1st mile picker. Seller needs to maintain this manifest copy for handling disputes

7. Specifics of API calls

7.1 Create Order & Update Order

In the new construct, PPMP orders will contain multiple SKUs & quantity
Every quantity will be broken in 1 order line
Customer details & address will be at order level
New encrypted parameter UIDX will get introduced which will be stored (it is customer id)
All the other information will be at order line level -
- -A new array for different charges “Charges” will be applicable
- -Charges can contain - shipping(at order level too), discount, MRP, tax
- -Line final value amount will be the net value
No totals will be shared at order level

7.2 RTD call

RTD is at an order line level. No cancellation before RTD is now mandatory. Partial RTD can be marked
RTD will fail if there is any error in any of the lines
Every successful RTD will return one packet id & tracking Id

7.3 Download Invoice & Shipping label

ShippingLabel and Download Invoice will now be done on Packet Id
For download invoice in case of seller generated invoice will also work on packet id
File stream to be rendered instead of pdf

7.4 Update Order

Shipped & Delivered status will be pushed on packet id to seller systems by Myntra
Hold & unhold will be on pushed on order id & order line id

8. Cancellation

Order line can be marked as cancelled by the seller or by customer
Once the order line is RTDed seller cannot cancel a line. Seller cancellation will be treated as vendor failed to supply
Customer cancellation can be accepted till RTD status
Order will be canceled if it is open for more than 3 days by Myntra operations team with reason code “Vendor failed to supply”
Customer order cancellation request before packed will be pushed back to Seller

9. Returns

Once customer initiates return request - it will be picked by delivery executive and it will reach Myntra hub / warehouse - from there it will be shipped to brands by Myntra logistics to single warehouse of seller
For RTO shipments, the shipping label itself will have the required information available. Packet id will be used as return id
All the RTV shipments will have return-id (barcode) on the shipments which can be scanned to the corresponding order-id

Returns Flow Summary

3PL picks up the products from customers & does one level of QC at the doorstep
When a customer initiates the return & money is refunded to the customer, the seller receives a trigger “Return created” with a return id
When the merchandise is outscanned from Myntra hub seller gets a status update “Ready for Return”
When finally it reaches the customer & POD is signed seller gets a status update “Return Delivered”
If the goods received at the warehouse are not in acceptable condition seller needs to apply under Seller Protection Fund Policy within 30 days of receipt of goods in an offline process

API Flow (Outbound APIs)

1. Create Return

Whenever a return request is initiated & pushed to seller, it contains type COURIER_RETURN (for RTO), CUSTOMER_RETURN (for RTV) & status = Confirmed
Return Id is in body

2. Return in-transit (Update Return)

When the returns leave the return hub seller recvs. another call which says status = READY_FOR_PICKUP with return id

3. Return Closed(Update Return)

Post the in-transit call the return can be either canceled or delivered at seller warehouse
Seller receives the return delivered call post the POD upload in Myntra LMS systems with status = DELIVERED
If for some reason the return is cancelled status "DECLINED" will be pushed to seller system in the same API