Making an API usable by AI agents
Most APIs are usable by agents in the same sense that a library is usable by someone who cannot read: everything is technically there, and none of it is reachable.
The gap is not capability. It is that conventional APIs assume a developer who found you, read your docs, signed up through a form, received a key by email, and wrote code. Every step in that chain assumes a person. Remove the person and the chain breaks at the first link.
Closing it takes three things, each of which an agent has to be able to complete alone.
1. It has to be able to find you
An agent will not read your landing page and will not guess your endpoints. Discovery works by convention: a manifest at a path fixed in advance, which anyone can request without being told it exists.
The important detail is not the format but the audience. Manifest formats increasingly separate the human-facing description from the model-facing one, and the second should be operational — what the service does concretely, and which endpoints serve which task. A model reading it is deciding whether it can accomplish something and in what order to call things, not whether it likes your positioning.
The manifest is an advertisement at a fixed address. The generated interface spec it points at is the actual contract.
Read next: How does an AI agent discover what your API can do? — well-known paths, the two-description split, why discovery must be unauthenticated but rate-limited, and where MCP is a different question from HTTP discovery.
2. It has to be able to pay you
Signup is the wall. An agent has no email to confirm, no card, no billing address — but it can have a wallet and sign with it unattended.
The 402 Payment Required status code, unused for thirty years, turns out to be the right primitive: answer an unpaid request with a machine-readable description of the payment you want, and let the caller retry with proof. No account, no key issued in advance, no human in the signup flow.
The engineering is mostly in replay protection and in failing closed — a payment authorisation is a bearer instrument, and an endpoint with no configured price should deny access rather than quietly give itself away.
Read next: How does an AI agent pay for an API call? — the two proof models, why a signature-based authorisation removes the agent's gas problem, and why nonce replay belongs in a unique index rather than a lookup.
3. It has to be able to authenticate as itself, safely
Per-call payment suits a caller with no history. An ongoing integration is a different relationship: signing a payment on every request is overhead, and the caller will happily be provisioned once.
That is what signed-request authentication is for, and the near-universal exchange convention — a key id, a secret, an HMAC over a canonical form of the request — is the right thing to copy. What varies between implementations, and what actually determines whether it is secure, is which bytes go into the signature, what else gets checked, and in what order.
Scoping matters more here than anywhere, because an autonomous caller holding an over-scoped key is a standing risk rather than an occasional one.
Read next: How do you authenticate a trading bot safely with API keys? — exactly what to sign, why the raw body must be the arrived bytes, the check order, and why generic failure messages are deliberate.
What this adds up to
The three together mean a caller that had never heard of you can find you, work out what you do, pay for a call, and get an answer — inside one session, with nobody involved.
That is a genuinely different distribution channel from search, and the comparison is stark. The human path is: search, read, evaluate, sign up, integrate, over weeks. The agent path is: fetch a manifest, call an endpoint, pay. Both are worth having. One of them currently has almost no competition, which is the entire argument for doing this work early rather than when it is obviously necessary.
Where teams get it wrong
Four failure patterns, in rough order of how often they appear.
Marketing copy in the model description. The most valuable few hundred characters you have, spent on positioning aimed at a reader who is not there.
Gating discovery. Requiring authentication before a caller can learn what you offer means it never reaches the point of paying you.
Hand-maintained interface specs. A human reading stale docs gets confused and asks a question. An agent reading a stale spec builds a call that fails and cannot tell that the spec was at fault. Generate it from the running service.
Errors that describe instead of instruct. 400 Bad Request with prose is a dead end. A 402 carrying the price, or a validation error naming the field and the constraint, is something a caller can act on without a human reading the message. For an autonomous caller, an actionable error is a feature of the interface, not a nicety.
BT365 exposes its trading surface to agents over x402, MCP and machine-readable discovery. Explore the platform or read the API documentation.