AsyncAPI
How it works
An AsyncAPI specification is a YAML or JSON file describing a few key sections: info (API metadata), servers (message brokers), channels (topics, queues or other exchange points), operations (send/receive actions), messages (payload definitions) and components (reusable schemas, security, parameters). In 3.0 operations are first-class citizens decoupled from channels, which makes complex flows easier to express and lets channels be reused across operations. Tooling consumes the spec to generate HTML documentation, clients and servers in languages such as Java, TypeScript, Go and Python, plus payload validators used at runtime and in contract tests.
Problem solved
Before AsyncAPI there was no accepted standard for describing asynchronous APIs. OpenAPI covers the REST world but does not fit messaging and event streams. Without a shared contract, event-driven integrations were ad-hoc, documentation drifted from the code and generating clients and servers was effectively impossible. AsyncAPI provides a machine-readable contract that closes these gaps and lets event-driven systems be treated on par with synchronous APIs.
Components
A single YAML or JSON file containing the complete event-driven API specification.
Logical message exchange points — topics in Kafka, queues in AMQP, paths in WebSocket.
Send and receive actions describing what the application does with a channel. Decoupled from channels in 3.0.
Event payload definitions with schema (JSON Schema, Avro, Protobuf), headers and examples.
Protocol-specific configuration — e.g. partition key for Kafka, exchange type for AMQP, QoS for MQTT.
Official
Implementation
AsyncAPI 3.0 introduces fundamental structural changes (operations decoupled from channels), so 2.x documents are not directly compatible with 3.x tooling.
Without automated validation the specification quickly drifts from the actual payloads emitted by producers.
Bindings (e.g. for Kafka or AMQP) are often filled in partially or incorrectly, leading to misgenerated clients and servers.
Evolution
Fran Méndez publishes the first version of the spec as open source — the messaging counterpart of OpenAPI.
The project moves under the Linux Foundation, gaining neutral governance and accelerated adoption.
Significant structural changes to the spec and an expanded bindings system for various protocols.
Operations become first-class entities decoupled from channels, enabling richer flow descriptions.
AsyncAPI becomes a standard for describing events in LLM agents and multi-agent AI pipelines.
Hyperparameters (configurable axes)
Choice of transport protocol: Kafka, AMQP, MQTT, WebSockets, NATS, JMS, STOMP, Redis, IBM MQ.
AsyncAPI version: 2.x vs 3.x. In 3.x operations are decoupled from channels, changing document structure.
Payload schema format: JSON Schema, Avro or Protobuf.
Hardware requirements
AsyncAPI is a specification (a YAML/JSON contract), not a runtime — it does not execute computation and is not tied to specific hardware.