FAQs
- Kamaldeep Sharma
We are already integrated with logistic partners. Our sellers will use these logistic partners’ services to deliver the order to customers. Sellers can do the delivery by their local delivery boy as well in case of hyper-local delivery. Let us know if it will work for us as a TSP provider to go live in MVP.
Yes, Off-network logistics will also work temporarily but we would strongly advise you to please integrate with the On-network logistics
What should be the response time of on_search, On_select, On_init, and other APIS after acknowledging the request from search, select and another API?
The protocol will define the message validity but the final say will be from the respective buyer apps to have a better user experience.
If we acknowledge the request of search API and if we did not find any SKUs with the seller then what should we send to you in On_search API?
Empty item array in the catalog
Can sellers cancel the orders after sending the status: accepted in On_Confirm API?
Yes, but it should be done only when there is a valid reason and in exception scenarios. The seller app is responsible for maintaining the correct order and fulfilment state at their end.
What will be the final status where the customer cancels the order in ondc?
Order state will be “Cancelled”
We are not taking the replacement feature for MVP? Can we go live without a replacement feature?
Yes, you can but you should state the timeline by when it will be implemented. Further, return has to be enabled and replacement can be enabled through a return and a new order. Pls check the API contract
What are the main statuses at the order level? we found the below status on GitHub. Are these final statuses for retail? can you please arrange the details of these statuses at the order level and item level?
Please check the API contract
Order. State (retail): | Fulfillment State Codes (Retail): |
|---|---|
Created | "Serviceable" |
Accepted | "Non-serviceable" |
In-progress | "Pending" |
Completed | "Packed" |
Cancelled | "Order-picked-up" |
| "Out-for-delivery" |
| "Order-delivered" |
| "RTO-Initiated" |
| "RTO-Delivered" |
| "Cancelled" |
The case where sellers are using their courier partner to deliver the order to the customer, we need to share the breakup of delivery charges and packaging charges in the On_select API. Can we pass 0 value to these parameters since sellers’ delivery, packing, and other charges are included in the selling price?
No need to include them.
Details for your reference:
{
“@ondc/org/item_id”: “Fulfillment1”,
"title": "Delivery charges",
“@ondc/org/title_type”: “ delivery”,
"price":
{
"currency": "INR",
"value": "0"
}
},
{
“@ondc/org/item_id”: “Fulfillment1”,
"title": "Packing charges",
“@ondc/org/title_type”: “packing”,
"price":
{
"currency": "INR",
"value": "0"
}
}
What is the format of validity of message in context? How we will understand and calculate this Validity? What is the meaning of PT? should be send immediate NACK if validity expire? Will we get the the same search request again from buyer once validity expired.
"ttl":"PT30S" (context ttl is in ISO8601 duration format. It is a universal standard format) For now, ONDC has defined this
validity and set it as 30 seconds (represented as PT30S) Yes, if a response is received after that ttl (validity), the participant can send a NACK.
Once I will received one search request from any buyer app, I will send you ack immediately but I have multiple sellers then should I send you On_Search for every seller against one search? If yes then how would I can see in one payload only one contextin on_search?
As discussed on meeting, as vinculum is participating as a TSP(adaptor) then against one search request vinculum has to send multiple(On_search) one callback for each seller.
Difference between bpp/descriptor and bpp/providers? I am considering Vinculum is bpp/descriptor and Vinculum sellers as bpp/providers who fulfill orders. I am not considering the bpp/providers details for each location under one seller. Please confirm if we have the same understanding of this? Also Why is bpp/descriptor required if we are TSP and where it will be visible?
Understanding is correct.
But as TSP, Vinculum will be bringing in sellers as Network Participants who will be BPPs themselves, and the providers/ stores under those sellers will be providers
What is the objective to share Provider enable and disable and timestamp details in on_search?
At the time of catalogue share, the tag helps buyer apps identify whether the store is functional at the time or is closed/ disabled for the time.
If we will share catalogue of active sellers only then will it impact any functionality?
Please elaborate on the search flow, at what time are you proposing sending the catalogue of the active sellers
Label and timestamp is optional or mandatory?
Mandatory
What is the importance of "ttl":"P1D" in on_search? What is the exact use case and expected functionality from TSP providers ?
Time Validity of the Catalogue ( Please refer the Comments ). Catalogue expires after that TTL, buyer apps who are caching catalogues provided by the sellers should be creating a fresh search request again once the ttl expires to get the latest catalogue details
How do we identify which fields are mandatory and which are non-mandatory ?
All attributes mentioned in the API contract are mandatory. Optional attributes are mentioned as optional in the footnotes
What is "id" in Location in On_search API? What value should be passed in this? what is the use of this id in ONDC network or for buyer app?
Location.id is used to identify location level segregation for sellers. e.g. sellers may have different storefronts at different locations. Buyer apps may list these separately as individual “stores” or list a provider level listing with individual locations mentioned in the store page. The serviceability and category id is mentioned at the location level.
We are not passing the gps and Radius tags values in On_searc API? Is there any blocker in On_search integration?
This is mandatory at a seller/ provider level. Given that Vinculum is coming as a TSP, the “platform” should have the functionality for sellers to provide their GPS and radius within which they will be servicing
What is the intent to identify the city wise search in the search API ?
Catalogue pull at a city level identifying sellers servicing in the city.
For city wise search filter, city is provided in the context part of the search payload. The corresponding on_search response will consist of all the items/catalog provided by a seller NP in that particular city.
If one location of the seller is able to serve self pickup and Delivery fulfillment then should i pass all three ids or only id =3.
Yes, 3 needs to be sent
"bpp/fulfillments":
[
{
"id":"1",
"type":"Delivery"
},
{
"id":"2",
"type":"Self-Pickup"
},
{
"id":"3",
"type":"Delivery and Self-Pickup"
}
]
Please define "id” tag value in item tag.
item.id is used to identify the items in the catalog
What value i need to pass in the tag given below:
First sample image of the Product for product listing
"symbol":"https://abc.com/images/07.png",What is price.maximum_value and price.value? please Maximum_value is MRP and value is selling price?
The understanding is correct
What value should I pass in Qty.maximum.Count?
Qty.Available <= Qty. Maximum
What value should i pass to fulfillment_id":"1 ?
This attribute shows which type of fulfillment is available for that item. There are three fulfillments types that are provided as part of the on_search payload. One of them has to be provided here to identify the type of fulfillment for this item
What is the meaning of this tag ? "recommended":true.
This is for the offers like 1. Buy x no of items, get y no of items (e.g. buy 2 get 3 for an item);
Discounts (flat or % discount up to an amount);3. Freebie (get one or more items free if order value beyond certain amount);
But currently not enabled on network
Kindly explain Serviceability construct in detail.
What exactly are bpp/descriptor and bpp/providers ? bpp/descriptor - seller details ?bpp/providers - location details ?
bpp/descriptor - seller app details
bpp/ provider - seller's details
bpp/provider/location - various locations of the seller