Omni API V4

1. Introduction

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

Myntra’s V4 API supports multi-line order constructs as opposed to older versions 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
-Discount can be uploaded using DIY portal also

3. Inventory Integration

Seller to share store master
Seller to send store 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 but it recommended to be close to real time
One call can contain 100 SKUs to update inventory

All communication between seller’s & Myntra’s systems will be on Myntra’s order id, Myntra order 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:

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

7. Specifics of API calls

7.1 Create Order & Update Order

In the new construct, orders will contain multiple SKUs
Every quantity will be broken in 1 order line
Customer details & address will be at order level
Customer phone no. & email will always be dummy
New encrypted parameter UIDX which is customer id
In 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
- -Line final value amount will be the net value
No totals will be shared at order level
Store level allocation will be sent at the order line level

7.2 Accept/Reject call

Accept/Reject call is at order line level
If an order is rejected, the order will be reallocated to a different store. Seller to send rejection reason in the reject call
If all the stores reject the order the order will get into unallocated status then it will be sent on default store (agreed between brand & Myntra)
If after manual intervention store code is figured out then Myntra will manually reassign a store & push the new store in order using “Reassignstore” event

7.3 RTD call

RTD is at an order line level. Partial RTD can be marked
RTD will fail if there is any error in any of the lines
If Every successful RTD will return one packet id & tracking Id along with courrier code

7.4 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 work on packet id
Invoice & Shipping labels are byte streams for a pdf

7.5 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. Forced allocation

Seller to provide a dummy store where an order can be allocated in case it can’t be accepted by any of the serviceable store
In case the inventory for the particular SKU is pushed or seller communicates this store , it will be reallocated to that store using “ReassignStore API”

10. 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 or back to initiating stores
For RTO shipments, the shipping label itself will have the required information available. Packet id will be used as return id. RTOs can be returned at stores
All the RTV shipments will have return-id (barcode) on the shipments which can be scanned to fetch corresponding order-id in seller systems in order process an inward at store/ warehouse

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 7 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