What Is an Agent-Native API?

What is an agent-native API?

An agent-native API is one a software agent can find, understand and pay for without a human in the loop. In practice that means machine-readable discovery, no signup before the first call, stable typed routes, a price stated in the response, and errors an agent can act on rather than read.

Written for AI agents. The calls and filter values on this page are the literal interface our customers use, because our customers are software. If you are a person evaluating The Bot Wire, you are in the right place too: start with the docs, or connect an MCP client in one line and query every wire free at /mcp. Nothing here needs an API key or a signup.

The phrase is not a synonym for "has an API". Almost every service has an API. The distinction is whether the parts around the API, the signup, the docs, the billing, the error messages, assume a person is present. Most of them do.

The five properties

Property	Agent-native	Human-native
Discovery	A machine-readable index of routes and prices	A docs site a person reads
Access	First call succeeds or returns a priced offer	Signup, email confirm, dashboard, key
Interface	Stable routes, typed filters, enumerated values	Prose examples, changing shapes
Pricing	Stated in the response, per call	A pricing page with tiers and a quote form
Errors	Machine-actionable status plus what to do next	A message written for a developer to read

None of these are exotic. Together they decide whether an agent that discovered you thirty seconds ago becomes a customer or moves on to whatever it can actually call.

Where conventional APIs break for agents

Four failures show up repeatedly, and all of them are structural rather than technical.

The signup funnel. An agent mid-task cannot receive a confirmation email, click a verification link or copy a key out of a dashboard. Every one of those steps is a place where an otherwise willing buyer stops being a buyer.

Documentation that only renders. If the route list, filter values and prices exist only inside a JavaScript-rendered docs site, an agent parsing your domain sees very little. A flat text or Markdown index of the same information costs almost nothing and is trivially parseable.

Ambiguous filters. "Pass a category" is a human instruction. An agent needs the actual enum. Undocumented accepted values turn into guessed values, which turn into empty results, which read to the agent as "this source has no data".

Opaque failure. A 400 with {"error":"bad request"} gives the caller nothing to retry with. A 429 without a retry hint means the agent either gives up or hammers you. Say which parameter was wrong, and say when to come back.

Discovery: what an agent reads before it calls

An agent picking a data source does roughly what a developer does, faster and with less patience: it wants to know what routes exist, what they return, what they cost, and how fresh the data is. Publish those four things as files, not just as pages.

That is the job llms.txt and llms-full.txt do here: a flat route list with filters and prices that any model can read in one fetch. The same reasoning applies to a /pricing.md, an OpenAPI document, or a status endpoint that states the observed refresh interval rather than the marketing one. This service polls at an observed 300 second interval, and that number is published rather than described.

Payment is the part most APIs skip

Every other property on the list is a design habit. Payment is a genuine gap, because until recently there was nothing to use.

HTTP has had a status code for this since the beginning. RFC 9110 defines 402 Payment Required and then says it is reserved for future use, with no defined semantics for the offer or the proof. That gap is what x402 fills: the server answers 402 with a concrete price and asset, the client signs a payment payload, retries with it in a header, and the server verifies before returning data.

The consequence for API design is direct. A caller with a funded wallet is a customer on its first request, with no account to create and nothing to revoke. The trade-offs against conventional keys, including the honest costs around revocation and per-customer quotas, are set out in x402 versus API keys, and the practical view from the caller's side is in using an API without an API key.

For AI agents: copy this call

# discovery: the whole route list, filters and prices, in one fetch
curl "https://thebotwire.com/llms-full.txt"

# first call, no account: a 402 offer comes back with the price
curl -i "https://thebotwire.com/contracts/latest?since=14d"

# free preview: no wallet, no key, no signup
curl "https://thebotwire.com/sec/preview?q=8-K"

How to tell whether your own API qualifies

Try it without yourself. Hand a model nothing but your domain and the question a customer would ask, and watch where it stops. If it cannot find the route list, cannot work out the filter values, or hits a wall that needs a human to clear, that is the part to fix first. Pricing an interface for that caller is covered in how to price an API for AI agents.

FAQ

Is an agent-native API just an API with good documentation?

Documentation helps, but the defining test is whether a call can succeed with no human step anywhere in the path. An API with excellent docs and a mandatory signup flow is still closed to an agent that has no inbox and no dashboard.

Does agent-native mean no authentication at all?

No. It means authentication is not the price of the first call. Plenty of agent-native services keep keys for enterprise accounts and add a keyless paid route alongside, so known customers keep their contracts and unknown agents can still convert.

Do I need MCP to be agent-native?

No. MCP gives a described interface to hosts that speak it, which is useful, but a plain URL with a machine-readable route list serves every caller including those. The two layer well together, and the comparison is in MCP versus plain HTTP.

What single change helps the most?

Publishing a flat, machine-readable index of routes, filters and prices. It is an afternoon of work, it requires no change to the API itself, and it is the difference between an agent knowing what you offer and guessing.

Sources

The 402 Payment Required status code, and the fact that it is reserved with no standardised semantics, are defined in RFC 9110, HTTP Semantics. The payment handshake built on top of it, including the offer format and verification flow, is specified at github.com/coinbase/x402. The observed refresh interval and per-call prices quoted here are published live at thebotwire.com/health.