In large organizations, platform architecture tends to be more historical artifact than intentional design. At the foundation of the stack sit monoliths that predate modern API standards; many of them are too risky or too costly to decommission fully. Built on top of them are services that were stood up to fill the gaps, often duplicating functionality or exposing overlapping APIs. Over time, ownership becomes shared, fragmented, or altogether unclear, as teams pursue incremental modernization without the luxury of taking the business offline.

The result? A set of challenges that will feel all too familiar. 

• No single source of truth for what APIs actually exist across the organization
• APIs that mirror backend structure rather than serving consumer needs
• Multiple services exposing similar capabilities in inconsistent ways
• Difficulty in safely exposing internal functionality to partners or external developers
• Inconsistent governance, particularly around access control and rate limiting

Before any of that can be addressed, you need visibility into what you're actually working with.

In the enterprise, the API you want to expose is rarely a one-to-one match with a backend service. Your actual business needs might look more like this:

• Expose only a subset of operations from a large monolith
• Combine operations from multiple services into a single, cohesive API
• Create a simplified API tailored to a specific partner or internal team
• Publish different “views” of the same backend for different audiences

Historically, delivering on any of these scenarios has been an uphill battle. APIs were tightly coupled to gateway services and routes, which meant your API's shape was ultimately dictated by your infrastructure; unfortunately, not by business requirements.

API composition in Konnect Catalog changes that equation entirely by removing that coupling.

Starting with Kong Gateway v3.13 and later, you can install the Access Control and Enforcement (ACE) global plugin declaratively on a control plane. This new method of linking APIs in the Konnect Catalog enables new possibilities for developer self-service in Dev Portal.

Instead of linking a Catalog API directly to a single gateway service, you can now link it to a control plane with ACE enabled. This is a meaningful shift in how platform teams operate.

By linking at the control plane level, a single Catalog API can now span:

• Multiple gateway services
• Multiple routes
• Only the specific operations you choose to expose

For platform teams, this means APIs are no longer constrained by how backend services happen to be built or routed internally. For consumers, it means the API reflects how they actually think about the capability — not how the infrastructure is wired together behind the scenes.

Once an OpenAPI spec is added to the Catalog, Konnect analyzes the operations defined in the spec and maps them to the actual routes configured on the gateway.

This process uses the same routing logic as Kong Gateway itself, so what you see in the Operations view is a true reflection of how traffic will actually flow in production.

It translates into the ability to compose new APIs from existing routes without duplicating services or rewriting backend code.

For example:

• Create a unified “customer profile” API that pulls operations from billing, identity, and preferences services
• Publish a partner-facing API that exposes read-only operations from an internal service
• Define a stable API surface while backend teams refactor or consolidate services behind the scenes

This is how enterprises transition from infrastructure-driven APIs to API-as-a-Product.

As platforms mature, teams often want to define and operate APIs at multiple levels simultaneously:

• Low-level, service-oriented APIs for internal use
• Higher-level, consumer-oriented APIs for specific use cases

At the same time, platform teams still need to understand dependencies, enforce governance, and apply consistent controls.

This is exactly where API packaging becomes critical.

API packages, available in Catalog / APIs, allow you to group operations from one or more existing Catalog APIs into a single package. Think of a package as a curated API product built from your underlying building blocks.

With API packages, you’re able to:

• Assemble operations across multiple APIs
• Apply rate limits at the package level
• Override rate limits for specific operations when needed

When an application registers for an API package, those limits are enforced automatically through the gateway.

Once published to the Dev Portal, an API package behaves just like any other API

Developers can:

• Discover it in the portal
• Register it to an application
• Receive credentials
• Start making requests

Developers don’t need to know how many backend services are involved, or how the API was composed. For them, it’s a single, well-defined contract.

When combined with Teams and role-based access control (RBAC), this allows platform teams to expose tailored APIs to specific audiences, including internal teams, partners, or external customers, without creating and managing entirely separate gateway configurations.

API composition and packaging aren’t only about flexibility. They’re about acknowledging how enterprise platforms really work.

They let you do the following:

• Represent today’s architecture transparently
• Define the API surface you want consumers to see
• Modernize incrementally, without breaking contracts
• Apply consistent governance across composed APIs

Most importantly, they allow API teams to shift the conversation — from “how is this service built?” to “what capability are we offering, and to which audience?”

That is the foundation of a scalable API platform, and how to think in API-as-a-product terms.

Ready to start composing APIs? Our step-by-step guide to API packages walks you through your first implementation, starting from ACE setup to publishing your first package in the Dev Portal. To get started, check out our how-to guide for API packages.