AsyncAPI

A specification, and a set of open-source tools, for describing event-driven APIs in one YAML or JSON document: the brokers an application connects to, the channels it sends to or receives from, and the messages on them.

Linux Foundation project

What it is: Pub/sub
Used for: Web APIs
Type: Open source
Made by: AsyncAPI Initiative (Linux Foundation), started by Fran Méndez
Foundation: The Linux Foundation, joined March 2021. A series of LF Projects, LLC
License: Apache 2.0
Facts checked: 28 October 2026

What it is

AsyncAPI does for message-driven systems what OpenAPI does for HTTP APIs. An AsyncAPI document describes one application: servers gives the brokers it connects to and their protocol, channels lists the topics or queues it uses (each with an address and the messages that may appear on it), and operations says what the application does on each channel, with an action of send or receive. Payloads are described with AsyncAPI’s Schema Object, a superset of JSON Schema Draft 07, or in another format such as Avro or Protocol Buffers, which tools are recommended but not required to support, and shared schemas, messages and security schemes live under components. The current version, 3.1.0, came out on January 31, 2026.

The same format covers many transports. Bindings add protocol-specific details, such as a Kafka topic’s partitions or the QoS level of an MQTT publish, to servers, channels, operations and messages; the specification defines binding keys for 20 protocols, including Kafka, MQTT, AMQP, NATS, Pulsar, Google Pub/Sub, Amazon SNS and SQS, WebSockets and ROS 2. The initiative also maintains the tools that read the format: the AsyncAPI CLI, which validates documents and generates docs or code from templates, Studio for editing documents visually, Modelina for generating payload models in languages such as Java, TypeScript and Go, and parsers for JavaScript and Go.

Why teams pick it

One machine-readable contract for an event-driven service, from which docs, payload models and code are generated, the way OpenAPI works for HTTP
Protocol-neutral: the same structure describes Kafka, MQTT, AMQP, NATS, WebSocket and other APIs, with bindings for each protocol’s own settings
Payload schemas are a superset of JSON Schema, and a message may instead point to an OpenAPI, Avro, RAML or Protocol Buffers schema, so existing payload definitions can be reused
Vendor-neutral under the Linux Foundation, with the specification and core tools under Apache 2.0 and no contributor licence agreement for the tools

Watch out for

Version 3.0 changed the core structure: publish and subscribe became operations with send or receive, and channel keys became IDs with a separate address, so 2.x documents and tools need converting
It describes what an application sends and receives, not how messages flow across a whole system; tracing producers to consumers means relating many documents
Binding support varies by protocol and tool: a binding defined in the specification may be ignored by the generator template or docs renderer you use
A hand-written document drifts from the code unless it is generated from the code or checked in CI

Alternatives

What all pub/sub have in common →Compare side by side →

OpenAPI SpecificationOpen sourceA standard, language-neutral way to describe an HTTP API in one JSON or YAML document, from which tools generate docs, client SDKs, server stubs, tests, gateway configs and AI tools.

Protocol BuffersOpen sourceGoogle’s schema-first binary encoding: messages defined in .proto files, fields identified by number, code generated for each language.

Amazon SNSAWSAWS’s managed pub/sub topics, which push each message to queues, functions, webhooks, phones and inboxes.

Google Cloud Pub/SubGoogle CloudGoogle Cloud’s serverless messaging service: fan-out across subscriptions, work sharing within each one.

ZeroMQOpen sourceA messaging library, not a server: you link it into each program, and its sockets carry whole messages between processes in patterns such as pub-sub, push-pull and request-reply, with no broker in between.

How it fits with other technologies

What AsyncAPI uses

An AsyncAPI 3.1 document for a service that publishes order events to Kafka · yaml

asyncapi: 3.1.0
info:
  title: Orders service
  version: 1.0.0
servers:
  production:
    host: kafka.example.com:9092
    protocol: kafka
channels:
  orderCreated:
    address: orders.created          # the Kafka topic
    messages:
      orderCreated:
        $ref: '#/components/messages/OrderCreated'
    bindings:
      kafka:
        partitions: 12
operations:
  sendOrderCreated:
    action: send                     # what this application does
    channel:
      $ref: '#/channels/orderCreated'
components:
  messages:
    OrderCreated:
      contentType: application/json
      payload:
        type: object
        required: [orderId, totalCents]
        properties:
          orderId: { type: string }
          totalCents: { type: integer, minimum: 0 }

What changed between 2.x and 3.0#

Version 3.0.0, released on December 5, 2023, is the one major break so far; 3.1.0 only added ROS 2 bindings.

	2.x	3.x
Operations	`publish` and `subscribe` nested inside each channel	A separate `operations` section, each with `action: send` or `action: receive` and a reference to a channel
Point of view	`publish` meant others could publish to the channel because your application subscribed to it	The document describes what your own application does, so `send` means it sends
Channels	The channel’s key was also its address, and a channel could not be reused	The key is an arbitrary ID, the address is a separate field, and channels can be reused across documents
Servers	One `url` field	Separate `host`, `pathname` and `protocol` fields

See it in a real stack

No architecture uses AsyncAPI yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from2016–2026

OpenAPI gave HTTP APIs a shared description format, but systems built on message brokers had nothing similar: teams documented Kafka topics, MQTT topics and AMQP queues by hand. Fran Méndez created AsyncAPI in 2016 to describe such message-driven APIs; it started as an adaptation of the OpenAPI specification, kept as compatible with it as possible so users could reuse parts in both. Version 2.0.0 came out on September 11, 2019.

As adoption grew the project needed a neutral home. On March 30, 2021 the Linux Foundation announced it would host the AsyncAPI Initiative, with Ably, Apideck, Bump, IQVIA, MuleSoft, Slack, Solace and TIBCO as founding sponsors; the release named Adidas, PayPal, Salesforce, SAP and Slack as production users and said production use had tripled from 2019 to 2020. The charter limits how many representatives one company may have on the Technical Steering Committee.

Version 3.0.0, released on December 5, 2023, rebuilt the core around separate operations with a send or receive action, ending a long-standing confusion over what publish and subscribe meant. Version 3.1.0 followed on January 31, 2026 with bindings for ROS 2, the robotics middleware.

Why it’s built this way

Start from OpenAPI: AsyncAPI began as an adaptation of OpenAPI and aimed to stay as compatible with it as possible, so users could reuse parts, such as payload schemas, in both.
Protocol bindings instead of one protocol: Event-driven systems run on many brokers, so the core describes channels and messages generically and bindings carry each protocol’s own settings.
Describe the application’s own actions in 3.0: In 2.x, publish described what other applications could do, which readers kept misreading; send and receive describe the application itself.

Timeline

2016
Fran Méndez starts AsyncAPI; the specification repository is created in November
2019
AsyncAPI 2.0.0 released on September 11
2021
The Linux Foundation announces it will host AsyncAPI, on March 30
2023
AsyncAPI 3.0.0 released on December 5, with operations and send/receive
2026
AsyncAPI 3.1.0 released on January 31, adding ROS 2 bindings

Sources7 · facts checked 28 October 2026

Improve this page on GitHub