The Offering Discovery Protocol (ODP) gives agents a consistent way to read your catalog. An Offering describes something available from your service, such as a report, a download, or a search operation. Its Actions tell the agent where and how to request that product or operation.

Build those descriptions from your existing products or API operations. Keep your catalog as the source of product data; adding ODP does not require maintaining a second inventory. For example, a report Offering can describe the report and expose an Action for requesting it from your existing endpoint.

Advertise the enrollment and payment capabilities your service supports. The endpoint still checks access and handles payment when the agent requests the report. Reading an Offering or its Action does not make a purchase.

Follow Build a Service to publish your catalog. For the caller’s side, Discover a Service explains how an agent finds and reads it.

The Agent Enrollment Protocol (AEP) lets an agent introduce a verifiable identity to your service. Your service decides whether to accept the enrollment. After enrollment, your application still decides which products or operations that agent may access.

Your service advertises the authentication methods its protected endpoints accept. It may issue a session credential, such as an API key, for later requests. Session credentials are optional: an agent can enroll without requesting one and follows the service’s advertised methods when accessing protected endpoints.

A service-issued credential authenticates the agent to that service. An InFlow API key authenticates requests to InFlow. Use the service credential for its protected endpoint and the InFlow key only for InFlow API calls.

Start with Publish an Inspect document to advertise your service’s requirements, then follow the service quickstart through enrollment and resource protection. Agent developers can start with Inspect a Service. The Protected-resource access guide explains credential selection and presentation.

Suppose your service sells generated reports and requires agents to enroll before purchasing one. An agent buying a report follows this sequence:

1. Discover the report Offering and read its Action to determine the target endpoint and request parameters.
2. Read the service’s AEP requirements, complete enrollment if needed, and authenticate the report request with an accepted method. The service checks whether the agent may request that report.
3. Use a compatible buyer to satisfy the endpoint’s live MPP or x402 payment requirement, subject to the payer’s approval and spending rules.
4. Receive the requested report and check the payment outcome. If the request is interrupted, follow the original transaction before starting another purchase.

An agent that already knows the endpoint can start without ODP discovery. An endpoint that does not require AEP can accept payment without enrollment. When both apply, the service authenticates the request before processing payment.

Use AEP protocol composition for combining authentication and payment headers. Deliver paid results explains when your handler runs relative to settlement for the selected integration. Follow Status and recovery for interrupted purchases.

When adding multiple capabilities, we recommend Payments, then AEP, then ODP. Skip capabilities you have not selected. The payment integration establishes the paid operations. AEP adds agent enrollment and authenticated access. ODP then describes those products, Actions, and supported protocols.

This recommended build order reduces revisions to discovery documents while the underlying behavior is changing. It is different from the order an agent follows when buying a report. Keep existing authentication in place throughout the work; adding payment does not require opening protected endpoints.

The Directory’s coding-agent integration guide helps you choose all three capabilities or a subset. It coordinates the individual guides, with a plan and review checkpoints for each integration. You can re-run the guide to add another capability or improve an existing integration.

Check your deployed ODP documents and advertised operations with Validate an integration. Confirm that Offerings describe the intended products and their Actions reach the working endpoints.

To help agents find your service, publish it to the InFlow Directory. Submit the service’s public HTTPS origin after validation. The Directory indexes service information; agents read the current catalog from your service. Publication is optional and is not required to accept payments.

Separately test the complete journey you offer: discovery, required enrollment and authentication, payment, and delivery. A Directory listing does not establish that enrollment or payment succeeds. Follow Test your integration for payment scenarios, alongside your application’s own tests. Authorize any test that spends funds before running it.