The Archivist's Amnesia: How a 19th-Century Fire Brigade Created the First API
In the 1860s, London was a city held together by paper and rumor. Its telegraph wires hummed with private financial dispatches, but for the public, news travelled at the speed of a running boy. Into this gap stepped John Game, superintendent of the Metropolitan Fire Brigade. He faced a data problem of immense, tangible consequence: how do you know where a fire is, the instant it starts, without being there?
His solution, the Metropolitan Fire Brigade's telegraphic ‘fire alarm’ system, was a masterwork of open data principles, born a century before the term existed. Game convinced the city to install over forty ‘fire alarm pillars’ across the metropolis. These were not simple call boxes; they were endpoints. Each pillar contained a clockwork mechanism and a numbered code wheel. A citizen, spotting a blaze, would break the glass, turn the handle to their pillar's unique number, and release it. The system didn't transmit a voice or a written message—it transmitted pure, structured data.
A Protocol of Flames
That numbered signal shot down dedicated telegraph lines to a central station in Watling Street, where it tripped a bell and moved a needle on a dial to point at the pillar’s number. The watchman, consulting a single, canonical map, would translate that integer into a location: Pillar 27 = Corner of Chandos Street and Tottenham Court Road. He would then telegraph the horse-drawn engines stationed in that district. The entire chain, from citizen’s hand to galloping hooves, could take under two minutes. This was an API call and response: a public-facing interface (the pillar), a standardized request (the number), a centralized processor (the watchman and his map), and a structured action (dispatching a specific resource).
What fascinates me, however, is the archival ghost this system left—or rather, failed to leave. The data was supremely ephemeral. The bell stopped ringing, the needle reset, the engines rolled. The ‘request’ existed only as motion and sound, leaving no ledger of calls, no log of false alarms, no trace of the citizen’s initiating act. We have maps of the pillar locations and descriptions of the technology, but the vital flow—the daily, desperate pings of a city on fire—is lost. The system was built for real-time response, not for preservation. It was a perfect, self-erasing record.
In our era, we grapple with the opposite problem: preserving too much, saving every packet, every transient state. Game’s system asks a different, haunting question of digital archivists: what is the cost of a system designed only for the present tense? The fire alarms created a public utility of incredible efficiency, but they also enacted a kind of mandatory amnesia. The data served its immediate, lifesaving purpose and then vanished into the air, like smoke. It makes me wonder about our own APIs—the weather feeds, transit alerts, civic reporting tools. They are built for now. What story of our own emergencies and daily needs will be lost because it was never designed to be kept, only to be acted upon, instantly, and then forgotten?
John Game didn't think he was building an early digital protocol; he was just trying to put out fires faster. But in doing so, he created a stark lesson in the politics of data design. An open system can be brilliantly accessible and functionally transparent, yet still be a black box to history. The most elegant API might also be the most profound silencer.
Notes & further reading
A few pages I came back to while writing this: