# Capabilities (/connectors/kafka/reference/capabilities)



This reference lists every Kafka API key the KubeMQ Kafka connector advertises, the version
range it accepts, and how complete that support is. **✅ Full** means "point a stock Kafka
client at KubeMQ; it works." **🟡 Partial** states the exact scope — read it before relying
on the capability. **🔵 Preview** means the wire protocol is implemented and advertised, but
the multi-client conformance matrix hasn't run yet — it is not a GA guarantee.

Every key's advertised `[min, max]` version window comes from one source table inside the
connector that both the `ApiVersions`(18) response and the per-request bounds check read, so
the two can never drift apart. A request whose version falls outside a key's window is
answered [`UNSUPPORTED_VERSION`](/connectors/kafka/reference/error-codes), encoded at
that key's max version, so the client renegotiates instead of decoding garbage.

## Produce, fetch, and metadata [#produce-fetch-and-metadata]

| Key | API                  | Versions | Status | Notes                                                                                                        |
| --- | -------------------- | -------- | ------ | ------------------------------------------------------------------------------------------------------------ |
| 0   | Produce              | 3–9      | ✅ Full | RecordBatch v2 only; `acks` 0/1/all; strict per-partition ordering                                           |
| 1   | Fetch                | 4–12     | ✅ Full | Long-poll (`fetch.max.wait.ms`); serves RecordBatch v2                                                       |
| 2   | ListOffsets          | 1–7      | ✅ Full | `earliest`/`latest`/by-timestamp; earliest tracks the live retention floor                                   |
| 3   | Metadata             | 0–13     | ✅ Full | v13 carries a deterministic `TopicID` (KIP-516); `Fetch` deliberately stays name-based (v12), not UUID-keyed |
| 23  | OffsetForLeaderEpoch | 0–4      | ✅ Full | Real KIP-320 leader-epoch fencing for log-truncation detection on consumer resume                            |

## Consumer groups (classic protocol) [#consumer-groups-classic-protocol]

| Key | API             | Versions | Status | Notes                                                   |
| --- | --------------- | -------- | ------ | ------------------------------------------------------- |
| 10  | FindCoordinator | 0–3      | ✅ Full | scalar SELF shape only                                  |
| 11  | JoinGroup       | 0–5      | ✅ Full | includes the static-membership `InstanceID` field (v5+) |
| 14  | SyncGroup       | 0–3      | ✅ Full |                                                         |
| 12  | Heartbeat       | 0–4      | ✅ Full |                                                         |
| 13  | LeaveGroup      | 0–4      | ✅ Full | single- and batch-member leave shapes                   |
| 15  | DescribeGroups  | 0–5      | ✅ Full | authz-gated; a denied group never leaks membership      |
| 16  | ListGroups      | 0–4      | ✅ Full |                                                         |
| 42  | DeleteGroups    | 0–2      | ✅ Full |                                                         |
| 8   | OffsetCommit    | 0–8      | ✅ Full | durable, per-group, leader-linearized                   |
| 9   | OffsetFetch     | 2–7      | ✅ Full |                                                         |
| 47  | OffsetDelete    | 0–0      | ✅ Full |                                                         |

<Callout type="info">
  **Static membership (KIP-345) is Full.** A consumer that sets `group.instance.id` joins as a
  static member: a static rejoin within the session timeout skips a rebalance entirely, and a
  *second* connection presenting the same `instance.id` — a displaced or duplicate instance —
  is fenced with [`FENCED_INSTANCE_ID`(82)](/connectors/kafka/reference/error-codes)
  across Join/Sync/Heartbeat/OffsetCommit/Leave.
</Callout>

There is no separate API key for KIP-848's next-generation consumer-group protocol — see
[Not supported](#not-supported).

## Handshake and authentication [#handshake-and-authentication]

| Key | API              | Versions | Status | Notes                                                                     |
| --- | ---------------- | -------- | ------ | ------------------------------------------------------------------------- |
| 18  | ApiVersions      | 0–3      | ✅ Full | A request above v3 is answered at v0 with `UNSUPPORTED_VERSION` (KIP-511) |
| 17  | SASLHandshake    | 0–1      | ✅ Full | negotiates PLAIN vs. the modern separate-authenticate flow                |
| 36  | SASLAuthenticate | 0–2      | ✅ Full | carries PLAIN, SCRAM-SHA-256/512, and OAUTHBEARER (TLS listener only)     |

## Admin [#admin]

| Key | API                     | Versions | Status     | Notes                                                                                               |
| --- | ----------------------- | -------- | ---------- | --------------------------------------------------------------------------------------------------- |
| 19  | CreateTopics            | 0–7      | ✅ Full     | auto-create on Metadata/Produce also applies                                                        |
| 20  | DeleteTopics            | 0–6      | ✅ Full     |                                                                                                     |
| 37  | CreatePartitions        | 0–3      | 🟡 Partial | increase-only — same-count, decrease, or over the 256-partition cap all reject `INVALID_PARTITIONS` |
| 21  | DeleteRecords           | 0–2      | 🟡 Partial | low-end log truncation only (advances the log start; never renumbers offsets)                       |
| 32  | DescribeConfigs         | 0–4      | ✅ Full     | leader-authoritative overlay read                                                                   |
| 44  | IncrementalAlterConfigs | 0–1      | 🟡 Partial | recognizes a subset of configs; several are accepted but no-op                                      |
| 60  | DescribeCluster         | 0–2      | ✅ Full     | self-as-broker-and-controller                                                                       |
| 75  | DescribeTopicPartitions | 0–0      | 🟡 Partial | optional API; tooling can safely fall back to `Metadata`                                            |

## Transactions and exactly-once semantics [#transactions-and-exactly-once-semantics]

| Key | API                | Versions | Status     | Notes                                                                |
| --- | ------------------ | -------- | ---------- | -------------------------------------------------------------------- |
| 22  | InitProducerId     | 0–4      | ✅ Full     | idempotent-producer PID allocation and KIP-360 epoch bump            |
| 24  | AddPartitionsToTxn | 0–3      | 🟡 Partial | V1 flat, non-batched wire shape only                                 |
| 25  | AddOffsetsToTxn    | 0–3      | 🟡 Partial |                                                                      |
| 26  | EndTxn             | 0–4      | 🟡 Partial | writes a real in-log COMMIT/ABORT marker; no per-`EndTxn` epoch bump |
| 28  | TxnOffsetCommit    | 0–3      | 🟡 Partial | single-group shape only                                              |

Transactions are exactly-once at the **V1** wire scope: `(PID, epoch)` fencing,
`read_committed` isolation, and staged-offset materialization on commit all work like real
Kafka's coordinator. **KIP-890 transaction protocol V2 is not shipped** — there is no
per-`EndTxn` epoch bump — and `WriteTxnMarkers`(27), the broker-internal marker RPC, is never
advertised to clients (see [Not supported](#not-supported)).

## Access control (ACLs) [#access-control-acls]

<Callout type="info">
  **ACL enforcement is Full**, independent of the three management keys below — every
  Produce/Fetch/group dispatch is authorization-gated at the first hop. The management keys
  only reflect configuration; they don't drive enforcement. **Write is coarse-grained,
  though** — a topic's Write permission authorizes both produce **and** destructive admin
  operations on that topic; there is no separate admin-only permission tier. This is a
  documented limitation, not a roadmap gap.
</Callout>

| Key | API          | Versions | Status     | Notes                                                                          |
| --- | ------------ | -------- | ---------- | ------------------------------------------------------------------------------ |
| 29  | DescribeACLs | 0–3      | 🟡 Partial | returns an honest empty view (or `SECURITY_DISABLED`) — no fabricated bindings |
| 30  | CreateACLs   | 0–3      | 🟡 Partial |                                                                                |
| 31  | DeleteACLs   | 0–3      | 🟡 Partial |                                                                                |

## Quotas and SCRAM credential admin [#quotas-and-scram-credential-admin]

| Key | API                          | Versions | Status     | Notes                                                                                                                |
| --- | ---------------------------- | -------- | ---------- | -------------------------------------------------------------------------------------------------------------------- |
| 48  | DescribeClientQuotas         | 0–1      | 🟡 Partial | per-principal produce/fetch token-bucket baseline; full multi-tenant quotas are a later continuation                 |
| 49  | AlterClientQuotas            | 0–1      | 🟡 Partial |                                                                                                                      |
| 50  | DescribeUserScramCredentials | 0–0      | 🟡 Partial | reflects configured users' mechanisms and iteration counts from server config (never salt or keys)                   |
| 51  | AlterUserScramCredentials    | 0–0      | 🟡 Partial | honestly rejects every mutation with `SECURITY_DISABLED` — SCRAM credentials are config-managed, not runtime-mutable |

## Share groups (KIP-932) — preview [#share-groups-kip-932--preview]

<Callout type="warn">
  **Preview, not GA.** Share groups are implemented and advertised — acquire,
  `Accept`/`Release`/`Reject` acknowledgements, multi-record batches, and follower-to-leader
  forwarding are all wired and validated against a real franz-go share consumer. The full
  multi-client share-group conformance matrix — the share-group analogue of the transactions
  exit gate — has not run yet. Never read this as "fully supported." See
  [Share Groups](/connectors/kafka/how-to/share-groups) for what to expect today.
</Callout>

| Key | API                       | Versions | Status     | Notes                                                                |
| --- | ------------------------- | -------- | ---------- | -------------------------------------------------------------------- |
| 76  | ShareGroupHeartbeat       | 0–1      | 🔵 Preview | join/leave for a share-group member                                  |
| 78  | ShareFetch                | 1–1      | 🔵 Preview | acquire; advertised atomically with 76/79 — a client needs all three |
| 79  | ShareAcknowledge          | 1–1      | 🔵 Preview | standalone acknowledge outside a ShareFetch round-trip               |
| 77  | ShareGroupDescribe        | 0–1      | 🔵 Preview | read-only member roster and group state                              |
| 90  | DescribeShareGroupOffsets | 0–1      | 🔵 Preview | read-only per-partition start offset and lag                         |
| 91  | AlterShareGroupOffsets    | 0–0      | 🔵 Preview | resets an **empty** group's start offset                             |
| 92  | DeleteShareGroupOffsets   | 0–0      | 🔵 Preview | resets an **empty** group's start offset to the log start            |

The data-plane trio (76/78/79) is advertised as a unit — a franz-go share consumer needs all
three to make any progress. `kcat`, `confluent-kafka`, `kafkajs`, `Confluent.Kafka`, and
`rdkafka` (Ruby and Rust) have no share-consumer API today; only &#x2A;*franz-go (Go)** and
Java's **preview** `KafkaShareConsumer` can drive this surface.

## Not supported [#not-supported]

* **KIP-848 next-generation consumer groups** (`ConsumerGroupHeartbeat`/`ConsumerGroupDescribe`,
  keys 68/69) — never advertised; classic groups (`group.protocol=classic`) are the only
  supported path. A client that requests `group.protocol=consumer` fails client-side before
  sending a single heartbeat — there is no server-side fallback.
* **KIP-714 client telemetry** (`GetTelemetrySubscriptions`, key 71) — never advertised;
  clients simply run without broker-side telemetry collection.
* **`WriteTxnMarkers`** (key 27) — broker-internal only; real Kafka clients never call it
  directly, and this connector never advertises it.
* **Schema Registry server** — the hosted REST API and its `_schemas`-backed storage aren't
  embedded. The wire-level magic-byte prefix passes through untouched, so Schema-Registry-aware
  *serializers* work unchanged. The real, **external** Confluent Schema Registry service does
  run against KubeMQ, though — its `_schemas` topic is just a compacted topic on the `next`
  engine like any other; only the embedded/hosted SR REST API isn't built in. See the
  [Fitness Matrix](/connectors/kafka/reference/fitness-matrix) for the proof tier.
* **ksqlDB** — a separate stream-processing runtime; out of scope as an embedded engine.
* **MirrorMaker 2** — cross-cluster mirroring isn't offered as a hosted tool; migration is
  start-fresh (see [Migrate from Kafka](/connectors/kafka/how-to/migrate-from-kafka)).
* **Kerberos / GSSAPI SASL** — no KDC integration; use SASL/SCRAM, SASL/PLAIN, OAUTHBEARER, or
  mTLS instead.
* **Delegation tokens** — `CreateDelegationToken`/`RenewDelegationToken`/`ExpireDelegationToken`/
  `DescribeDelegationToken` (keys 38–41) aren't implemented; any delegation-token request is
  answered [`DELEGATION_TOKEN_AUTH_DISABLED`(61)](/connectors/kafka/reference/error-codes) —
  switch those principals to SASL/SCRAM or mTLS instead.

## Related [#related]

<Cards>
  <Card title="Error Codes" href="/connectors/kafka/reference/error-codes" description="Every Kafka protocol error code the connector returns and what triggers it." />

  <Card title="Fitness Matrix" href="/connectors/kafka/reference/fitness-matrix" description="Per-workload drop-in / caveat / roadmap / unsupported verdicts, with proof tiers." />

  <Card title="Kafka settings reference" href="/configure/reference/connectors#kafka" description="Field-by-field Connectors.Kafka.* settings, ports, and TLS/SASL options." />

  <Card title="Share Groups" href="/connectors/kafka/how-to/share-groups" description="Queue-style consumption with KIP-932 share groups, in preview." />
</Cards>