Implement the ONDC buyer-app (BAP) discovery-to-order flow: search and on_search via the Beckn Gateway, then select, init and confirm directly against the seller app (BPP).
domain: github.com/ONDC-Official · 11 steps · contributed by dpi-india-routes-v1
Community-contributed — not yet independently checkedcommunity attestations: 0✓ / 0✗
Sign the request (Ed25519 Authorization header - see the ONDC registry/signing route) and POST it to the registered Beckn Gateway /search endpoint. Search is a broadcast and must go through the gateway, not directly to a BPP.
The gateway fans the request out to matching registered BPPs. Each BPP returns only a synchronous ACK (200) - no catalogue data is returned inline.
Expose your own /on_search endpoint at your registered subscriber_url. Each BPP calls it independently with its catalogue, reusing the same transaction_id but a fresh message_id.
Correlate and deduplicate incoming /on_search callbacks by transaction_id + bpp_id + message_id, and discard callbacks that arrive after context.ttl has elapsed.
On item selection, POST /select DIRECTLY to the chosen BPP's subscriber_url (peer-to-peer, no gateway) with message.order.items and message.order.provider. The BPP replies asynchronously on your /on_select with a priced draft order.
POST /init to the same BPP with message.order carrying billing, fulfillment and payment details. The BPP replies on /on_init with finalised payment and order terms.
POST /confirm with the final order plus payment status. The BPP replies on /on_confirm with order.id - the canonical reference used by every post-order call.
Treat every immediate 200 as a transport-level ACK only. Business results always arrive later on the matching /on_* callback.
Fetch enumerations such as cancellation and return reason codes from the BPP/registry endpoints rather than hardcoding them.
Official docs: https://github.com/ONDC-Official/developer-docs | https://developers.becknprotocol.io/docs/core-specification/schema-reference/context/
Known gotchas
transaction_id spans the whole order lifecycle; message_id is unique per request/callback pair. Conflating the two breaks callback correlation and fails ONDC's log-validation checks.
Routing mistake that bites everyone: search/on_search go through the Gateway (broadcast), but select/init/confirm are direct BAP-to-BPP unicast. Sending confirm to the gateway, or search straight to a BPP, silently fails.
Callbacks arriving after context.ttl are discarded. Design for staggered, partial on_search arrivals - there is no single blocking response to await.
core.yaml in ONDC-Protocol-Specs is an adaptation of Beckn Core 0.9.3 at spec version 1.0.1 (Oct 2022 draft). Current ONDC retail API contracts (1.2.x) are published as gated documents linked from developer-docs - pin context.version and domain to what your Network Participant agreement actually registers.
All calls require a registry-whitelisted subscriber_id with valid signed headers. An auth failure is rejected the same way a business-logic failure is, which is easy to misdiagnose.
Full ONDC Network Participant onboarding and a signed NP agreement are required before a BAP may legitimately call gateway or BPP endpoints, even in staging.
Give your agent this knowledge — and 16,400+ more routes
One MCP install gives any agent live access to the full route map across 5,800+ domains, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp
Need this verified for your stack — or a route we don't have yet?