Client Deprecation in Confluent Cloud

The Apache Kafka® 3.7 distribution released in Q1, 2024 included KIP-896. KIP-896 is the proposal to remove support for older client protocol API versions in Kafka 4.0. The 3.7 release marked these older, client protocol API versions deprecated with a notice that they will be completely dropped by 4.0. This page discusses the changes in Confluent client behavior resulting from KIP-896.

Confluent provides one year of extended compatibility for customers’ Confluent Cloud clusters. Starting February 2026, deprecated client requests will no longer be accepted and will result in errors.

Minimal compatible baseline

With the release of Kafka 4.0 in 2025, Confluent sets the new baseline for client protocol API versions to Kafka 2.1.0, which was released in November 2018. As a result, clients connecting to new clusters must use compatible API versions.

The following chart describes the minimal compatible versions of some popular client libraries:

Client

Version

Released

Java client for Kafka

2.1.0

November 2018

Python (confluent-kafka-python)

1.8.2

October 2021

.NET (confluent-kafka-dotnet)

1.8.2

October 2021

Go (confluent-kafka-go)

1.8.2

October 2021

C/C++ (librdkafka)

1.8.2

October 2021

KafkaJS

1.15.0

November 2020

Sarama

1.29.1

June 2021

kafka-python

2.0.2

Sep 2020

Any librdkafka-based protocols not listed in the preceding table have a version minimum of 1.8.2 as specified in the October 2021 release of Apache Kafka®.

List of deprecated Kafka APIs

API

Deprecated version

Produce

V0-V2

Fetch

V0-V3

ListOffset

V0

Metadata

None

OffsetCommit

V0-V1

OffsetFetch

V0

FindCoordinator

None

Heartbeat

V0-V1

LeaveGroup

None

SyncGroup

None

DescribeGroups

None

ListGroups

None

SaslHandshake

None

ApiVersions

None

CreateTopics

V0-V1

DeleteTopics

V0

DeleteRecords

None

InitProducerId

None

OffsetForLeaderEpoch

V0-V1

AddPartitionsToTxn

None

AddOffsetsToTxn

None

EndTxn

None

WriteTxnMarkers

None

TxnOffsetCommit

None

DescribeAcls

V0

CreateAcls

V0

DeleteAcls

V0

DescribeConfigs

V0

AlterConfigs

None

AlterReplicaLogDirs

V0

DescribeLogDirs

V0

SaslAuthenticate

None

CreatePartitions

None

CreateDelegationToken

V0

RenewDelegationToken

V0

ExpireDelegationToken

V0

DescribeDelegationToken:

V0

DeleteGroups

None

How to identify deprecated client requests

You can monitor deprecated client requests from the Confluent Cloud Console on the Clients overview page. You can filter clients by producers or consumers. You can also use this page to identify clients with deprecated requests. The Client Version column marks deprecated clients and their associated client version with a warning icon. Display a tooltip by hovering the mouse over the marker:

../_images/deprecated-cloud-1.png

Click on the tool tip to get more information:

../_images/deprecated-cloud-2.png

Users with the MetricsViewer role can query the io.confluent.kafka.server/deprecated_request_count metric in the Confluent Cloud Metrics API to identify clients sending deprecated requests. The query returns the client’s ID, the principal using that client, and the request type the client is using.

Note

Because Confluent Cloud identifies clients by principal and client ID, if your installation has multiple clients using the same principal and client ID, the Confluent Cloud Console may incorrectly report that all of them have deprecated requests. In this scenario, you must manually inspect each client to identify the one requiring an update.

The following example illustrates how to use the Metrics API to query for a deprecated client:

  1. Create a JSON file named deprecated_requests_query.json using the following template:

    {
     "group_by": [
         "metric.client_id",
         "metric.principal_id",
         "metric.type",
         "resource.kafka.id"
     ],
     "aggregations": [
         {
         "metric": "io.confluent.kafka.server/deprecated_request_count",
         "agg": "SUM"
         }
     ],
     "filter": {
         "op": "AND",
         "filters": [
         {
             "field": "resource.kafka.id",
             "op": "EQ",
             "value": "CLUSTER_ID"
         }
         ]
     },
     "granularity": "ALL",
     "intervals": ["TIMESTAMP"]
 }

  2. Change lkc-CLUSTER_ID and the MY_TIMESTAMP values to match your environment, for example, lck-abcd0 for the CLUSTER_ID and 2025-04-11T00:00:00.000Z/PT10M for the TIMESTAMP.

  3. Save the JSON file.

  4. Submit the JSON query as a POST.

    In the example below, change <API_KEY> and <SECRET> to match your environments:

    http 'https://api.telemetry.confluent.cloud/v2/metrics/cloud/query' --auth '<API_KEY>:<SECRET>' < deprecated_requests_query.json

    Successful output will resemble the following:

    {
    "data": [
        {
        "timestamp": "2025-04-11T00:00:00Z",
        "value": 1026.0,
        "resource.kafka.id": "lkc-xxxxx",
        "metric.principal_id": "u-xxxxx",
        "metric.type": "Produce",
        "metric.client_id": "cloud_client_id_1"
        },
        {
        "timestamp": "2025-04-11T00:00:00Z",
        "value": 6.0,
        "resource.kafka.id": "lkc-xxxxx",
        "metric.principal_id": "u-xxxxx",
        "metric.type": "ListOffsets",
        "metric.client_id": "cloud_client_id_1"
        }
    ]
}

For more information on how to query the Metrics API, see Confluent Cloud Metrics.

Related content