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.

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.

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.

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 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.

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.

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.