> This page is for Postman Docs, version Latest (v12) (default). > For other versions, use one of these documentation indexes: > - Latest (v12) (default): https://learning.postman.com/latest-v-12/llms.txt > - v11: https://learning.postman.com/v11/llms.txt > For clean Markdown content of this page, append .md to this URL. For the complete documentation index, see https://learning.postman.com/llms.txt. # 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](/docs/use/send-requests/protocols/kafka/kafka-request-interface/). 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](/docs/use/send-requests/protocols/kafka/kafka-request-interface/#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](/docs/use/send-requests/protocols/kafka/kafka-request-interface/#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](/docs/use/send-requests/protocols/kafka/kafka-request-interface/#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. > **Warning** > > 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](/docs/use/send-requests/protocols/kafka/kafka-schema-registry/) for that workflow and what validation actually checks today.