For API consumers

Every listing on AirnodeHub is an API served through an Airnode, so you consume them all the same way: find it, read its self-description, call it, and verify what came back. Each step is machine-readable, so the consumer can be an agent as easily as a person.

If your agent speaks MCP, every one of those steps is served as a tool at one endpoint, so it can do them without you wiring up any of this by hand.

Finding an API

Say what you need in plain English and the Hub answers with the calls that could serve it, each with its parameters, an example filled in, its price and who will have attested to the answer before anything is spent. A model reads the listing registry to choose, so it understands a request phrased in words no listing uses, and every candidate it returns is checked back against the registry before you see it: the parameter contract, the price and the address come from the API's own document rather than from the model. If it cannot be reached you get a 503 rather than a guess, since a candidate carries an address and a price and nothing that never read your intent should arrive wearing them. Send it again in a moment.

Ask for "yesterday" or "the last three hours" and the dates come back filled in, worked out from the current time in UTC and from the timezone your request appears to come from. Near midnight, or when your agent runs a long way from you, name the date in the intent rather than leaving it to be inferred.

This is an endpoint as much as a page, and it is free to call:

curl -X POST https://airnodehub.api3.org/resolve \
  -H 'Content-Type: application/json' \
  -d '{ "intent": "current USD price of ETH" }'

Free, but rate limited per caller, since every resolve costs us inference to serve. Over the limit you get a 429 rather than an answer. Reading the listings costs nothing, so search-listings and get-listing-details over MCP are not limited, and an agent that searches rather than resolving repeatedly never meets the limit.

We record the intents the Hub resolves and the answer each one got: the operations offered, the parameters filled in for them, and anything it could not resolve. An intent nothing on the Hub can serve is the most useful thing you can tell us, since it names an API worth listing, and it is why we keep it rather than answering and forgetting it. When nothing matches, the Hub says so and points you at Discord, where you can ask for help or name the API you came for.

Alongside it we keep your IP address, roughly where that is, the network the request came over, what software made the call and Cloudflare's reading of whether the caller is a bot. We use it to keep the endpoint available to everyone, to apply the rate limit, and to understand how the Hub is being used.

You can also browse the catalogue and search the listings. Agents read /llms.txt, which the site serves generated from the same listing registry: a one-line summary of the marketplace, how to call a listing, and one link per listing with its description. /llms-full.txt is the same registry with every operation, its parameters and its price written out, for an agent that would rather read one file than follow the links. Either is enough to find and use every API on the Hub.

Either way, a listing resolves to the URL of a deployed Airnode, and the badge on it says who runs that Airnode. First-party means the original data source operates it, so the attestation reaches all the way back to the producer. Third-party means someone runs it over a source they do not own, and the attestation is provenance for the relay rather than for producing the data. Read the badge before you decide what a signature buys you. Integrations covers what a listing is made of, and AirnodeHub is where the details of each one live.

Reading what it serves

A GET of the listing URL returns the Airnode's own OpenAPI document: the operations it serves, the parameters each one takes, and under x-airnode the address to verify responses against.

curl https://airnode-nodary.fly.dev/

A listing's page on the Hub renders a saved copy of this same document for a person. The Airnode's own answer is the authority: an agent should read the listing URL directly, and you can too when it matters.

The HTTP interface covers what is in the document and what is deliberately left out of it.

Calling an operation

A POST to the same URL names an operation and its parameters:

curl -X POST https://airnode-nodary.fly.dev/ \
  -H 'Content-Type: application/json' \
  -d '{ "operation": "latestFeeds", "parameters": { "name": "ETH/USD" } }'

The response is the upstream data plus the attestation over it. data carries the upstream body as JSON when the upstream answered JSON, and as text otherwise:

{
  "airnode": "0xE70f1e8b22a21e4Bb5188918a3033341b281E4c0",
  "requestHash": "0x…",
  "timestamp": "1752580000",
  "data": { "ETH/USD": { "value": 1877.62, "timestamp": 1752579990000, "category": "crypto" } },
  "signature": "0x…"
}

An unknown operation is a 404, a missing, unknown or mistyped parameter is a 400, and an upstream failure is a 502.

A listing's page on the Hub can send these requests from the browser: pick an operation, fill its parameters, perform it, and hand the response straight to verification on the page.

Verifying the response

Check that the signature is the listed address signing over exactly this request, this time and these bytes. Attestation documents the algorithm and a client side implementation, and a listing's page on the Hub runs the same check in the browser. There is deliberately no verify endpoint to call: verification is yours to do, so an Airnode is never asked to grade its own work.

Verification is what makes the responses composable. An answer your agent assembles from several listings can carry every underlying attestation along, so whoever consumes the aggregate can verify each original source rather than trusting the last hop. Attested data covers why that works.

Paying

Discovery is always free, and a listing may price the operations it serves with x402: performing one becomes the paid resource, settled per request in USDC without a human in the loop. A priced operation answers an unpaid call with 402 and a set of payment requirements. The caller signs an authorization to pay and retries it in a header, which is a step an agent takes on its own. You need no account and no API key, just a wallet. A listing that prices nothing stays free to call. See payments for how this maps onto the endpoints.

Today nothing is priced. Every listing on the Hub is free to call while AirnodeHub is in early access, which is where we are rather than a promise about where we are going. Read the price out of the listing's own document rather than assuming it, and your agent keeps working on the day one of them starts charging.