Integrations

An integration is a deployed Airnode over exactly one API. It is the unit that runs.

Airnode itself is a library, not a service. An integration supplies the OpenAPI document of the API being wrapped and starts a server with it. That is the whole of the contract, so an integration that needs no bespoke behaviour is a handful of lines and a document. They are built together, and a deployer decides which one to run.

This split is what keeps the bar low for providers. The machinery is written once and the thing that differs per API is a document the provider already has.

Integrations are meant to be many, so these docs describe what they share rather than any particular one. AirnodeHub is the list of them, and each listing's page carries the details of the API behind it, so a reader here only needs how an integration works in general.

Nodary

The worked example wraps the Nodary signed API, one of the official Api3 Signed APIs the push oracle uses to update the base feeds. It serves one operation, signedData, which returns every beacon Nodary currently signs, keyed by beacon ID.

A beacon ID is the hash of an Airnode address and a template ID: the address identifies the provider, the template ID identifies one endpoint of their API. Each value is an ABI encoded int256.

Two signatures, not one

Nodary is worth reading as the composability case rather than as a first-party wrap, because Nodary has already signed every beacon it serves. The response carries two signatures that say different things:

• Nodary's, inside each beacon, attests to producing the value.
• The Airnode's, over the whole response, attests to relaying that exact set at that exact time.

Both survive, which is signed data composing in practice: the aggregate unfolds back to the original source rather than asking a consumer to trust the last hop. The outer signature does not make this a first-party feed and does not claim to. Nodary's inner signature is the first-party attestation, and the Airnode's is provenance for the relay.

What the attestation means

An attestation says this Airnode obtained this response from this upstream at this time. Whether it means more than that depends on the API being wrapped, because not every upstream is a function. An API that answers the same request differently each time, a language model being the obvious case, leaves nothing to reproduce: the attestation is provenance and nothing else. Two Airnodes over such an upstream will never agree, so aggregating across them, which is exactly the right move for a price, means nothing there.

Status

The integrations that exist are built and deployed by Api3 and listed on AirnodeHub. An operation can be priced, in which case it is metered per call through x402 and settled in USDC; an operation with no price stays free. Pricing is opt-in per deployment, so an integration over a paid upstream charges only once the deployment supplies a payout address, and serves everything free until then.