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

We’ve all seen the following stack before. Some of us have helped architect it, and most of us have inherited it:

• Postman for API design and testing
• Backstage for the developer portal and catalog
• Multiple API gateways: Apigee, Kong, AWS API Gateway, Mulesoft, IBM, Azure
• Monitoring is split across Datadog, New Relic, and Splunk
• Documentation scattered across Confluence, Notion, and GitBook

Individually, each tool is best-in-class, and each team uses the “right tool for the job.”

But are these tools actually designed to work together at scale? 

When do things break within the API stack? 

The most commonly used API stack is becoming a nightmare for large orgs only because these tools were never built to work together at enterprise scale.

Here’s what I have seen across the board:

1. Fragmented tools create workflow challenges

Postman helps devs design and test APIs, backstage catalogs them, and gateways enforce runtime. But none of the systems talk to each other natively. 

Each platform needs custom glue code or plugins.

And the result? Duplicate metadata, repeated work, and conflicting lifecycle states. 

Your APIs live in 5 tools. And no one knows which one’s the source of truth.

2. Backstage is a Product, not a Portal

Let’s talk about Backstage. 

It is a powerful tool, but scaling it means you’re now building and maintaining internal plugins for every gateway you use.

It becomes someone’s full-time job.

What was supposed to simplify the dev experience now needs a DevOps team of its own.

3. API Lifecycle becomes inconsistent

The APIs are designed in Postman, deployed in Apigee, published in Backstage, and documented in Confluence.  

Now imagine you have 2000 APIs.

No one knows what’s deprecated, what’s live, or what’s secure anymore. And that’s how the API lifecycle is disrupted, and you lose trust from both developers and leadership.

4. Zero governance across runtimes

Each gateway has its own policies, SLAs, and access controls. Developers don’t know if they can reuse an API, whether it's compliant, or if it even exists in production.
This leads to:

• Shadow APIs
• Duplicate endpoints
• Or worse, zombie APIs still exposing data
  

5. Dev Experience Gets Diluted

APIs feel different across platforms. Auth flows vary, SDKs behave differently, and docs are inconsistent. So developers do what they always do when things get messy: They rebuild.

And now you have ten different APIs to do the same thing, and it leads to API duplication.

Why can't integration platforms cannot fix this? 

iPaaS to the rescue? Some teams try patching this with integration platforms. But all that does is add more layers.

You still need custom connectors and unified governance. Patchwork will just make the problem even worse as opposed to solving it.

Why doesn't standardising across one gateway work?

I have heard this potential solution by a lot of tech leaders: “Why not just move everything to X gateway?” 

But it is not as ideal as it might sound.

• You have regulatory mandates (some teams must use certain platforms)
• You’ve acquired companies with their own stacks
• Migration costs can cross $10M+
• And frankly? Best-of-breed exists for a reason

So what's the solution?

I firmly believe that adding more tools to the landscape will not solve this problem.

What is needed is an intelligence layer that sits above your existing stack.

One that lets you:

• Discover every API across every gateway
• Automatically catalogue, version, and document them
• Apply policies consistently, no matter where they live
• Give developers a unified experience
• And make those APIs instantly consumable by AI agents

This is what we’ve been building at DigitalAPI.ai.

We don't ask you to rip anything out; we unify what’s already there.
And we do it with:

• Native multi-platform support (Apigee, Kong, AWS, Azure, Mulesoft… all covered)
• AI-ready design (your APIs become self-serve for AI agents out of the box)
• Governance that scales
• And pricing that doesn’t balloon with team size

This is more important than ever because AI agents are here, and most enterprise APIs aren’t ready.

Agents will not be able to function with APIs fragmented across platforms, slow onboarding, and broken governance.

If this sounds relevant to you, I would love to connect for a quick call to understand the context better.