Today, we're pleased to announce Kong Gateway 3.10, our next Long-Term Support (LTS) version. This LTS version will be supported until March 2028, up to three years from the release date. Please check our documentation [here](https://docs.konghq.com/gateway/latest/support-policy/)here for more details on Kong’s support policy.

Highlights of this release include:

• - Exposing Kafka topics as REST and SSE APIs 
• - Easier data orchestration with Request Callout
• - Centralized management of Redis configuration
• - Incremental Config sync goes GA 

To find out more, keep reading! 

## Exposing Kafka topics as REST and SSE APIs 

We're excited to announce that you can now expose Kafka topics for consumption as REST and Server-Sent Events (SSE) API endpoints, allowing you to consume Kafka topics — synchronously or asynchronously — without having to interact with the Kafka protocol. This is driven by the Kong Gateway’s new protocol mediation capabilities, enabled by the new Kafka Consume plugin. 

Protocol mediation extends the value of your real-time data by opening up access to new application teams or even external partners that can’t — or don’t want to — set up their applications as native Kafka clients. Developers can integrate event-driven workflows into their applications more easily without dealing with the complexity of navigating native Kafka protocols and libraries. Using familiar HTTP-based APIs helps reduce the friction developers face when adopting event-driven architectures.

As always, Kong Gateway allows you to add additional security, resilience, and access controls, such as authorization, encryption, and rate-limiting, to protect your API and back-end systems. 

The new Kafka consumer plugin rounds out Kong Gateway’s existing Kafka and Confluent Upstream plugins, which already support producing messages to Kafka via HTTP. The existing Kafka Log plugin, which supports pushing Kong telemetry to other platforms via Kafka, has also been updated to enable customization of the message format.

With this update, you can now more confidently, and securely expose Kafka event streams via Kong Gateway for both producing and consuming applications. This feature opens up new opportunities to deliver innovative customer experiences and real-time process automation.

If you're interested in our new Kafka Consume plugin, you can find it on the [plugin hub](https://docs.konghq.com/hub/?category=transformations)plugin hub.

## Centralized management of Redis configuration

Many Kong plugins — such as rate limiting, service protection, and caching — rely on Redis for state management and data processing across distributed systems. Before this update, you had to specify the Redis config for every API and plugin that used Redis. Updates were cumbersome, and developer time was wasted.

You can now define your Redis configuration once globally and reference that configuration in other plugins. This should help your teams eliminate redundancy, reduce the potential for error, and simplify change management for both the self-managed and Konnect-managed Gateways. 

We’ve added a new `partials` config and admin endpoint to support defining these reusable terms. Please take a look at a sample decK configuration below or refer to the documentation [here](https://docs.konghq.com/gateway/3.10.x/kong-enterprise/partials/)here:

_format_version: "3.0"
partials:
- config:
    read_timeout: 3001
    send_timeout: 2003
  name: my-ee-partial
  type: redis-ee
plugins:
- config:
    limit:
    - 10
    window_size:
    - 60
    window_type: sliding
    namespace: test-ns
    sync_rate: -1
  enabled: true
  name: rate-limiting-advanced
  partials:
  - name: my-ee-partial

## Calling out to third-party services with Request Callout 

While not every use case or API implementation calls for orchestration or heavy amounts of Gateway logic, some do. These use cases often require the ability for the Gateway to “call out” to third-party services during a single request flow. Typically, we see two use cases that customers want callouts for:

1. - **Custom auth scenarios:** where the upstream API requires a specific token or credential to be retrieved from a specialized auth service. For example, Kong will reach out to an authentication service such as Okta or PingFederate using a credential that will respond with a payload containing the token and time-to-live (TTL) for that token. Kong will then attach the token to the upstream request, all in a single request flow.
2. - **Request augmentation:** augment API requests with data from a third-party service. This could involve manipulating headers or merging the request body of an API request with that of another. For example, let’s say you are an e-commerce company that is a Kong Gateway customer. Kong Gateway can formulate a new request using the ConsumerID to a third-party service that returns store and brand information. These can then be used to transform the upstream request, adding new headers to deliver the correct brand experience for the user. 

Here’s an example of augmenting a request with additional data from external services.

Historically, this has required custom plugin work. With 3.10, we're changing this with a new Request Callout policy, enabled by the [Request Callout plugin](https://docs.konghq.com/hub/kong-inc/request-callout/)Request Callout plugin. This capability enables customers to call out to third-party APIs and use the response to populate or transform subsequent API requests — opening up new data orchestration and internal auth use cases without the extra dev work required for custom plugins.

### Incremental Config sync is now GA 

At the end of last year, we announced the tech preview availability of Incremental Config Sync. We're happy to now announce that this feature is generally available for our Konnect customers using hybrid deployments. 

For those not familiar with this functionality, here's a quick refresher:

For customers using hybrid deployment models, configuration updates can use up crucial resources such as CPU and memory and reduce the performance reliability of your apps and services. This is because the control plane would send the entire configuration set to each data plane. For customers with large configuration sets, this can mean a big resource draw on the Gateway.  In extreme cases, this results in latency spikes and loss in throughput for high-traffic data planes.

To address this pain point, we've introduced incremental configuration updates. The control plane will send only the changed parts of the configuration to data planes. This is good news for customers with large deployments and thousands of configuration entities, who can now enjoy much lower CPU and memory usage on DPs and more consistent and predictable latency and throughput. 

Please refer to this [previous blog post](https://konghq.com/blog/product-releases/incremental-config-sync-tech-preview)previous blog post for the performance benchmark tests for Konnect Control Planes, including CPU and memory usage improvements.

This feature will not be enabled by default. To try this capability, you must change your settings to use this feature. Please refer to the documentation [here](https://docs.konghq.com/gateway/latest/production/deployment-topologies/hybrid-mode/incremental-config-sync/)here to learn how. 

## Consumers in Konnect now GA

We're making centralized consumer management and identity on Konnect generally available to help customers reduce operational overhead. By storing and maintaining Kong consumer definitions outside of data plane config, customers can define consumers once and reference them across multiple control planes without replicating consumer definitions for every control plane. Consumer configuration can also be retrieved “just-in-time” and cached locally in the data plane with automatic cache management.

For customers with many thousands of consumers, storing consumers in your data plane in memory takes up resources. This is because a large number of consumers would be tied to each control plane, increasing the size of the configuration that is pushed down to data planes. 

With this update, customers can expect smaller config sync sizes and overall sync overhead.

You can learn more about this feature [here](https://docs.konghq.com/konnect/centralized-consumer-management/)here.

## Providing the infrastructure for agentic workflows with AI Gateway

We also have some exciting updates for Kong AI Gateway with new functionality to enhance AI governance, reduce LLM hallucinations with [automated RAG pipelines](https://konghq.com/blog/enterprise/automated-rag-hallucination-proof-llms)automated RAG pipelines, and provide the underlying [infrastructure for agentic workflows](https://konghq.com/blog/enterprise/building-pii-sanitization-for-llms-and-agentic-ai)infrastructure for agentic workflows. Check out the [AI Gateway 3.10 blog post](https://konghq.com/blog/product-releases/ai-gateway-3-10)AI Gateway 3.10 blog post for the full details.

## Getting started with Kong Gateway Enterprise 3.10

Start with Kong Gateway Enterprise 3.10 by [signing up for Kong Konnect](https://konghq.com/products/kong-konnect/register)signing up for Kong Konnect for free. Alternatively, you can explore the options for getting started [here](https://konghq.com/install)here. 

Please see the [CHANGELOG](https://docs.konghq.com/gateway/changelog/)CHANGELOG for Kong Gateway Enterprise here to explore the comprehensive list of features, fixes, and updates.