Inside APIX: How a Proposed Directory Could Help Software Agents Find APIs

Software agents, programs that choose and use services, need a reliable way to find APIs and compare what they offer. API Index, or APIX, is a proposal for a shared directory where agents could search structured service descriptions that software can read. They could also review trust information and find documentation. The agent would then contact the service it chose directly.

APIX remains a proposal, not an established global directory. As of November 8, 2026, its core specification is an individual IETF Internet-Draft. The IETF has not adopted it as an official standard. The draft describes the design in detail, but the available evidence does not show that a live index operates worldwide at large scale.

How an agent would discover a service

A service owner would publish an APIX Manifest, a structured description of the service. It links to the service’s technical specification, which describes how the service works, and records its capabilities. The manifest also includes trust signals and commercial terms. This gives software a consistent starting point for assessing the service instead of having to work out those details from web pages.

An agent would start at a stable APIX address, search the directory, and follow links in the results to service records and related information. The proposed interface uses HATEOAS, short for “Hypermedia as the Engine of Application State.” The server returns links that tell the client where to go next. The client follows those links rather than guessing the addresses of API endpoints. Search filters could cover capabilities, communication protocols, ways to authenticate, pricing models, and deployment regions, according to the APIX Core draft.

APIX gives agents a common way to find services, while leaving how they use those services unspecified. APIX would not route an agent’s API call or handle authentication or payment for a service. After choosing a service, the agent would connect directly to infrastructure run by that service’s owner. APIX would not take part in the transaction, so the agent would need to understand and meet the service’s requirements.

What the trust signals mean

APIX separates trust into three dimensions. Organization trust covers checks of the owner’s identity and how it meets applicable requirements. Service verification covers checks of the service or its technical specification. Liveness records whether the service appears to be available.

One “verified” label cannot answer every question about trust. The core draft defines separate levels for organization and service verification. It describes checks such as retrieving and reading an API specification, comparing the specification’s listed structure across checks, and recording how often the service is available. These are proposed methods. Their inclusion in the draft does not show that an operator has carried them out consistently in a live service.

An agent should judge the available evidence according to its own rules. For a task with little risk if something goes wrong, it might accept a service with limited verification. For a sensitive task, it should require stronger evidence and assess the service’s security practices. The draft explicitly warns against relying on index presence alone for consequential use, especially when an organization registered itself and no one checked it.

Why connected devices need a different profile

A directory for web APIs can check whether a documented endpoint responds. For connected devices, publishing a specific device’s online status or network address could reveal information about its owner. The APIX IoT Device Profile, for example, separates public details about a type of device from private details about an individual device.

Anyone could look up a device type, including its capabilities and supported communication protocol. An anonymous search would not return an individual device’s address or online status. It would also withhold the device’s operating state. The profile requires authorization from the device owner before anyone can access information about a specific device. It also handles availability differently: devices send presence signals, instead of an index crawler checking them as it would web APIs.

These safeguards are requirements in a draft, and their real-world protection depends on how an operator handles permissions, owners granting access to others, and sensitive requests. A device maker or index operator evaluating the profile should examine these controls as well as the rules for public and private data.

What the proposal does not establish

The core draft includes an example response that lists 12,483 services, but that number appears as sample payload data. It does not verify the size of a live index. Similarly, the draft estimates a 70–85% reduction in typical search-result payload size when transport compression is used, but the reviewed evidence does not include independent benchmark results.

The draft’s funding plan is also unproven. It proposes free discovery queries funded primarily by service-owner registration fees. This would mean agents do not pay for each search, but the proposal does not set actual fees or show how many owners would take part or whether the funding would last.

With a central index, APIX could make searches consistent and service records easier to compare, but the index operator would carry the operational responsibility. In a federated approach, organizations would publish and manage separate directories. This could reduce reliance on one operator, but make it harder to search across directories and keep their information consistent. The draft discusses both approaches but offers no independent assessment of which works better.

How to assess APIX today

Treat APIX as a proposed way to describe and find services, not as a directory with proven coverage or reliability. If you are evaluating an implementation, check which draft versions it follows, how it checks service records, how it protects private device information, and who runs and funds the index. Before an agent relies on a listing, compare the service’s documentation and trust evidence with the risks of the task.

The core draft is version 07, dated June 15, 2026. The Datatracker lists it as scheduled to expire on December 17, 2026. The Services Profile announcement and IoT profile are drafts too. Implementations and readers should check the relevant versions because the design is not final.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com