Skip to content

Self-maintaining AsyncAPI: keep your API declaration and implementation in sync

From source code: AsyncAPI generated from Spring Messaging code, with drift flagged in the IDE

From brokers and queues: Kurkik compares live Kafka, Pulsar, SNS and SQS with your document (coming soon)

The contract: JSON Schemas that let editors, CI and AI agents validate every change

The foundation: free bindings and schemas docs, plus open-source JAsyncAPI

AsyncAPI drift, caught from both sides

An AsyncAPI document is a promise. Code changes, topics get added, queues get reconfigured, and the promise quietly stops being true. These tools compare the declaration with what actually runs, and keep it correct.

From source code

The JetBrains plugin

Generates the AsyncAPI document from your Spring Messaging code and flags listener mistakes in the editor. When the code changes, the document is regenerated and the difference is yours to review, not something to remember.

See the plugin →
The contract

One AsyncAPI document

The single place that says what your system does. Validated against the AsyncAPI JSON Schemas by editors, CI pipelines and AI agents, so every automated change to it stays valid.

Use the schema registry →
From brokers and queues

Kurkik Coming soon

Reads the live Kafka, Pulsar, SNS or SQS system, shows where it differs from the document, and applies fixes only as a plan you approve.

Read about Kurkik →

This is the direction I've been building toward for years: self-maintaining APIs, where the declaration and the implementation stay in step and an agent can propose the fix. The free bindings and schemas documentation, the schema registry and the JAsyncAPI library are the foundation under it.

Built by an AsyncAPI maintainer

I'm Pavel Bodiachevskii, a member of the AsyncAPI Technical Steering Committee and a maintainer in the AsyncAPI ecosystem. I have spent years on one problem: keeping AsyncAPI declarations and the systems they describe from drifting apart. The tools here come from daily work with the specification, brokers and real event-driven systems, and are used by teams like the ones listed below.

GitHubBlogJetBrains MarketplaceSupport my work

Tools for every step of AsyncAPI work

Write, validate, document and generate AsyncAPI for Kafka, AMQP, MQTT, SNS, SQS and more, in the IDE you already use.

IDE & editors

AsyncAPI plugin for JetBrains IDEs

Free + Pro

Keep AsyncAPI in step with your Spring code, inside IntelliJ IDEA, WebStorm, PyCharm and Android Studio

Generate AsyncAPI documentation straight from your Spring Messaging code and catch drift between the document and the implementation as you work. Also a complete AsyncAPI editor: validate while you type and preview the result.

  • Live validation, completion and quick fixes for AsyncAPI 2.x and 3.x
  • Instant preview, templates and resolution of references across files
  • Spectral and Redocly linting without leaving the editor
  • Generate AsyncAPI documents from Spring Messaging code: Kafka, JMS, Amazon SNS and SQS, Pulsar, STOMP, SSE
  • Inspect a single server, channel, message or operation in isolation

AsyncAPI Language Server

In development

AsyncAPI support for VS Code, Zed and Sublime Text

Bring diagnostics, completion and hover documentation for AsyncAPI documents to your favourite editor, not only to JetBrains IDEs.

  • Errors and warnings highlighted as you type
  • Context-aware completion
  • Quick documentation on hover
  • Planned: VS Code, Zed and Sublime Text

Code & automation

Kurkik

Coming soon

Catch drift between your AsyncAPI document and the brokers and queues that actually run

Point it at an existing messaging system and get an up-to-date AsyncAPI 3.0 document. Compare the document with reality to spot drift, and apply fixes only after you review them.

  • Document an existing Apache Kafka, Apache Pulsar, Amazon SNS or Amazon SQS estate
  • Detect drift between your AsyncAPI document and the live system
  • Apply changes as a reviewed plan, with the risky ones kept out of the default approval
  • Says plainly what it could not read, instead of guessing

JAsyncAPI

Free & open source

Read, create and write AsyncAPI documents from Java and Kotlin

A free, open-source JVM library with models for AsyncAPI 2.x and 3.x, all protocol bindings and all security schemes. Used by Springwolf, the Quarkus AsyncAPI extension and Specmatic.

  • AsyncAPI 2.0.0, 2.6.0 and 3.0.0
  • 19 protocol bindings, from Kafka and AMQP to MQTT, NATS, SNS and SQS
  • All security scheme types
  • Apache-2.0 on Maven Central: com.asyncapi:asyncapi-core

Reference

AsyncAPI Bindings documentation

Free

Kafka, AMQP, MQTT, SNS, SQS and 15 more brokers, with examples

Plain-language reference for every AsyncAPI protocol binding: what each field does, working examples and the gotchas worth knowing before you write the document.

  • 20 brokers, all binding versions
  • Channel, message, operation and server bindings
  • Copy-paste examples

AsyncAPI Schemas documentation

Free

Understand AsyncAPI data, security and multi-format schemas, with examples

Documentation for the AsyncAPI Schema Object, security schemes and multi-format schemas (Avro, JSON Schema, XML and more): how to use them in AsyncAPI documents and while generating them.

  • Schema and multi-format schema objects
  • HTTP, OAuth 2.0 and SASL security schemes
  • Examples and hints for real documents

AsyncAPI JSON Schema Registry

Free

Machine-readable schemas to validate and autocomplete AsyncAPI, for tools and AI agents

Point your editor, CI pipeline or AI agent at a schema URL to validate AsyncAPI documents, bindings and security schemes, get autocompletion, and understand the structure of the specification.

  • AsyncAPI 3.0 and 3.1 documents, 603 draft-07 schemas
  • Bindings for 20 brokers, per version
  • Works in JetBrains IDEs, VS Code, check-jsonschema and agents
  • Nightly channel with refactored, improved schemas

What do you want to do with AsyncAPI?

Document brokers and queues

Describe Apache Kafka, AMQP, MQTT, Amazon SNS and SQS, NATS and 15 more brokers correctly the first time with examples for every binding.

Browse bindings →

Get docs from Spring Messaging code

Generate AsyncAPI from your Spring listeners and templates, so the documentation follows the source instead of drifting from it.

Spring support →

Write and validate AsyncAPI

Edit with completion, live validation, Spectral or Redocly linting and JSON Schemas, in or outside a JetBrains IDE.

Use the schema registry →

Validate and generate with AI agents

Give agents and LLMs the exact JSON Schema for your AsyncAPI version and bindings, so what they generate is valid.

How agents use it →

Split large documents

Decompose a big document into files with references, and preview one server, channel, message or operation at a time.

Typed components →

Trusted by

Frequently asked questions

What is a self-maintaining API, and what is AsyncAPI drift?

Drift is when an AsyncAPI document no longer matches the system it describes: the code sends different messages, or topics and queues were changed on the broker. A self-maintaining API detects that mismatch and brings the declaration and the implementation back in step. These tools do it from both sides: the JetBrains plugin from your source code, and Kurkik (coming soon) from live brokers and queues.

How do I detect drift between AsyncAPI and my code or my broker?

From code, the JetBrains plugin regenerates the AsyncAPI document from Spring Messaging code so you can review what changed. From the broker side, Kurkik, announced and coming soon, compares the document with a live Kafka, Pulsar, SNS or SQS system and reports what matches, changed, is missing or is extra. Validate the result against the schema registry in CI.

How do I document Spring Kafka, JMS, SNS or SQS listeners as AsyncAPI?

The AsyncAPI plugin for JetBrains IDEs can generate an AsyncAPI document from your Spring Messaging code, so the documentation comes from the source instead of being written twice. Kafka, JMS, Amazon SNS and SQS, Pulsar, STOMP and SSE are covered.

Where can I find AsyncAPI binding examples for Kafka, AMQP, MQTT and other brokers?

The bindings documentation on this site covers 20 brokers with every binding version, field explanations and working examples.

How do I validate an AsyncAPI document?

Validate in the editor with the JetBrains plugin, lint with Spectral or Redocly, or validate against the AsyncAPI JSON Schemas from the schema registry at schemas.asyncapi.pavelon.dev, for example with check-jsonschema in CI.

Where can I get JSON Schemas for AsyncAPI documents and bindings?

The AsyncAPI JSON Schema Registry at schemas.asyncapi.pavelon.dev serves schemas for AsyncAPI 3.0 and 3.1 documents, 20 broker bindings and security schemes. Use the URL in your editor, in CI, or give it to an AI agent.

How can an AI agent or LLM validate or generate AsyncAPI correctly?

Give the agent the schema URL for your AsyncAPI version and binding. It can read the structure from the schema, generate a document or a single binding, then validate the result against the same schema and fix the reported errors.

How do I split a large AsyncAPI document into smaller files?

Use references between files. The JetBrains plugin resolves them, validates the result and lets you preview a single server, channel, message or operation on its own.

Can I write AsyncAPI without a JetBrains IDE?

Yes. The schema registry works in any editor or CI pipeline, and the AsyncAPI Language Server for VS Code, Zed and Sublime Text is in development.

Is there a free way to use these tools?

Yes. The plugin has a free core, JAsyncAPI is open source under Apache-2.0, and the bindings and schemas documentation is free. If you enjoy the free tools, you can support the work through GitHub Sponsors.

How do I keep AsyncAPI documentation in sync with a running Kafka, Pulsar, SNS or SQS system?

Kurkik, announced and coming soon, documents an existing system as AsyncAPI 3.0, reports drift and applies changes only after review.

Using my tools?

Let me know how you are using them and what you think! I appreciate your feedback.

Let me know