Generate a Kafka collection from an AsyncAPI specification

You can generate a Kafka collection directly from an AsyncAPI specification in Spec Hub. Brokers, topics, authentication structure, and example message payloads are populated automatically from the spec. Postman doesn’t support Schema Registry yet. You’ll still need to provide credentials and configure bounded-consume settings.

The collections you generate are unidirectional and changes you make in the generated collection don’t write back to the spec.

To generate a collection, open your AsyncAPI specification in Spec Hub and click Generate Collection.

What gets generated

Each request in the generated collection is a Kafka request. The following table shows where each part of the generated collection comes from.

Generated field	AsyncAPI 3.x source	AsyncAPI 2.x source	Notes
Collection title	`document.info().title()`	same	You can override this with your own collection name.
Collection description	`document.info().description()`	same
Collection variables	`server.variables()` + `channel.parameters()`	same
Broker URLs	`server.host()` + `server.pathname()`, for servers where `server.protocol()` is `kafka` or `kafka-secure`	`server.url()`, same protocol filter	One broker entry per matching server. Generation fails if the spec has no Kafka server.
Secure connection	Set when `server.protocol()` is `kafka-secure`	same

Topics and requests

Generated field	AsyncAPI 3.x source	AsyncAPI 2.x source	Notes
Request node	One per operation in `document.operations()`, resolved to its channel	One per operation, found by iterating `document.channels()` then each channel’s `operations()`	A channel with both a send and a receive operation (3.x), or both `publish` and `subscribe` (2.x), generates two requests: one producer, one consumer.
Topic name	Channel’s `kafka` binding `topic`, falling back to `channel.address()`	Channel’s `kafka` binding `topic`, falling back to `channel.id()`
Request title	`operation.summary()`, `operation.operationId()`, or the channel address	`operation.summary()`, `operation.operationId()`, or the channel ID
Request description	`operation.description()` or `channel.description()`	same

Producer or consumer

AsyncAPI 2.x and 3.x describe direction with different verbs.

AsyncAPI 3.x uses send and receive from the application’s point of view: send means the generated request is a producer and receive means the generated request is a consumer.
AsyncAPI 2.x uses publish and subscribe from the application’s point of view: publish means the generated request is a producer and subscribe means the generated request is a consumer.

Messages

Generated field	Source	Notes
Message value	`message.payload()` schema, resolved to an example instance	Pre-filled example payload. Generated from a schema that you can edit before sending. Content is JSON by default; a message can also be generated as `text`, `hex`, or `base64` if that’s what the schema calls for.
Message key	The message’s `kafka` binding `key` schema	Omitted if the spec doesn’t define a key schema.
Message headers	`message.headers()` schema properties
Partition, timestamp, acknowledgment level	Not generated	These aren’t part of AsyncAPI’s producer message model, so they’re never generated. Per-topic partition and offset bounds are available on generated consumer requests instead. For more information, see Consumer fields.

Consumer settings

Generated field	Source	Notes
Subscribed topic	Resolved the same way as the producer topic name, earlier in this table
Start position	Not generated. Defaults to Latest.
Bounded consume (`stopAfter`)	Not generated	AsyncAPI has no concept of a bounded consume stop condition, so the generated consumer request leaves `stopAfter` unset. An unset `stopAfter` doesn’t mean unbounded: it falls back to the same 1,000-record default as a manually created request. Set your own bound after generating the request if you want something different. For more information, see Bounded consume.

Authentication

Generated auth comes from server.security(), or operation.security() when an operation overrides the server-level scheme. See How AsyncAPI security schemes map to Kafka auth types for the full mapping, noting that an AsyncAPI spec using the X509 security scheme doesn’t generate a Kafka auth type at all and maps to the connection’s TLS setting instead.

Postman never copies credential values out of your AsyncAPI spec. Even if a spec embeds them, credential fields on the generated request are always left empty. You’ll need to fill in your actual username, password, token, or certificate after generating the collection.

Schema

Generation itself doesn’t link a request to a schema. The one-click generator transforms the spec into a collection. It doesn’t know the id it will be given until after the collection is created and therefore can’t write a schema reference into the request at generation time.

Linking a topic or message to the spec itself is a manual step you can perform after generation, so Postman can validate it. You only need to pick the spec from the schema picker on the topic (for consume) or message (for produce). For more information, see Validate messages against a schema for that workflow and what validation actually checks today.