How to Detect Zombie APIs: Zero Traffic Doesn’t Always Mean Dead

TL;DR

A zombie API is an API that is still deployed but has had no consumer traffic for 90 days. You detect zombie APIs by connecting every gateway's traffic data, checking each API's last call against a 90-day window and confirming with the owner before you retire anything.

An API with no traffic data is not a zombie. It's unknown. Mark it unknown, find out why you can't see it, and only then decide whether it's dead.

Count the APIs on your gateways. Then count how many of them you can prove were called in the last 90 days.

Most teams find the second number is smaller than they expected, and not only because some APIs are unused. Some are unused. Others are simply invisible. This guide shows you how to tell zombie APIs from APIs you can't see, and how to retire the real zombies safely.

What is a zombie API?

A zombie API is an API that is still deployed, and often still billed, but has had no consumer traffic for a set period, usually 90 days. It was registered and documented properly at some point. Then its consumers moved on, and nobody switched it off. It keeps running, keeps costing money and keeps exposing an endpoint nobody watches.

Zombie APIs are a recognized problem. In Salt Security's 2024 State of API Security report, 70% of respondents rated zombie APIs a great or strong concern, up from 54% in 2023.

Zombie vs shadow vs deprecated APIs: what's the difference?

A zombie API is known but unused, a shadow API is used but unknown, and a deprecated API is known, possibly still used and formally on its way out. The difference decides what you do next. You retire a zombie, register a shadow API and migrate the consumers of a deprecated one.

For more on the second column, see our guide to shadow APIs.

Why do zombie APIs matter?

Zombie APIs matter because they cost money and widen your attack surface while delivering nothing. Each one takes gateway capacity, hosting and sometimes license fees. It also keeps old auth rules, old dependencies and unpatched code reachable from the network.

• Cost: Gateway calls may be zero, but compute, hosting and per-API license costs keep running.
• Security: Old endpoints often miss newer auth and validation rules, and nobody monitors them.
• Audit findings: Auditors ask why an API with no owner and no traffic is still reachable.
• Noise: Every zombie makes your inventory harder to read and your catalog harder to trust.

Scale makes this worse. Akamai's 2026 API Security Impact Study puts the median enterprise at more than 5,900 APIs. Even a small zombie share at that scale means hundreds of endpoints running for no one.

How do you detect zombie APIs?

You detect zombie APIs in five steps: list every API, connect traffic data for each one, apply a 90-day window, check the edge cases and confirm with the owner. The detection itself is a simple query. The hard part is making sure the traffic data is complete, so you don't flag an API you can't see.

1. List every API: Pull APIs from every gateway, plus specs from Git. Our guide to building an API inventory covers this step.
2. Connect traffic data for each API: Link each API to the gateway analytics, logs or metrics that record its calls. Note any API with no traffic source.
3. Apply a 90-day window: Find every API with zero consumer calls in the last 90 days. These are zombie candidates.
4. Check the edge cases: Exclude health checks and monitoring pings from the count. Look for quarterly, yearly and disaster-recovery callers.
5. Confirm with the owner: Ask the API's owner whether anything still depends on it before you start retirement.

Step 2 is where most detection goes wrong. If an API has no traffic source, step 3 will report zero calls, and you'll flag it as a zombie when you simply can't see it.

What is the 90-day rule, and why 90 days?

The 90-day rule says an API with no consumer traffic for 90 days is a zombie candidate. Ninety days is long enough to catch monthly and most quarterly callers, and short enough that dead APIs don't run for a year before anyone notices.

• Shorter windows, such as 30 days, flag false zombies: Month-end and quarter-end jobs look dead between runs.
• Longer windows, such as 365 days, leave real zombies running: You pay for a year before you act.
• 90 days is a candidate, not a verdict: Yearly jobs, such as annual reporting or tax-season APIs, still need the owner check in step 5.

Adjust the window for APIs you know run on a longer cycle. Write the exception down, so the next person doesn't flag the same API.

Why is "unknown" not the same as "dead"?

An API is unknown, not dead, when you don't have the traffic data to judge it. Zero calls in your dashboard can mean nobody called the API. It can also mean the calls happened somewhere your dashboard doesn't look. Treating both as "dead" is how teams retire APIs that still matter.

Common reasons an API ends up unknown:

• No traffic source: The API's gateway isn't connected to analytics, or its logs aren't collected.
• Traffic that bypasses the gateway: Internal services call the backend directly, so the gateway sees nothing. The Thales API Threat Report for the first half of 2025 reports that organizations typically have 10–20% more active APIs than they are aware of. Traffic that skips the gateway is one way an API stays out of sight.
• Not enough history: The API is newer than 90 days, or your metrics retention is shorter than 90 days.

Unknown is an honest answer. It turns a risky deletion into a fixable data gap. Fixing the unknowns is often as much work as retiring the zombies.

How do you retire a zombie API safely?

You retire a zombie API safely by announcing the change, reducing access in stages and keeping a way back until you're sure nothing breaks. Retiring quietly is what turns a zombie into an outage. A staged retirement takes a few weeks and costs little.

1. Confirm the zombie: Recheck traffic, and get the owner's sign-off.
2. Mark it deprecated: Add a Deprecation header (RFC 9745) and update the catalog.
3. Set a sunset date: Add a Sunset header (RFC 8594) with the retirement date, and tell known consumers.
4. Run a brownout: Return errors for short, announced periods, so hidden callers show up.
5. Retire it: Remove the route and return 410 Gone for a while, so late callers get a clear answer.
6. Clean up: Remove the backend, credentials and catalog entry, and record the cost saved.

This is right for you if you run APIs on more than one gateway, your inventory includes APIs nobody owns, or you pay per API or per gateway instance.

This is not right for you if you have a handful of APIs on one gateway with full logging. A quarterly manual review is enough at that size.

How does DigitalAPI flag zombie and unknown APIs?

Teams using DigitalAPI see zombie and unknown APIs across every gateway they run in one view, so they retire the dead APIs and fix the blind spots instead of guessing. It applies the 90-day rule to the traffic data from your connected gateways. Any API whose traffic it can't measure is marked unknown, not zombie.

• One estate across gateways: Zombie checks cover APIs on Apigee, Kong, AWS, Azure and other connected gateways, not one gateway at a time.
• The 90-day rule: APIs still deployed with no consumer traffic for 90 days are flagged as zombie candidates.
• Unknown, not dead: APIs without measurable traffic are marked unknown, so a blind spot never looks like a deletion candidate.
• Off by default: You switch zombie detection on when you choose to.
• Part of sprawl reduction: Flagged APIs feed the same workflow you use to cut duplicates and unowned APIs. See API sprawl for the wider picture.

See how many of your APIs are zombies, and how many you can't see: book a DigitalAPI demo.

Zombie API FAQs

What is a zombie API?

A zombie API is an API that is still deployed but has had no consumer traffic for a defined period, usually 90 days. It keeps costing money and stays reachable on the network, but nothing depends on it. It should be confirmed with its owner and then retired.

How long before an API counts as a zombie?

Most teams use a 90-day window. It's long enough to catch monthly and most quarterly callers, and short enough to stop dead APIs running for a year. APIs with yearly callers, such as annual reporting, need a longer window or an owner check before retirement.

Is a zombie API the same as a deprecated API?

No. A deprecated API is formally scheduled for retirement and may still have consumers who need to migrate. A zombie API has no consumers at all, but nobody has scheduled its retirement. A zombie should be deprecated, given a sunset date and then retired.

What is the difference between a zombie API and a shadow API?

A zombie API is registered in your inventory but receives no traffic. A shadow API receives traffic but was never registered, documented or reviewed. You retire zombies and register shadow APIs, so mixing them up leads to the wrong action.

Why would an API be marked unknown instead of zombie?

An API is marked unknown when there isn't enough traffic data to judge it. Common reasons include no analytics on its gateway, traffic that bypasses the gateway, an API newer than 90 days or metrics retention shorter than 90 days. Fix the data gap before deciding the API is dead.

How do you safely decommission an API?

Confirm it has no consumers, mark it deprecated with a Deprecation header, announce a sunset date with a Sunset header, run short brownouts to surface hidden callers, then remove it and return 410 Gone. Finally, remove its backend, credentials and catalog entry.

Final word

A zombie API is a cost you can remove. An unknown API is a question you can answer. The mistake is treating them as the same thing. Measure first, mark what you can't see as unknown, and retire only what you can prove is dead.

If you run APIs across several gateways and want to know which are dead and which are invisible, see how DigitalAPI flags both.