Introduction

The phrase "Kafka API version" can mean more than one thing. Sometimes people mean the Kafka broker software version. Sometimes they mean the wire-protocol API versions a broker supports. Sometimes they actually mean the version of the client library in their application.

Those are related, but they are not the same. The fastest way to avoid confusion is to decide which one you need first.

If You Mean Broker API Support

The official Kafka CLI for this is kafka-broker-api-versions.sh:

bin/kafka-broker-api-versions.sh --bootstrap-server localhost:9092

This connects to the broker and prints supported API keys and version ranges. That is the most direct answer when you need to know what protocol-level features a broker can speak.

Typical output includes lines describing APIs and their min and max supported versions. That is what client compatibility tooling cares about more than a simple marketing version string.

If You Mean Broker Software Version

If you want the installed Kafka version itself, the broker logs are often enough. On startup Kafka logs a version line similar to:

Kafka version: 3.x.y

You can also inspect the local installation's CLI version:

bin/kafka-topics.sh --version

That tells you the version of the Kafka distribution installed on that machine. It is useful, but remember it reflects the local binaries, not necessarily the exact capabilities of every broker in a remote cluster.

Why the Broker API Versions Matter More for Compatibility

Kafka clients negotiate supported API versions with brokers. That means a newer client can often still talk to an older broker, as long as there is compatible overlap in the protocol versions for the APIs it uses.

So if the real question is:

• "Can this client talk to that cluster?"
• "Why is a feature unavailable?"
• "Which request version is being negotiated?"

then the broker API versions are the thing you want, not just 3.7.0 or 3.6.1.

Check the Client Library Version Separately

The Java client version is part of your application dependency tree, not part of the broker metadata. For Maven, for example:

mvn dependency:tree | grep kafka-clients

Or in Gradle:

./gradlew dependencies | grep kafka-clients

This matters because "Kafka version" questions are often really "which kafka-clients jar are we using?"

A Practical Troubleshooting Workflow

When compatibility issues appear, check these three things in order:

1. broker API support from kafka-broker-api-versions.sh
2. broker software version from logs or local CLI tools
3. client library version from your build or package manager

That gives you a much better diagnostic picture than asking for "the version" in the abstract.

When Clusters Have Mixed Brokers

During rolling upgrades, a cluster may temporarily contain brokers on different versions. In those cases, querying a single broker may not tell the whole story.

Run the API-version tool against the cluster bootstrap server and inspect the per-broker output carefully. Mixed-version windows are normal during upgrades and can explain surprising behavior.

What Not to Do

Do not assume the package version on one server proves the protocol capabilities of the whole cluster.

Do not assume a client library version tells you the broker version.

And do not rely only on startup logs when what you actually need is the negotiated protocol support. Logs and API support answer different questions.

Common Pitfalls

The biggest pitfall is using "Kafka version" to mean three different things in the same debugging conversation. That leads to wrong fixes quickly.

Another common mistake is checking only the local CLI version on an admin host and assuming it describes a remote managed cluster.

People also forget mixed-version upgrades. If one broker behaves differently during an upgrade window, the cluster may be temporarily heterogeneous.

Finally, when the real issue is client compatibility, the kafka-broker-api-versions.sh output is usually more useful than the raw broker version string.

Summary

• Decide whether you need broker API support, broker software version, or client library version.
• Use kafka-broker-api-versions.sh for supported protocol API versions.
• Use broker logs or kafka-topics.sh --version for local broker software version.
• Check your application dependencies separately for the client library version.
• Be careful during rolling upgrades, because brokers may temporarily report different versions.