Kafka REST Proxy: Confluent vs Karapace vs Strimzi

Apache Kafka has no built-in HTTP API for records: clients speak Kafka's binary protocol over TCP. A Kafka REST proxy translates between the two, so applications can produce and consume Kafka records over HTTP. Common use cases include browser apps, serverless functions that prefer an HTTP API, and services on networks that only allow HTTPS. Producing is the simpler part: every REST proxy compared here accepts a POST with a batch of records and returns offsets. Consuming through a consumer-instance API is harder. Requests for that consumer must reach the proxy process that owns it. A proxy restart loses the instance; idle cleanup depends on the proxy and its configuration.

This guide compares three self-managed Kafka REST proxies you can run against an Apache Kafka cluster: Confluent REST Proxy, the reference implementation of the v2 and v3 APIs, under the Confluent Community License; Karapace, an Apache 2.0 implementation of the Confluent v2 API; and Strimzi Kafka Bridge, an Apache 2.0 bridge with its own v2-style API and no built-in Schema Registry serialization. It covers API compatibility, serialization formats, consumer recovery, authentication, license, and maintenance activity, then looks at the built-in options on Redpanda and Confluent Cloud and at declarative HTTP gateways.

Quick decision

Does Kafka have a REST API?

Not for producing or consuming records. Kafka Connect has a REST API for managing connectors and tasks, but it does not expose record-level produce or consume endpoints.

To reach Kafka over HTTP, you run a proxy that translates HTTP requests into Kafka client calls, or use one built into your platform. Two kinds of work go through these proxies:

• Data plane: producing and reading records. Consumer-instance APIs support group subscriptions or manual partition assignment. Redpanda's HTTP Proxy also lets clients read a partition at an explicit offset without creating a consumer instance.
• Admin plane: listing and creating topics, reading and changing configs, and inspecting consumer groups.

Confluent REST Proxy covers both, with a v2 API for produce and consume and a v3 API for produce and administration. Karapace and Strimzi Kafka Bridge focus on the data plane and expose a smaller set of metadata and admin endpoints.

Kafka REST proxies compared

This table is based on each version's documentation, source code, and upstream test definitions.

Confluent REST Proxy

Confluent REST Proxy defines the v2 API that Karapace and Redpanda implement and that Strimzi's API is modeled on. It is source-available under the Confluent Community License, which allows production use but not offering it as a competing hosted service; it is not an OSI-approved open source license.

Capabilities and limitations

• v2 API: Produces to topics and partitions and runs consumer instances with subscription, manual assignment, seek, commit, and fetch endpoints. The embedded formats are json, binary, avro, protobuf, and jsonschema; with the last three, the proxy registers or looks up the schema in Schema Registry and writes records in the Confluent wire format.
• v3 API: Adds cluster administration (topics, configs, ACLs, consumer groups) and a produce endpoint, POST /v3/clusters/{cluster_id}/topics/{topic_name}/records, which can stream records over one connection. It has no consume endpoints, so HTTP consumers still use v2. Confluent's reference warns that "the v3 Produce API returns HTTP 200 even when individual records fail validation." Check the HTTP status for request-level errors, then the error_code in each delivery report: 200 means that record was written.
• Authentication: HTTP clients can authenticate with Basic, mutual TLS, or OAuth/OIDC. OAuth/OIDC uses Confluent's security plugins, which require an Enterprise license (a trial is available). Authenticating the HTTP caller and authenticating the proxy's Kafka connections are separate settings. Basic authentication alone does not propagate the caller's identity to Kafka ACLs; principal propagation requires the Enterprise security plugin.
• Upgrading from before 8.0: Check HTTPS host name handling after the move to Jetty 12 (the check can be turned off with sni.host.check.enabled=false), and update the HTTP Basic JAAS module to org.eclipse.jetty.security.jaas.spi.PropertyFileLoginModule. For schema-based formats, null key or value data is now validated against the supplied schema; set null.request.body.always.publishes.empty.record=true to restore the previous behavior.

When to choose Confluent REST Proxy

Choose Confluent REST Proxy if you run Confluent Platform, need the v3 API, or want the reference implementation of the v2 API with Avro, Protobuf, and JSON Schema serialization. Choose another proxy if you need an OSI-approved license, or per-caller Kafka identity without an Enterprise license.

Karapace

Karapace is Aiven's implementation of both Schema Registry and REST Proxy, written in Python and licensed under Apache 2.0. It describes itself as a "drop-in replacement both on pre-existing Schema Registry / Kafka Rest Proxy client and server-sides", and Aiven runs it for its own managed Kafka service.

Capabilities and limitations

• API: Implements the Confluent v2 API for producing, consumer instances, and metadata.
• Schema Registry: Avro, Protobuf, and JSON Schema formats serialize through a configured Schema Registry endpoint. The REST proxy and Schema Registry can be enabled independently.
• Authentication: With rest_authorization enabled, Karapace uses each caller's Authorization header for that caller's Kafka connection. Basic credentials use the configured SASL mechanism, such as PLAIN or SCRAM; Bearer tokens use SASL OAUTHBEARER. Kafka validates the JWT and enforces ACLs; Karapace reads the token's expiry to manage its client connections.
• OAuth sessions: Karapace removes the clients tied to a token before it expires. Before that cleanup, commit processed offsets and delete the existing consumer using the current token, then refresh the token and recreate the consumer.

When to choose Karapace

Choose Karapace if you want the Confluent v2 API with Schema Registry serialization under the Apache 2.0 license, or per-caller Kafka ACLs without an Enterprise license. Choose Confluent REST Proxy if you need the v3 API.

Strimzi Kafka Bridge

Strimzi Kafka Bridge is the Strimzi project's HTTP bridge for Kafka, written in Java and licensed under Apache 2.0. Its HTTP API is published as an OpenAPI specification that the bridge also serves at GET /openapi.

Capabilities and limitations

• API: The paths and media types resemble Confluent v2 (POST /topics/{topic}, POST /consumers/{group}, application/vnd.kafka.json.v2+json), but the APIs are not interchangeable: Strimzi does not expose Confluent's endpoint for reading a consumer's committed offsets. CORS can be enabled for browser clients.
• Deployment: Many people meet it as the KafkaBridge custom resource that the Strimzi Operator deploys on Kubernetes, but the bridge is a standalone Java application. You can also download the archive and run it on a host, or run its container image yourself.
• Formats: json, binary, and text, with no built-in Schema Registry serialization. A client can serialize a record with a Schema Registry serializer, Base64-encode the resulting bytes, and send them using the binary format; the bridge forwards those bytes to Kafka. That is a workaround, not Schema Registry support: the client needs a serializer and registry access, which is often what you were trying to avoid by using HTTP.
• Security: The bridge can serve HTTPS, but it does not authenticate HTTP clients. Add authentication through a reverse proxy or API gateway; network policies and firewalls can restrict network access. Connections from the bridge to Kafka support TLS and SASL.
• Observability: Supports OpenTelemetry tracing and Prometheus metrics at /metrics, both enabled through configuration.

When to choose Strimzi Kafka Bridge

Choose Strimzi Kafka Bridge if you already use the Strimzi Operator and need HTTP produce and consume with JSON, text, or binary payloads. Choose Karapace or Confluent REST Proxy if you need built-in Schema Registry serialization or per-caller Kafka identities.

Redpanda HTTP Proxy (Pandaproxy)

Redpanda builds an HTTP proxy into its brokers, configured in the pandaproxy section of redpanda.yaml. On self-managed Redpanda, it listens on port 8082 by default. On Redpanda Cloud, it is available on BYOC and Dedicated clusters, not Serverless, and its address comes from the cluster's connection details.

Capabilities and limitations

• API: Uses Confluent v2 paths and media types to list topics and brokers, produce, and run consumer groups with subscribe, fetch, and commit. The consumer API is a subset of v2: creating a consumer accepts only "auto.offset.reset": "earliest" and "auto.commit.enable": "false", so clients must commit offsets explicitly.
• Direct partition reads: GET /topics/{topic}/partitions/{partition}/records?offset=0&timeout=1000&max_bytes=100000 reads from an explicit offset without creating a consumer instance. The caller tracks its own progress; this is separate from the consumer-group subscribe and commit APIs.
• Formats: JSON and binary, with no built-in Schema Registry serialization. Schema-encoded records must be serialized by the client and sent as Base64-encoded binary data.
• Authentication: HTTP Basic with SCRAM credentials, or OIDC Bearer tokens; OIDC requires an Enterprise license on self-managed Redpanda. Authenticated callers are subject to their Kafka ACLs.
• Consumer timeout: Consumer instances expire after five minutes of inactivity by default, configurable through pandaproxy.consumer_instance_timeout_ms.

When to choose Redpanda HTTP Proxy

If you already run self-managed Redpanda or a Redpanda Cloud BYOC or Dedicated cluster, start with its built-in HTTP Proxy before deploying a separate proxy.

Confluent Cloud REST API

Confluent Cloud hosts a Kafka REST API v3 on its clusters, so you can produce over HTTPS without running a proxy. Authenticate with a cluster API key over HTTP Basic, preferably one owned by a service account, or with OAuth 2.0.

Capabilities and limitations

• Produce: Produce Records, POST /kafka/v3/clusters/{cluster_id}/topics/{topic_name}/records, is generally available and supports a streaming mode over one connection. Check the HTTP status for request-level errors, then the error_code in each delivery report: 200 means that record was written.
• Formats: BINARY, JSON, and STRING, with no built-in Schema Registry serialization. Schema-encoded records must be serialized by the client and sent as Base64-encoded BINARY data.
• Consume: As of 3 Oct 2026, the published API reference documents record production but no record-consumption endpoint. Consumer-group and lag endpoints return metadata, not topic records. Some guides show consume examples, but those routes are absent from the API reference.
• Admin: Topics, configs, ACLs, Cluster Linking, and consumer-group metadata; the lag endpoints are documented as Dedicated-only.

When to choose Confluent Cloud REST API

Use the hosted API when you need to produce to Confluent Cloud over HTTPS without operating a proxy. For HTTP consumption or built-in Schema Registry serialization, use a self-managed REST proxy connected to the cluster. If HTTP is not required, use a native Kafka client for consumption.

Declarative HTTP gateways: Zilla and Gravitee

The proxies above expose Kafka's own concepts: topics, partitions, consumer instances, offsets. A gateway lets you design the HTTP API your application needs and maps it onto Kafka.

• Zilla from Aklivity is configured in YAML. You declare HTTP routes and how each maps to topics, keys, and headers, and it can serve topics as Server-Sent Events streams. Zilla mixes Apache 2.0 components with modules under the Aklivity Community License 1.0, including its HTTP–Kafka and SSE–Kafka bindings. The community license permits production use but excludes providing hosted services that compete with Aklivity's offerings.
• Gravitee API Management can put HTTP POST, HTTP GET, WebSocket, SSE, and webhook entrypoints in front of a Kafka endpoint. These message APIs are an Enterprise Edition feature.

Choose a gateway when clients need an application-specific API, such as POST /orders, with routes mapped to Kafka topics. Choose a REST proxy when clients need a general-purpose API that exposes Kafka topics, partitions, records, and consumer operations.

Consumer instances: routing, timeouts, and recovery

Suppose your service creates a consumer through proxy A and then fetches records from it over HTTP. That consumer lives in proxy A's process. If a load balancer sends the next request to proxy B, B has no such consumer and returns 404. If proxy A restarts, the consumer is gone and must be created again. A native Kafka client keeps this state in your own process; a REST proxy keeps it on the instance that created it. Three things follow.

Send every request for a consumer to the same instance. Producer requests can go to any instance. Use the returned base_uri for subsequent consumer requests. If that URI points to a load balancer, configure session affinity so requests reach the instance that created the consumer. Strimzi leaves this affinity to the client application.

Detect a lost consumer and recreate it. Idle cleanup and proxy restarts both destroy consumer instances. Confluent and Redpanda remove idle consumers after five minutes by default; Karapace and Strimzi disable idle cleanup by default. Fetch more often than the idle timeout. On a consumer-not-found response, first check routing and session affinity. If the consumer has expired or its proxy has restarted, recreate it in the same group and restore its subscription. Delete consumers explicitly when your service shuts down.

Commit after processing, and expect redelivery. Session affinity cannot bring back a destroyed consumer. What survives is the group's committed offsets in Kafka: a recreated consumer in the same group resumes from those offsets, provided they have not expired and remain within each partition's valid offset range. Disable auto-commit and commit after processing; records that were processed but not committed before the loss may be delivered again, so make processing idempotent. (With Redpanda's direct partition reads, there is no consumer instance to lose, but your application must store the next offset for each partition.)

GitHub repository metrics

The tables below compare the GitHub activity, maintenance, and public interest of the three proxies. Snapshot: 2 Oct 2026.

Redpanda's HTTP Proxy lives in the Redpanda monorepo, which measures the broker rather than the proxy, so it is not included. The Karapace repository also contains its Schema Registry, so its figures cover both components.

Project overview

Activity

Confluent ships REST Proxy as part of Confluent Platform rather than through GitHub Releases. Its commit count is inflated by automated merges that carry each change forward through every maintained release branch (7.6.x into 7.7.x, and so on up to master); merged PRs are the better activity signal.

Maintenance

PR merge distribution counts non-bot merge accounts, with percentages calculated over merges attributed to those accounts. It does not measure reviewer or maintainer headcount. Median PR merge time measures creation to merge for PRs merged in the last 90 days; unmerged PRs are excluded. Issue closure rates use issues opened 90–180 days before the snapshot, giving each issue a full 90-day window. These figures cover public GitHub issues and exclude commercial support channels.

Public interest

Stars and forks measure interest, not use.

Overall repository signals

• Confluent REST Proxy has the most accounts merging PRs, 17 in 12 months. For the 18 PRs merged in the last 90 days, the median creation-to-merge time was 17.6 hours. Its open backlog is old: 238 issues with a median age of 7.7 years and 38 PRs with a median age of 3.6 years.
• Karapace releases most often, 15 GitHub releases in 12 months, but those releases also cover its Schema Registry. Only 1 of 7 issues in the measured cohort was closed within 90 days.
• Strimzi Kafka Bridge has no open PRs and the fastest median merge time, 3.4 hours, but one account handled 88% of attributed merges in the past year.

These are repository activity, maintenance, and public-interest signals, not evidence of runtime quality or feature fit.

Test Kafka REST proxies with Kafma

Check what the proxy stored

Even a successfully produced record may contain bytes that differ from the consumer's expected format: a payload Base64-encoded twice is stored as Base64 text, and Avro bytes sent through binary without the Confluent prefix fail in consumers that expect it.

Kafma's Kafka console shows the record as Kafka stores it. Raw shows the exact bytes in hexadecimal, and with a Confluent-compatible Schema Registry connection, automatic decoding reads the schema ID from the record and shows the decoded value.

This matters most with Strimzi, Redpanda, and Confluent Cloud, which have no built-in Schema Registry serialization. The client serializes the value with a Confluent-compatible Schema Registry serializer (which adds the prefix), Base64-encodes the bytes once, and sends them as binary. A value written this way shows magic byte 0x00 and the 4-byte schema ID at the start of Raw, and decoding shows the expected value.

See where an HTTP consumer will resume

A consumer recreated in the same group starts from the group's committed offsets, if they are still valid. The proxy may not show them: Strimzi has no endpoint for them, and Confluent's requires a live consumer instance. Kafma's consumer group UI shows each partition's committed offset, lag, and assignment.

Auto-commit can commit offsets for records your application has not processed yet, so a lost consumer may skip them. Disable it when you create the consumer. In a test group with a single consumer, the committed offsets in Kafma should then move only after your application commits.

Watch Group marks the records around those positions as consumed or pending. Kafma reads this without joining the group, so it does not disturb the HTTP consumers. These labels reflect committed offsets, not whether application processing succeeded.

Move offsets before recreating consumers

Sometimes you need a different starting position: to skip a record that keeps failing, or to process a range again. Recreating the consumer does not help, because it resumes from the same committed offsets.

1. Stop all applications using the group, delete their HTTP consumer instances, and wait for the group to become Empty or Dead. Kafma enables Reset Offsets only then, so no running member can commit over the change.
2. Reset the offsets to the earliest or latest offset, a timestamp, a specific offset, or by a relative amount.
3. Recreate the HTTP consumers in the same group and restore their subscriptions. They start from the new offsets.

Download Kafma and connect it to the cluster behind your proxy.

Frequently asked questions

Does Kafka have a REST API?

Not for producing or consuming records. Kafka Connect has a REST API, but it manages connectors and tasks. Producing and consuming over HTTP needs a proxy; see Does Kafka have a REST API?.

What is the difference between the v2 and v3 REST Proxy APIs?

v2 produces and consumes, with Schema Registry formats. v3 produces and administers the cluster but has no consume endpoints. See Confluent REST Proxy.

Can a REST proxy consume messages?

Yes. Consumer-instance APIs keep state in one proxy process, so plan for session affinity, idle timeouts, and restarts; see Consumer instances: routing, timeouts, and recovery. Redpanda's HTTP Proxy also provides direct partition reads, where the caller supplies the offset without first creating a consumer instance.

Is Karapace a drop-in replacement for Confluent REST Proxy?

For the Confluent v2 API, that is its stated goal. Test the endpoints and formats you use. It does not implement Confluent's commercial security plugins; with rest_authorization enabled, it forwards each caller's credentials to Kafka instead.

Is Kafka-Pixy still maintained?

The repository appears inactive. Kafka-Pixy, Mailgun's gRPC and REST proxy, tagged its last release, v0.18.0, in July 2021, and its default branch has had no commits since July 2022. It manages consumer-group membership through ZooKeeper, so it is not suitable for KRaft-only clusters, including Kafka 4.0 and later.

What happened to Upstash Kafka's REST API?

Upstash announced the deprecation of Upstash Kafka on 6 September 2024. The announcement said it was no longer accepting new users and would discontinue support in six months. It did not specify an exact shutdown date. Upstash Kafka is therefore not an option for a new deployment; existing integrations should follow the provider's migration guidance.

Conclusion

If you run Confluent Platform or need the v3 API, start with Confluent REST Proxy and accept its source-available license. If you need the v2 API with Avro, Protobuf, or JSON Schema serialization under Apache 2.0, choose Karapace; test the endpoints you depend on. If you already use the Strimzi Operator and need JSON, text, or binary payloads, choose Strimzi Kafka Bridge, with a reverse proxy or API gateway for HTTP client authentication.

When you use a consumer-instance API, commit after processing and be ready to recreate the consumer. With direct partition reads, persist the next offset for each partition in your own application. To check what your proxy wrote and where its consumers will resume, use Kafma alongside it.

This guide is maintained by the team behind Kafma.