Zilla Console / API Data Products

Publish Kafka topics as governed API products.

API Data Products are how the Zilla Console turns a topic into a product — AsyncAPI contract, plans, versions, deployments, identity, and rate limits, enforced on every request at the Zilla Kafka Gateway.

a capability of the Zilla Console · included with

Plus

Enterprise

Explore the Console

Try the quickstart

console.aklivity.io / catalog / orders-apiv1.2

Zilla Console

OverviewEnvironmentsClustersGatewaysWorkspacesCatalogApplicationsPoliciesSecurityUsers

Orders APIspec · plans · deployments

Spec

channels: orders.created
schema: Order · avro
security: sasl/plain · mtls
# source: orders.asyncapi.yaml

Plans

Internal10 000 bytes/sec · api key

Partner1 000 bytes/sec · mtls

Deployments

production2 gateways

staging1 gateway

The problem

Kafka holds the data. It doesn’t carry the product.

The gap

Kafka topics move events. They don't carry a contract, a version, an access tier, a developer surface, or a credential lifecycle.

The consequence

Consumers assemble that layer by hand — schemas, ACLs, bootstrap details, connection docs — then redo it every time a producer changes shape. Contracts drift; consumers break in production.

The resolution

Aklivity makes the Kafka interface the product: spec-defined, plan-governed, subscription-consumed, gateway-enforced. The topic stays where it is; the product layer becomes visible and enforceable.

The definition

Five components. One catalog entity.

In the Console’s Catalog, an API Data Product is a named entity that combines contract, runtime binding, policy, version, and deployments into one governable object.

Plus

Enterprise

One product, one spec — multiple plans, multiple versions, multiple environments.

AsyncAPI Specification

The contract — channels, operations, and schemas. One source of truth for the catalog entry, the gateway's runtime validation, and the consumer's connection guide.

Server Settings

Bind the product to its gateway and Kafka runtime — bootstrap server, gateway pool, and an optional Schema Registry attachment. After deployment it is reachable at {product-name}.<your-domain>:9094.

Plans

Rate limits, security, and audience controls. One product can carry several — Internal, Partner, Trial — each consumed independently.

Versions

Breaking changes stay separated. Multiple versions of one product run at once, and the previous version stays available until consumers migrate.

Deployments

Place the product in one environment or many, each with its own gateway pool, Kafka cluster, and plan attachments.

What’s different

Four structural choices, not four features.

Architectural commitments, not capability bullets. Each one shapes what an API Data Product can do in production.

Spec-first, not registry-first.

The Zilla Kafka Gateway validates against AsyncAPI directly. A Schema Registry can attach, but it is never the choke point for governance.

Governance becomes enforcement.

Deploy the product and the control plane pushes identity, plans, rate limits, and schema validation to every attached gateway. No separate ACL script, validator service, or side-channel config.

One product serves many clients.

Kafka, HTTP, SSE, WebSocket, gRPC, MQTT, or MCP — same gateway, same identity, same plan, same schema. The gateway translates at the edge.

One product runs across vendors.

Production on Amazon MSK, staging on Apache Kafka, development on Redpanda. One contract; environment-specific runtime.

The lifecycle

Define. Publish. Deploy. Consume.

The four-step path from a live Kafka topic to a governed Data Product with consumers — all four steps in one console.

Step 01

Define

Generate an AsyncAPI spec from a live Kafka cluster, import a team-owned spec, or iterate on one in a Workspace.

Step 02

Publish

Publish it as a product with Server Settings and one or more Plans. It enters the Catalog as a versioned entity.

Step 03

Deploy

Deploy to an Environment and the attached gateways begin enforcing identity, plans, and schema validation in real time.

Step 04

Consume

Consumers register an Application, create a Subscription, and receive generated credentials with a ready-made connection guide.

The consumption side

The product is the contract. The plan is the policy. The subscription is the entitlement.

Platform teams publish products. Developers and partners see only entitled products, plans, credentials, and connection details — the console narrows to what their Team entitlements and subscriptions allow.

Product

the contract

Plan

the policy — rate limit + security

Subscription

the entitlement — app × version × plan

Credentials

generated, revealed once, revocable

Plans attach rate limits and security policy. Subscriptions link an application to a product, a version, and a plan. Credentials are generated automatically, revealed once, and revocable at any time. Every request is attributable through gateway telemetry.

See the Federated Access pattern

what consumers never see

Kafka cluster credentials — the gateway terminates identity and proxies under its own.

Other teams' products — Catalog visibility is gated by Team entitlements.

Schema Registry configuration — the AsyncAPI spec drives validation at the gateway.

The portability claim

Define the contract once. Deploy it across the fleet.

A Data Product is defined by its spec, not by the Kafka cluster behind it. Run one product across environments, vendors, gateway pools, and regions while preserving one contract in the Catalog.

api data product · deployments Orders API v1.2

Environment	Cluster vendor	Gateway pool	Plans
dev	Apache Kafka	zilla-dev-1	Internal
staging	Redpanda	zilla-stg-1	Internal
prod	Amazon MSK	zilla-prd-3	Internal · Partner

One product, three deployments. Same spec; different clusters, vendors, and plan attachments per environment.

Environment parity across vendors.

A product backed by an MSK topic in production can have its staging twin backed by a self-managed Apache cluster — same spec, same schema validation, same Plans. The contract carries between environments; the cluster is a deployment detail.

Partner exposure without separate clusters.

Attach a Partner Plan to a production deployment and the same product surfaces to authorized partners with a tighter rate limit and API Key auth — no partner-only cluster, no partner-only catalog.

Multi-region, multi-compliance.

Deploy one product to two production Environments in two regions, each backed by the region's local cluster, each enforcing region-local Plans and mTLS issuance. The spec stays one object in the Catalog.

See the Federated Access pattern

FAQ

Questions platform teams ask.

Get started

Get API Data Products with the Zilla Console.

Define the contract once, govern it with plans, enforce it at the gateway — across Apache Kafka, Amazon MSK, Confluent Cloud, Aiven, Redpanda, and Cloudera. Included with Plus and Enterprise.

Try the MCP Gateway

Try the quickstart

Read the docs

Talk to engineering

Request a demo

Read the architecture brief