Skip to main content
Copy the list of ODP services in the InFlow directory into your own platform with its public API. You need no InFlow account, no login, and no API key. The directory gives you the list of services, not their catalogs. To read the offerings of a service, connect to that service with the ODP agent SDK.

List the services

Call the service search endpoint without a search phrase.
The response contains the published, visible services that have a valid ODP document.

Get every page

  • The default page size is 50. The maximum is 100.
  • Send a GET request to the next URL. Continue until the response has no next field.
  • A relative next URL resolves against https://api.inflowpay.ai.
  • Treat the next URL as opaque. Do not build it or change its cursor.

List the services with the Node SDK

The client follows the continuation links. It reads https://directory.offeringprotocol.org, and you cannot change this URL. For the sandbox, use createDirectoryClient({ environment: "sandbox" }).
Always check page.issues. The client puts malformed entries there and leaves them out of items, without failing the page. Without this check, you can lose entries and not know it.

Fields that the SDK leaves out

The directory SDK leaves out these service document fields, because its parser does not validate them. branding, mcp, http, odp_version, payment_origins, search_capabilities To get one of these fields, call the API directly, or read the live Service Document of the service.

SDKs for other languages

Each ODP SDK includes directory support. The method names and the iteration APIs differ by language. Each repository documents its directory client.

Keep a local copy in sync

For a small directory, use this approach.
1

Get the full list on a schedule

Read every page of the list at a regular interval.
2

Key each entry by its origin

Store or update each entry with service_origin as the key.
3

Replace the old copy only after a full read

Replace the previous copy only when every page loads with no rejected entries. Only then remove the entries that are missing from the new list.
4

Keep the old copy on failure

If a request fails, keep the previous copy.
The list is a paginated discovery listing, not a transactional database snapshot or an incremental change feed. You do not need a separate bulk export.

Read the catalog of a service

The directory entry is cached discovery metadata. To read the current catalog, connect to the service at its service_origin with the ODP agent SDK.
If getOffering cannot resolve the attributes, read the returned issues. Do not assume that the offering has no attributes.

Use only the advertised operations

A service without list-offerings and get-offering does not have an empty catalog. Some services use search or collections instead. Check the advertised operations. Then use searchOfferings(), listCollections(), or listCollectionOfferings(collectionId) as the service supports.

Catalogs can need authentication or payment

The directory API is public, but the catalog operations of a service can need authentication or payment. Before you read a catalog, check the authentication value of each operation and the advertised payment protocols. Authenticated or paid access needs its own code.
A protected catalog or an unavailable catalog is not an empty catalog. Never record a service as having no offerings because a catalog call failed.
These calls only read data. They do not invoke the actions of an offering or buy anything. The agent SDK also supports authentication, pagination, caching, and action resolution. See the packages/agent folder in offering-protocol/odp-node.

The InFlow directory

Read what a listing shows, and search the directory with the CLI.

Discovery with ODP

Read how services, collections, offerings, and actions fit together.
Last modified on October 15, 2026