This guide will walk through the end to end requirements and flow to develop the APIs required to facilitate the transaction between consumer and provider.

Do you need assistance in building the buyer or seller apps? Go through ONDC reference buyer and seller apps source code to help you get started.

ONDC reference Buyer APP:

ONDC reference Seller APP:

note

API Specifications

ONDC API contracts map business requirements for various use case scenarios to a set of attribute keys in different APIs and ensures interoperability, between a buyer app & seller app, as follows:

• by defining the set of attribute keys that need to be exchanged to establish a handshake between the buyer app & seller app;

• clearly defining the single source of truth for each attribute key and thereby establishing mutability & immutability of these keys on behalf of the participants at each end of the transaction;

59b54eee-861c-4cf1-a2aa-a2167dbd6618f3419816-cc5c-4118-a38f-ca8a68beb40aDECIDEDRetail

• Retail

Retail Domains live in ONDC:

ONDC APIs is built as an extension to Beckn protocol and closely follows the standards of Open API.

Refer to the complete API specs and try the APIs in swagger hub:

Please refer our API contract to understand the attributes usage and retail specific use cases implemented. These API contracts will help you understand the single source of truth for each attribute key and thereby establishing mutability & immutability of these keys on behalf of the participants at each end of the transaction.

Retail B2C transaction contract between Retail Buyer and Seller:

There is a new version released for retail, which is currently being developed by the existing network participants in staging and pre-prod environment. The new version (v1.2.0) released includes Variants, customization, Add-ons, cross-categories, offers and much more. All the new network participants are expected to develop on the newer version v1.2.0.

Refer to the logistics API contract to understand the attributes usage and retail specific use cases implemented. These API contracts will help you understand the single source of truth for each attribute key and thereby establishing mutability & immutability of these keys on behalf of the participants at each end of the transaction.

There is a new version released for Logistics, which is currently being developed by the existing network participants in staging and pre-prod environment. All the new network participants are expected to develop on the newer version v1.2.0.

Logistics transaction contract between Logistics Provider and Consumer:

17797645-15ad-40f4-a301-48b2ef3bb1d4b7ae2075-c8bb-4642-a2c4-b60da6ad57cdDECIDEDB2B

• B2B

Please refer our API contract to understand the attributes usage and retail specific use cases implemented. These API contracts will help you understand the single source of truth for each attribute key and thereby establishing mutability & immutability of these keys on behalf of the participants at each end of the transaction.

The API contract here elaborates the process flows for buying gift cards on the network across four phases of order processing flow of discovery of gift cards available on the network, order placement, fulfillment of the order and post fulfillment requirements.

cba7552b-1818-4ff7-b38a-4855d90086cfcb008271-7ffe-41d5-8ff4-583a4aa09fc9DECIDEDMobility

• Mobility

Shreyansh Shah to update

8b6b0bf9-486b-4c79-a014-d0abe26bf26db617d4b8-5ab3-4089-b8f3-46539c50e4f2DECIDEDFinancial Serivices

• Financial Serivices

Shreyansh Shah to update

The Issue & Grievance Management (IGM) for ONDC is a mechanism via which issues between users of the network are resolved. The IGM flow has been developed based on the Issue & Grievance Management framework which acts as a facilitator to resolve issues, grievances and disputes between a Complainant and Respondent in a manner that ensures transparency, fairness and data security to the parties. The framework is built on the interactions on a tripartite Network Participants (NPs) contract for a unique transaction including logistics services by Logistics Service Provider (LSP)  that has been procured on-network. This implies that a complainant shall be raising an issue for a particular transaction on the network which may involve buyer app, seller app, logistics service provider app or any other participants as may be notified by ONDC as identified entities for a given transaction.

Try the APIs on swagger hub:

Refer to IGM API contract here:

The objective is to propose a Reconciliation and Settlement framework for Network Participants (NP), such as Buyer Platforms, Seller Platforms, Logistics Platform etc, on ONDC. The construct defined will provide a framework for participants to settle funds against transactions to respective parties and create an audit trail of transactions. Following are the enumerated design principles for reconciliation and settlement framework:

1. Enable seamless settlement of funds collected by participants

2. Non-repudiable information dissemination all through network entities

3. Maintaining Audit trail to ensure evidence security 

4. Defining standards of message communication for transparency, efficiency and machine readability of Information

5. Building trust through safeguarding fund flow for a transaction through well defined triggers for money withdrawal from Nodal Like account

6. Ensuring non-repudiability through digital signatures and payload authentication

7. Seamless integration using protocol with all stakeholders including settlement agency, reconciliation service providers and participants

Try the APIs on swagger hub:

Refer to RSP API contract here:

The serviceability construct will allow a buyer app to display catalogs, for only those stores, that can fulfill orders for a buyer, at a specific time, at their location.

Please go through the serviceability construct here

City-State codes are defined here:

The objective is to propose process flows for Cancellation, Return & Replacement. Cancellation, Return & Replacement can be processed by Buyer & Seller Apps, using existing protocol APIs. The detailed process flows and sequence diagrams are defined below.

This note proposes detailed process flows for the following:

• Cancellation - for the full order or for part of an order, i.e. some of the items in an order;

• Return - for one or more items in an order. A part return will be defined as return of one or more items in an order but not return of all items in the order. A full return will be defined as the return of all items in the order.

• Replacement - for one or more items in an order. A part replacement will be defined as replacement of one or more items in an order but not replacement of all items in the order. A full replacement will be defined as the replacement of all items in the order. Note that a replacement can also be handled by part or full return of the order and creating a new order with the items that are being partly or fully replaced.

Please go through the complete flow here:

Error Codes