The Transformation of APIs — When the Same Operation Changes Its Meaning

git push — a four-character command.
One day it delivers a book. Another day, it delivers a voice to the national archive.

The point of this essay: An API is nothing more than a technical specification. But when the intent of the person using it changes, the same API transforms into entirely different infrastructure. The publishing pipeline on zenn.dev and TokiStorage's National Diet Library deposit pipeline are technically near-identical operations. What changed was not the API. It was the will behind "what to deliver."

1. One Command, Two Meanings

# Publish a book on zenn.dev
$ git push origin main → Markdown is auto-built and delivered to readers
# Deliver a voice to the national archive via TokiStorage
$ git push origin main → A newsletter is auto-generated and delivered to the National Diet Library

The command is the same. git push origin main. The keystrokes are the same. The structure of the request received by GitHub's API is the same. The pattern of processing executed by the server is the same.

Yet one delivers a technical book to readers, and the other delivers a human voice to the nation's permanent archive.

The API hasn't changed. What changed is the intent of the person using it.

2. zenn.dev — When the API Was "Publishing Infrastructure"

zenn.dev is a digital publishing platform for Japanese developers. Authors write Markdown files in a GitHub repository and push. The zenn.dev pipeline automatically builds and publishes them as books.

Over 60 technical books were published through this system. Write, push, publish. This cycle repeated hundreds of times.

At this stage, the GitHub API was "publishing infrastructure." Push a manuscript and it becomes a book. Nothing more, nothing less. A convenient, reliable, fast publishing pipeline. The API's role ended there.

3. The Turning Point — A New Meaning Flows Through the Same Pipeline

When conceptualizing TokiStorage, a design problem emerged: "How do we record each customer's story, and how do we permanently preserve it?"

The answer was already at hand.

Through the same pipeline used hundreds of times on zenn.dev, instead of manuscripts, customer stories would flow. Auto-generated newsletters are pushed to a GitHub repository, and that repository is a collection target of the National Diet Library.

Technically, it's nearly the same operation. Generate Markdown, push to GitHub, auto-publish. But the "meaning" flowing through the pipeline is entirely different.

Through zenn.dev, knowledge flowed.
Through TokiStorage, existence flows.

4. APIs Don't Ask About Intent

The essence of an API is its neutrality toward intent.

The GitHub API does not distinguish whether the pushed data is a technical manuscript or a newsletter recording someone's voice. To the API, both are the same sequence of bytes. They arrive at the same endpoint, via the same HTTP method, with the same authentication token.

This neutrality is the source of an API's power.

If the GitHub API had been designed exclusively for "publications," TokiStorage's newsletter pipeline would never have been born. If it were "code only," zenn.dev's publishing pipeline would never have been born either.

Because APIs don't ask about intent, when the user's intent changes, the same infrastructure can be repurposed for entirely new objectives. The versatility of technology enables uses its designers never imagined.

5. What 60 Books Taught

Publishing over 60 books on zenn.dev was not mere "experience." It was training that inscribed the reliability of GitHub pipelines into the body.

Push and it arrives. It always arrives. Never once lost. Every change is recorded. Incorrect changes can be reverted. This conviction cannot be gained by reading specifications. It was absorbed through hundreds of repetitions.

This is precisely why, in designing TokiStorage, it was possible to decide: "entrust the permanent preservation of human voices to a GitHub pipeline." A pipeline that had never lost even a publication manuscript would now carry proof of human existence. What that decision required was not technical knowledge, but trust cultivated through repetition.

6. The Meaning of Infrastructure Is Decided by Its Users

Water pipes were designed to carry water. But what the water carries dissolved within it changes the meaning. Carry drinking water and it's residential infrastructure. Carry medicine and it's medical infrastructure. The pipes themselves haven't changed.

APIs are the same.

The GitHub API was designed to carry data. But flow technical manuscripts through it and it becomes publishing infrastructure. Flow human voices through it and it becomes proof-of-existence infrastructure. Flow customer stories through it and it becomes national archival infrastructure.

Technology is neutral. Meaning is given by humans.

The same API can serve publishing, proof of existence, and national records.
What changes is not the technology. It is the will behind "what it's used for."

7. Conclusion — What I Think Every Time I Push

git push origin main.

This command once existed to deliver technical books to readers. Now it also exists to deliver human voices to the nation's permanent archive.

The keystrokes haven't changed by a single character. What changed is the weight of the moment the Enter key is pressed.

The pipeline reliability cultivated through over 60 publications now supports the proof of existence of someone I've never met. Without those hundreds of pushes on zenn.dev, this trust would not exist. And without that trust, the decision to entrust human voices to an API could never have been made.

APIs do not transform. The will of the humans who use them transforms.
And that transformation turns technology from a tool into infrastructure.