Most organisations treat their API inventory as a static document rather than a dynamic reflection of reality.  

Many believe their inventory is simply the collection of OpenAPI or Swagger files stored in a repository, or perhaps a manually curated list on a Confluence page. 

This mindset is fundamentally flawed. It reflects a point-in-time fantasy, not what’s actually running. 

In modern environments with CI/CD, microservices, and serverless functions, new endpoints are deployed, changed, and decommissioned every day.  

The inventory becomes outdated the moment it’s written. The core mistake is assuming documentation is the source of truth.  

In reality, the only source of truth is the traffic flowing through your network and most organisations aren’t equipped to continuously monitor and reconcile that with their documentation. 

 The audit surprise 

Audits are a classic trigger. An auditor will ask for a data flow diagram for a specific business process, and in the scramble to produce it, teams often uncover forgotten services that are still part of the chain.  

Incidents are another common catalyst. 

I recall a case where a business was dealing with a database performance issue. While tracing the source of excessive queries, the engineering team discovered a high-volume, unauthenticated internal API that was hammering a production database.  

It turned out this API was built for a one-off data migration years ago and was never switched off. It wasn’t just a performance drain; it was a critical security vulnerability waiting to be exploited, and it was completely absent from their inventory.  

Why You Can’t See the Risk 

Hybrid and multi-cloud architectures fragment visibility, making certain risks incredibly difficult to spot with traditional tools. The most dangerous are:  

• East-West Traffic: 
  Communication between services, often across different VPCs or 0cloud providers. Most security tools focus on North-South traffic (user to the application), leaving these internal data flows unmonitored. This is where a seemingly low-risk shadow API can become critical by accessing a privileged internal service. 

• Hidden Outbound Data Flows:
  Many applications rely on third-party APIs for things like payments or enrichment. The risk lies in what data is being sent. We’ve seen developers pass entire user objects to third parties, when only a single, non-sensitive field was needed. This kind of data leak quietly expands your compliance boundary.
• Ephemeral Endpoints
  With serverless architectures like AWS Lambda or Azure Functions, APIs can be created and destroyed in minutes. These short-lived endpoints are nearly impossible to track with manual inventories, yet they represent real, and often overlooked, risks. 

Why This Is So Hard for Engineering Teams 

Data classification and flow mapping typically fall outside an engineer’s responsibilities and tooling.

A developer might have deep context on the data within their microservice, but limited or no visibility into the broader data journey. They can’t map a flow they can’t see. 

It’s also a tedious, manual process. There’s no git commit that automatically flags a new field as PII. It requires domain expertise and regulatory knowledge, skills that are rarely part of the core engineering toolkit.

In a fast-moving DevOps culture, where the priority is to ship, this process is seen as friction. Often, it’s done inconsistently or skipped entirely. 

This is both a cultural and tooling gap. 

 So what actually works? 

The answer isn’t another dashboard. It’s a shift in mindset from documentation-first to evidence-first. 

The first step is establishing a ground truth by observing live traffic. And you don’t need to start with another complex tool.

Analyse logs from systems you already have: API gateways, service mesh proxies, cloud provider flow logs. The key is knowing what to look for and how to make sense of it. 

From there, the next step is automation. Build processes that continuously compare live traffic with declared API specs, automatically flagging mismatches.

It turns the inventory into what it should be: a living, breathing system.

If you need help uncovering your hidden APIs and want to talk, get in touch with us here.

The single most useful thing I find when working with teams is however to get them to realise that an API inventory is not a noun. It’s a verb. 

You can’t treat it as a static list you create once a year for an audit. It’s a continuous process of discovery, classification, and governance that must be embedded into your operations.