Still using Postman and Backstage with Multiple Gateways? You’re Already Behind!

Most enterprise API stacks were assembled the same way. A team needed to test APIs, so Postman got adopted. A CTO read about Backstage and greenlit a portal project. Apigee was already in production before AWS API Gateway showed up for a new microservices project. Kong came in through a Kubernetes migration. And somewhere along the way, someone set up Confluence for documentation.

Each decision made sense in isolation. None of them were made with the others in mind.

By the time a platform engineer inherits this stack, the org is running 5 or more tools that were never designed to work together, with APIs living in multiple systems and no single point of truth for any of them. The average enterprise now manages over 354 APIs across its infrastructure each with its own routing, authentication, rate limiting, and monitoring requirements. And 78% of organizations don't know exactly how many APIs they have, according to an Axway survey of technology executives.

The individually best-of-breed stack becomes collectively unmanageable. This article explains why and what the architecture looks like when it's fixed.

TL;DR

1. The typical enterprise API stack Postman for testing, Backstage for catalog, multiple gateways for runtime creates fragmentation, not efficiency, because these tools were never built to interoperate natively

2. The average enterprise manages 354+ APIs; 78% of organizations don't know their full API count; 30% of APIs operate outside any governance framework

3. Backstage requires dedicated plugin development per gateway it becomes a maintenance burden, not a developer portal

4. Fragmented gateways produce shadow APIs, zombie endpoints, and inconsistent policies that create real security risk: annual losses from poorly governed APIs are projected to exceed $100 billion in 2026

5. AI agents need a unified, well-documented API estate to function. Fragmented infrastructure makes your APIs invisible to AI systems

6. Gartner predicts over 30% of new API demand will come from AI and LLM tools infrastructure that isn't unified today is already falling behind

7. The fix is not another tool. It is a unified control plane above your existing stack

The Stack You Inherited

Here's the typical picture at a financial institution, insurer, or large technology company in 2026:

• Postman for API design and testing
• Backstage as the internal developer catalog and portal
• Apigee for the core API gateway, managed by one team
• Kong running Kubernetes ingress for another team's microservices
• AWS API Gateway for a set of serverless workloads
• Datadog, New Relic, and Splunk split across monitoring
• Documentation spread across Confluence, Notion, and GitBook

Every team chose the tool that fit their context. The platform engineers who deployed Kong in 2022 had no reason to care that another team was still running Apigee integrations from 2018. The frontend team that set up Backstage had no visibility into the AWS API Gateway deployment that a product team spun up six months later.

The result is not a unified API program. It is five parallel programs that happen to run in the same organisation.

Why the Tools Don't Talk to Each Other

Each tool in this stack was designed to solve one problem well. Postman is an API client. Backstage is a developer catalog. Gateways are traffic management layers. None of them were built to synchronise API state across the others.

What this means in practice: when an API is designed in Postman, deployed in Apigee, published in Backstage, and documented in Confluence, any update to that API requires four separate manual actions to keep every system current. In most organisations, three of those four don't happen. The gateway has the updated spec. Everything else has the version from six months ago.

The result is what platform engineers call the "source of truth problem" no one knows which system holds the authoritative state of an API. And when no one knows, no one trusts any of them. Developers stop using the catalog. They ask on Slack instead. And then they rebuild the API from scratch because it's faster than finding the existing one.

Gartner reports that 80% of large engineering organisations will use platforms to provide reusable services by 2026. The problem is that reuse requires discoverability, and discoverability requires a single, trusted source. Five disconnected tools cannot provide that.

The Backstage Reality Check

Backstage deserves its own section because it's the most common developer portal attempt and the one most likely to create a second maintenance problem.

Backstage is a powerful internal developer platform. It works well when an engineering team has the bandwidth to build and maintain custom plugins for every system it needs to integrate. In a small company with one or two gateways, that's achievable.

At enterprise scale, it becomes untenable. Every gateway you run needs its own Backstage plugin. Every new source of API metadata Postman collections, OpenAPI specs from GitHub, imported specs from a newly acquired company needs custom integration work to surface in the catalog. When the Apigee plugin breaks after an API version update, someone has to fix it. When the Kong plugin doesn't support the RBAC model your security team requires, someone has to extend it.

Backstage maintenance at scale is not a part-time task. It becomes a full-time engineering role sometimes an entire team. What was supposed to reduce developer friction now requires a DevOps team of its own to keep running.

There is a comparison of how DigitalAPI handles this differently from Backstage available at DigitalAPI vs Backstage if you want the specifics side by side.

What Fragmentation Actually Costs

The operational frustration of a multi-tool, multi-gateway stack is visible. The security and business costs are less visible until something goes wrong.

Shadow APIs accumulate silently: Approximately 31% of cyberattacks targeting transactional systems exploit undocumented APIs. Shadow APIs endpoints created by teams without IT oversight, usually for tests or quick fixes are the most common source. They ship without authentication, without rate limiting, and without anyone watching them. When a gateway doesn't have visibility into APIs running on other gateways, shadow endpoints multiply invisibly.

Zombie APIs keep running after deprecation: When the API lifecycle is tracked in five systems and none of them are the source of truth, deprecated APIs don't actually get turned off. They keep receiving traffic sometimes from external partners, sometimes from internal systems that were never updated and they keep exposing data through policies that were written for a different version.

Governance becomes inconsistent across gateways: Each gateway has its own policy engine, its own RBAC model, and its own approach to rate limiting. A security policy applied in Apigee does not automatically apply to the same API's Kong deployment. Developers navigating multiple gateways encounter different auth flows, different SDK behaviour, and different documentation quality depending on which gateway their API runs on. The inconsistency erodes trust and drives rebuilds.

Annual losses from poorly governed APIs are projected to exceed $100 billion in 2026, with the average data breach from an unmanaged API costing $4.4 million. These are not hypothetical risks. They are the predictable outcome of running APIs across systems that share no governance layer.

The AI Agent Problem Is Forcing the Issue Now

Fragmented API infrastructure was an operational pain point for years. In 2026, it has become a strategic blocker because of AI.

Gartner predicts that over 30% of the increase in API demand will come from AI and LLM tools. By end of 2026, projections suggest 80% of API traffic will be driven by non-human actors: AI agents, IoT devices, and automated systems. These agents don't send emails to the platform team asking for API keys. They programmatically discover APIs, read documentation, and make tool calls. If your APIs are poorly documented, spread across disconnected systems, and governed inconsistently, AI agents cannot use them. They will either fail silently or hallucinate incorrect behaviour based on incomplete metadata.

Model Context Protocol (MCP) is the emerging standard that lets AI agents discover and invoke APIs as structured tools. For an AI agent running on Claude or GPT to call your payment API, that API needs to be exposed as an MCP server with clean metadata, consistent authentication, and a stable endpoint. An API that exists in Postman but is deployed on three gateways with three different auth configurations cannot be reliably exposed as an MCP tool without a unification layer sitting above all three.

The organisations that get ahead of this are the ones that unify their API estate now before AI agent adoption forces an emergency migration in 18 months.

Why "Consolidate onto One Gateway" Doesn't Work

The most common proposed solution from technical leadership is to standardise on a single gateway. Just pick Apigee or Kong and migrate everything onto it. Problem solved.

It is not that simple, for three specific reasons that come up in every enterprise evaluation.

Regulatory mandates tie teams to specific platforms: Financial institutions operating across jurisdictions often have regulatory requirements that specify which platforms can process certain data. A team in one region may be required to use a certified platform that the rest of the organisation doesn't run. Consolidation is not available when compliance requires platform diversity.

Acquisition history creates non-negotiable legacy: When a company acquires another, it acquires that company's entire API infrastructure. The acquired company's teams built integrations against their gateway, wrote transformation logic specific to that platform, and run workloads that depend on it. A migration that forces them to rebuild everything overnight carries both cost and disruption risk that most organisations won't accept.

Migration costs at scale are prohibitive: Moving from one gateway to another is not a configuration exercise it is a rewrite of every policy, every authentication flow, every rate limit rule, and every integration test. At 354+ APIs across three or more gateways, that migration cost can exceed $10 million in engineering time before a single API has moved.

The right answer is not consolidation. It is a control plane that works with the gateways you already have.

What the Fix Actually Looks Like

The solution to a fragmented multi-gateway stack is not another point tool. Every additional tool adds another synchronisation requirement and another potential source of truth conflict. The fix is an API management platform that sits above your existing infrastructure and unifies it without replacing it.

The architecture looks like this:

DigitalAPI connects to your existing gateways Apigee, Kong, AWS API Gateway, Azure APIM, and others via read-only credentials. It indexes your full API catalog in under 24 hours, pulling metadata and OpenAPI specs from every connected source. From that point, every API across every gateway is discoverable from a single place, with AI-powered search that surfaces relevant APIs from natural language queries instead of requiring developers to know which gateway to search in.

API governance policies are defined once and applied across all gateways from the same control plane. An OAuth policy change doesn't need to be made four times in four systems. A deprecation decision surfaces everywhere in the catalog, in the documentation, and in the gateway configuration as a single action.

The developer portal is white-labeled and ships with built-in sandboxing, self-serve API key management, and subscription workflows. Internal teams, external partners, and AI agents all access APIs through the same interface. Auth flows are consistent regardless of which underlying gateway handles the request.

AI readiness comes from the MCP Gateway: any API in the catalog can be converted to an MCP server in one click, making it immediately callable by AI agents with appropriate credentials, rate limits, and audit trails without a separate integration build per API.

The existing gateways keep running. Kong still handles Kubernetes ingress. Apigee still manages the enterprise API estate it was built around. Nothing is ripped out. The fragmentation is resolved at the control plane layer, not by forcing everything onto a single runtime.

Named customers operating this architecture include HSBC, Fiserv, Zurich Insurance, and Canara Bank. You can read the specifics of how Canara Bank handled multi-gateway governance at scale on the customer stories page.

What the Stack Looks Like After Unification

For comparison, here is what changes and what stays the same after a unified control plane is in place:

The gateways remain. The teams that built on those gateways keep their workflows. What disappears is the operational overhead of maintaining synchronisation across disconnected systems and the security exposure that comes from the gaps between them.

FAQs

1. Does adopting a unified control plane mean replacing our existing gateways?

‍No. A gateway-agnostic control plane like DigitalAPI connects to Apigee, Kong, AWS API Gateway, Azure APIM, and others via read-only credentials. Your gateway infrastructure stays in place. The control plane governs what's already there rather than replacing it. This is why it resolves the multi-gateway fragmentation problem without triggering a multi-million-dollar migration.

2. Why is Backstage not enough for a large enterprise with multiple gateways?

‍Backstage requires custom plugin development for every gateway and every data source you want to surface in the catalog. At scale, each plugin needs ongoing maintenance as upstream APIs evolve. For enterprises running three or more gateways, this creates a second maintenance problem a platform team dedicated to keeping Backstage synchronized rather than delivering API infrastructure improvements. A purpose-built control plane handles that synchronisation natively.

3. What does "AI readiness" mean for an API estate?

‍For an AI agent to use your APIs as tools, those APIs need to be discoverable as MCP servers with clean metadata, consistent authentication, and stable endpoints. Fragmented infrastructure where the same API exists on three gateways with three different auth configurations cannot be reliably exposed to AI agents. A unified control plane with a MCP Gateway converts any cataloged API into an agent-callable tool in one click, with governance policies applied automatically.

4. What are the main security risks of a fragmented multi-gateway stack?

‍Three are consistently documented: shadow APIs (undocumented endpoints created without IT oversight, running without authentication or rate limiting), zombie APIs (deprecated endpoints still receiving traffic through outdated policies), and governance gaps (security policies applied inconsistently because each gateway has its own enforcement model). 31% of cyberattacks on transactional systems exploit undocumented APIs.

5. How long does it take to unify a multi-gateway API estate?

‍DigitalAPI indexes a connected gateway's full API catalog in under 24 hours. The pilot connecting one gateway, surfacing the catalog, and deploying a developer portal takes three days. Full multi-gateway unification, including governance policy migration and developer portal rollout across all connected systems, typically takes two to six weeks depending on the number of gateways and the complexity of the existing policy structure.