Skip to main content
Discovery is Step 3 of the InFlow integration. With ODP, the Offering Discovery Protocol, agents find your products, read their details, and find the actions to use or buy them. See Discovery with ODP for the terms. Start from what your application already does, not from an SDK example. Back every offering with real application data. To build this with a coding agent, see Integrate with a coding agent.

​
Step 1: Choose an SDK

The Python SDK is also on PyPI as offering-protocol. It needs Python 3.11 or later.

​
Step 2: Choose a level

Without search, an agent must list your whole catalog to find one product.

​
Step 3: Describe offerings and actions

An offering is one product. An action is an operation that an agent can do on that offering, for example a purchase. Give each offering:
  • A clear name and description.
  • The price and the currency.
  • The actions that use or buy it.
Describe the endpoint of each action as it already works, with its authentication and payment behavior. If the endpoint needs enrollment, say so. If the endpoint needs payment, the price in ODP must match the price in its 402 challenge. Group related offerings into collections, so that agents can move through a large catalog. Every list and search operation returns pages. When more items exist, the page must contain next. The last page must omit next. next must be a URL that the agent can request with GET. It must resolve to the same origin as the first request. Do not return a bare cursor. The correct value is only an example. Use your own continuation mechanism. Keep the request context in the link: the representation, filters, search terms, sort order, and page size. The agent follows next as it is, and does not decode the cursor or build a URL.
If next is not a usable URL, ODP clients reject the whole page. The directory then shows no collection or offering previews for your service. Do not remove next to fix this, or agents do not get your other pages.
Test every list operation that you advertise, including the offerings of each collection. Follow each next link. Make sure that each page advances, that no item is missing or repeated, and that the last page has no next. Validate each page against ODP. For the full rules, read the Pagination section of the ODP specification.

​
Step 4: Publish the Service Document

Serve the ODP Service Document at /.well-known/odp on your origin. The document must be public. Declare only the operations that you implement. For the document format, read offeringprotocol.org.

​
Step 5: Check discovery

Run your service. Then read your catalog as an agent does.
Check each offering for a description, a price, a currency, and at least one action. Then compare each listed price with the real charge. resolve turns an action into a request without sending it. mpp inspect or x402 inspect sends that request and shows the 402 challenge. Neither command pays.
The price and the currency in ODP must match the amount and the currency in the challenge. After you change your Service Document, add --refresh to inflow inspect to validate the public documents again.

​
List with an OpenAPI document

ODP is the native discovery format of InFlow. The directory also accepts a JSON OpenAPI 3.x document. Agents then read your operations with inflow openapi operations. See Publish to the directory.

​
Next step

Launch: Go live

Move the tested integration to production.
Last modified on October 15, 2026