// the find
asyncapi/spec
The AsyncAPI specification allows you to create machine-readable definitions of your asynchronous APIs.
AsyncAPI is a specification for documenting event-driven and message-driven APIs — think OpenAPI but for Kafka, MQTT, WebSockets, AMQP, and similar protocols. It defines a standard YAML/JSON format for describing channels, operations, messages, and servers, enabling tooling to generate docs, code, and validation from a single source of truth. It's for backend teams building distributed systems who are tired of their async contracts living only in tribal knowledge.
The protocol coverage is genuinely broad — the same spec format works across Kafka, MQTT, AMQP, WebSockets, and more, which matters when you have a mixed-transport architecture. The toolchain around it is real and maintained: code generators, validators, Studio UI, and mock servers all exist in the asyncapi org. The v3 redesign cleaned up some v2 oddities around operations and channels, particularly the request/reply modeling which was awkward before. Corporate backing from IBM, Solace, and Kong means it's not going to be abandoned quietly.
The v2-to-v3 migration is a breaking change with non-trivial semantic differences — if you have existing v2 specs and tooling, expect a real porting effort, not a version bump. The spec itself is markdown-as-source-of-truth, which sounds fine until you want to programmatically derive something precise and discover the normative text has edge cases the JSON Schema doesn't fully capture. Tooling quality varies significantly across the ecosystem: the official generators are uneven, and some protocol bindings (STOMP, Mercure) have thin community support compared to Kafka and MQTT. The spec is also still oriented around describing a single service in isolation — cross-service contract testing and compatibility checks require reaching for external tools.