Navigate ODP from the terminal

Use one interface for people and Agents

The InFlow CLI exposes the same ODP navigation flow in two forms. An interactive terminal receives readable tables and detail views, while an Agent or automation can request a structured result with an explicit output format. Both forms use the same validated ODP client underneath.

Install the InFlow CLI

The hosted installer selects and verifies the native package for macOS or Linux. Windows users can install through WinGet, and macOS users can alternatively use the Homebrew Cask. The complete platform instructions are available at inflowcli.ai.

curl -fsSL https://inflowcli.ai/install.sh | bash
inflow --version

Choose the right inspection command

Use the combined inspector when the protocols protecting a URL are unknown. It retrieves discovery metadata and sends a live HTTP probe to the supplied URL using the selected method. It does not enroll or pay, but the probe itself reaches the target, so use a safe URL and method. Use the focused ODP inspector when the goal is to read the Service Document without probing a catalog or Action endpoint.

inflow inspect https://demo.inflowpay.ai
inflow odp inspect https://demo.inflowpay.ai

• inflow inspect: inspect a URL across discovery, enrollment, and payment protocols
• inflow odp inspect: retrieve the ODP Service Document, canonical origin, resolved links, and advertised operations

Navigate the ODP command groups

Each command group represents a distinct stage of discovery. Directory commands select a Service. Collection and Offering commands query that Service directly. Action resolution describes an executable request but stops before execution.

Follow the Service's advertised operations

Before an initial Collection or Offering request, the CLI inspects the Service and verifies that the required operation is advertised. Action resolution retrieves the Full Offering through get-offering and resolves only an Action advertised by that Offering. The CLI does not construct an endpoint from a familiar path or assume that every Service implements optional search.

Resolve search capabilities before filtering

Text search can be sent directly when search-offerings is advertised. Structured filters, refinements, and sort identifiers come from the Service's effective search-capability catalog and must not be invented from Offering field names.

inflow odp offerings capabilities https://demo.inflowpay.ai
inflow odp offerings search https://demo.inflowpay.ai web

The capabilities command resolves Service-wide definitions and, when --collection-id is supplied, definitions attached to that exact Collection. Use the returned identifiers with repeatable --filter and --refinement flags or with --sort.

Bound discovery across Services

inflow odp offerings discover first selects Services through the Directory and then sends the Offering query and catalog criteria directly to each selected Service. Use --max-services, --max-offerings-per-service, and --concurrency to bound that fan-out.

Each selected Service can observe the query sent to it. The aggregate CLI result contains successful Offering matches and omits individual Service issue events. Use a direct per-Service command when the caller needs to inspect or report why one selected Service failed.

Continue without interpreting the cursor

Directory, Collection, and Offering sequences can return an opaque next value. Interactive output prints a ready-to-run continuation command. Structured consumers pass the value through --next exactly as received.

inflow odp offerings list https://demo.inflowpay.ai --next '<opaque-next-value>'

A continuation resumes the operation that produced it. Do not combine it with a new query, limit, Collection, filter, refinement, or sort; start a new search when those inputs change.

Resolve an Action without invoking it

A Full Offering can advertise one or more Actions. Select an Action by its identifier and resolve it to obtain its method, target, content type, input constraints, and response types. Resolution remains a discovery operation.

inflow odp actions resolve https://demo.inflowpay.ai search invoke

The command does not send the resolved request, perform enrollment, or initiate payment. After reviewing the contract, the caller separately decides whether to construct and execute the request through the protocol protecting the target.

Begin discovery without a login

Directory search and focused ODP Service inspection are public operations and require no InFlow login. A direct catalog request can also complete anonymously when the Service permits it.

For a protected catalog request, the CLI follows the Service's AEP OpenAPI policy or a live AEP challenge. A known required policy permits authentication on the first request; otherwise, the CLI attempts the request anonymously before responding to a challenge. It can use a compatible stored Service credential or initiate the required AEP grant flow, which can require an InFlow login and human approval.

Credentials remain scoped to the Service that established them. Executing a resolved target and satisfying an MPP or x402 payment requirement remain separate commands and policy decisions.

Choose output for the next consumer

The default terminal view favors scanning and copying identifiers. An Agent or pipeline should set --format explicitly so the result remains machine-readable even when standard output is redirected or no terminal is attached.

Keep discovery failures actionable

ODP failures carry a stable error code and a direct explanation. The CLI distinguishes a malformed Service Document, an unsupported operation, a remote HTTP failure, an invalid continuation combination, and a supporting resource such as an Attribute Schema that could not be resolved.

A supporting-resource issue can leave the surrounding Offering usable while identifying the unavailable capability. A failed operation does not cause the CLI to probe another unadvertised endpoint, discard the caller's criteria, or silently convert a protected request into an anonymous result.

Next steps