> ## Documentation Index
> Fetch the complete documentation index at: https://ifdocdemo.lumivescence.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Make your products discoverable

> Describe your offerings and actions with ODP, so that agents can find your products, read their details, and use or buy them.

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](/concepts/discovery) 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](/sellers/integrate-with-a-coding-agent).

## Step 1: Choose an SDK

| Language | GitHub repository |
| - | - |
| Go | `offering-protocol/odp-go` |
| Java | `offering-protocol/odp-java` |
| Node.js and TypeScript | `offering-protocol/odp-node` |
| Python | `offering-protocol/odp-python` |
| Rust | `offering-protocol/odp-rust` |

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

## Step 2: Choose a level

| Level | What you implement |
| - | - |
| Minimal | A conformant Service Document and the `list-offerings` and `get-offering` operations, with real application data. |
| Recommended | Minimal, plus descriptions, images, prices, and actions. Add search and collections. |
| Complete | Every discovery feature that fits your service. Examples are richer search, filters, attribute schemas, localization, and catalog relationships. |

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.

### Return usable `next` links

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.

| Wrong | Correct |
| - | - |
| `"next": "Mw"` | `"next": "/odp/collections?limit=3&representation=terse&cursor=Mw"` |

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.

<Warning>
  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.
</Warning>

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](https://offeringprotocol.org/draft/).

## 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](https://www.offeringprotocol.org/).

## Step 5: Check discovery

Run your service. Then read your catalog as an agent does.

```bash theme={null}
ORIGIN=https://api.example.com
inflow odp inspect $ORIGIN
inflow odp collections list $ORIGIN
inflow odp offerings list $ORIGIN
inflow odp offerings get $ORIGIN <offering-id>
```

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.

```bash theme={null}
inflow odp actions resolve $ORIGIN <offering-id> <action-id>
inflow mpp inspect <url-from-the-resolved-request>
```

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](/sellers/publish-to-the-directory).

## Next step

<Card title="Launch: Go live" icon="rocket" href="/sellers/go-live">
  Move the tested integration to production.
</Card>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.