An old program can contain a perfectly readable API call that nobody can confidently explain anymore.
That is what makes vanished developer documentation different from ordinary link rot. The code may survive. The function name may survive. Somebody may even have a working binary. What disappears is the contract around the interface: accepted parameters, return values, authentication rules, rate limits, version differences, error behavior, and examples showing how the designers expected it to be used.
API documentation can disappear by policy, not accident. Square’s API lifecycle documentation says retired APIs are removed from current developer documentation on or after retirement, although older API-reference versions may still retain information. That is a rational maintenance policy for a live developer portal and a preservation problem for anyone trying to understand old integrations years later.
Code does not contain the whole interface
Suppose an old application calls a method named people.get. The source can show the endpoint and the fields the programmer happened to request. It may not tell you which fields were optional, which scopes authorized them, what happened when a profile was private, whether pagination existed, or which behavior changed between API versions.
Examples are equally important. Good API documentation records idioms that are not obvious from a method signature. It may warn that a value is deprecated, explain an ordering guarantee, define a timestamp format, or show the correct sequence for a multi-step operation.
A graceful retirement shows what should survive. When Wikimedia shut down its experimental API Portal in June 2026, it did not simply erase the documentation. The shutdown announcement said documentation would move to other Wikimedia technical-documentation sites while old API routes were deprecated gradually.
Version context is part of the archive
Wikimedia’s historical API Portal record goes further: it points readers to Wayback Machine snapshots and a downloadable database archive of the retired documentation wiki. That preserves not just today’s replacement instructions but evidence of how the old interface was described while it existed.
Useful preservation should include reference pages, guides, sample code, changelogs, migration notices, schema definitions, SDK documentation, and dates. The date matters because API documentation is often continuously edited. A capture from one version may describe behavior that was false in another.
The Wayback Machine can rescue documentation after a vendor removes it, but dynamic documentation sites can replay badly. Search boxes, JavaScript navigation, generated code samples, or version selectors may not survive a simple crawl. Saving static exports, schemas, SDK packages, example repositories, and migration notices alongside web captures gives future readers more than one route back in.
There is also a limit to what documentation can recover. Once the actual service is gone, a reference manual cannot reproduce undocumented server behavior, data, or authentication infrastructure. It can explain the machine, not resurrect it.
Still, that explanation matters. When API documentation disappears, software history loses the difference between “this old code is strange” and “this old code was correctly following a contract that no longer exists.”