For API consumers

Every listing on AirnodeHub is an API served through an Airnode, so every listing is consumed 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.

Finding an API

Humans browse the marketplace 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. An agent needs nothing but that file to find and use every API on the Hub.

Either way, a listing resolves to the URL of a deployed Airnode. The badge on a listing says who runs it. First-party means the original data source operates the Airnode itself, 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. 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 a person 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": "signedData", "parameters": {} }'

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": "0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266",
  "requestHash": "0x…",
  "timestamp": "1752580000",
  "data": { "0xbeaconId…": { "encodedValue": "0x…", "timestamp": "1752579990", "signature": "0x…" } },
  "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 the consumer's to do, so an Airnode is never asked to grade its own work.

Verification is what makes the responses composable. An answer an agent assembles from several listings can carry every underlying attestation along, so a consumer of 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. There are no accounts or API keys, just a wallet. A listing that prices nothing stays free to call. See payments for how this maps onto the endpoints.