> 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. # Create and configure a Kafka request This page describes the fields available when you create a Kafka request in Postman, and where each one comes from when a request is generated from an AsyncAPI specification. For the AsyncAPI mapping, see [Generate a Kafka collection from an AsyncAPI specification](/docs/design-apis/specifications/generate-kafka-collection-from-asyncapi/). ## Create a Kafka request To create a Kafka request, click the **+** icon in the sidebar and choose **Kafka** from the protocol picker. ## Broker connection | Field | Description | | -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Bootstrap URLs | One or more broker addresses (`host:port`). When generated from a spec, this is populated from every server in the AsyncAPI document whose protocol is `kafka` or `kafka-secure`. | | Secure connection | Whether the connection uses TLS. Set automatically to on when a spec server uses the `kafka-secure` protocol. Mutual TLS (mTLS) is configured here as a connection setting, not as an auth type. See the note under Authentication. | | Compression and strict SSL | Connection-level options with nothing to match in AsyncAPI, left at their defaults when a request is generated from a spec. | ## Authentication Kafka requests support the following authentication types: | Auth type | Notes | | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | No Auth | No credentials required. | | SASL | Mechanism options are PLAIN, SCRAM-SHA-256, and SCRAM-SHA-512, plus username and password with no mechanism set. Used for Confluent Cloud. The mechanism (when there is one) is set as a credential field. | | AWS Signature | For brokers that authenticate using AWS IAM, such as Amazon MSK. Fields: AccessKey, SecretKey, and (under Advanced configuration) AWS Region, Service Name, and Session Token. | | OAuth 2.0 | Standard OAuth 2.0 flows. | > **Info** > > When a Kafka request is generated from an AsyncAPI specification, Postman never copies credential values out of the spec. Auth type and structure (for example, which fields a SASL mechanism needs) are set from the spec, but the actual username, password, token, or certificate fields are always left empty for you to fill in. ### How AsyncAPI security schemes map to Kafka auth types | AsyncAPI `securityScheme.type()` | Kafka auth type | Notes | | --------------------------------------------------------------------- | ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | *(none)* | No Auth | | | `plain`, `scramSha256`, `scramSha512` | SASL | The SASL mechanism is set from the scheme, for example SCRAM-SHA-256. | | `gssapi`, `userPassword` | SASL | No SASL mechanism is set. | | `oauth2`, `openIdConnect` | OAuth 2.0 | Flows and scopes are read from the security scheme when present. | | `http` (bearer scheme) | Not mapped | No Kafka authentication type exists today and the generated request falls back to No Auth. Double-check auth after generating from a spec that uses this scheme. | | `X509` | Not an auth type | Maps to connection-level TLS (mTLS), not to one of the authentication types. | | `apiKey`, `httpApiKey`, `symmetricEncryption`, `asymmetricEncryption` | Not mapped | No Kafka-native match. The generated request falls back to No Auth for these. Double-check auth after generating from a spec that uses one of these scheme types. | > **Info** > > AWS Signature isn't derived from any AsyncAPI security scheme. It's only available when you configure a Kafka request's auth manually. ## Topic and mode Each Kafka request operates in one of two modes: | Field | Description | | ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Mode | Producer or consumer. When generated from a spec, this comes from the operation direction. For more information, see [Producer or consumer](/docs/design-apis/specifications/generate-kafka-collection-from-asyncapi/#producer-or-consumer) for exactly how this is derived, since AsyncAPI 2.x and 3.x use different (and, for 2.x, counterintuitive) verbs for this. | | Topic name | The topic a producer request sends to, or a consumer request subscribes to. | ## Producer fields | Field | Description | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Message value | The message payload. The content type is text, JSON, hex, or base64 (default JSON). When generated from a schema-backed spec, this is pre-filled with an example payload derived from the schema. | | Message key | The message key (partition key), if the spec defines one. | | Message headers | Key-value message headers. | > **Info** > > Partition, timestamp, and acknowledgment level aren't configurable on a producer message because they're not part of a producer message, and AsyncAPI has no source for them either. Consumer topics have partition-level fields. ## Consumer fields | Field | Description | | ---------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Topics | One or more topics to subscribe to. A leading `^` marks the value as a regex pattern rather than a literal topic name. | | Topic enabled state and description | Optional fields for a topic entry. | | Partitions, start offset, and end offset | Optional per-topic partition and offset bounds. AsyncAPI has no source for these, so they're never set when a request is generated from a spec. Configure them directly on the request if you need them. | | **Start From** | Where to start reading. Options are Earliest, Latest, Offset, and Timestamp. **Latest is the default.** | | **Stop After** | The bounded consume stop condition. | ### Bounded consume A live Kafka topic is an unbounded stream, so every consumer request runs as a *bounded consume*. You can pick a stop condition with the **Stop After** control. | **Stop After** option | Stops after | | --------------------------- | ------------------------------------------------------- | | **Records** (default: 1000) | A maximum number of messages is received. | | **Duration** | A maximum total duration elapses. | | **Idle** | No new message arrives for this long (an idle timeout). | | **Timestamp** | The consumer catches up to a specific timestamp. | Bounded consume means a Kafka consume step can be used inside a Runner sequence or a CI run. An unbounded stream never reaches a stop condition, so the run could never advance to the next step. > **Warning** > > The **Start From** and **Stop After** settings are never set from an AsyncAPI spec, even when a request is generated from one. Configure them after generating the request or when you create the request manually.