No one owns the API graveyard. No process retires what was never officially buried.
Five root causes that let APIs accumulate unsecured versions and forgotten surfaces.
❌
No authoritative API inventory
No system of record that lists every deployed API, version, environment, and endpoint. Without an inventory, you can’t know what to retire, what to audit, or what to monitor. What isn’t tracked isn’t managed.
❌
No formal deprecation process
Launching a new version is a project. Retiring an old one is “we should do that sometime.” Without a process — sunset date, consumer notification, traffic monitoring, shutdown procedure — old versions accumulate indefinitely. A “deprecated” label in the docs means nothing if the endpoint still responds.
❌
Security updates applied only to current versions
When a vulnerability is patched, the patch is applied to the current supported version. Old versions — especially in large organizations where different teams maintain different versions — may not receive the patch. The old version becomes permanently vulnerable.
❌
Cloud infrastructure makes sprawl cheap and invisible
Spinning up a new environment in the cloud takes minutes and costs pennies per hour. Forgetting to shut it down is equally easy. Cloud accounts accumulate environments from past projects, migrations, and demos that remain live and internet-accessible indefinitely.
❌
Documentation is written at launch, not maintained after
API documentation reflects what was built initially. Internal-only endpoints, workarounds added during incidents, and test utilities added during development are never documented — and therefore never reviewed, audited, or removed.