Git, and specifically GitHub, is the factory floor of modern API operations, and I’ve believed this longer and more insistently than almost anything else in my work. Git is version control — a distributed system for tracking changes to files over time — but in the API world it has become much more: the place where API definitions live, where they’re versioned, where changes are proposed and reviewed, where the lifecycle is orchestrated, and where the source of truth resides. I declared GitHub the API lifecycle engine back in 2016, and everything since has only deepened that conviction. When I say Git is the source of truth for API operations, I mean it literally: the OpenAPI definition committed to a Git repository, with its full history of changes attributed and timestamped, is the authoritative record of what an API is and how it has evolved. Git is where API truth lives.
The insight started early, with the recognition that GitHub was becoming central to how the API community actually worked. I wrote in 2011 that GitHub says if there’s an app, there’s an API — capturing how GitHub itself embodied the API-driven, open, collaborative ethos. By 2012 I was writing about open-sourcing your API with GitHub, managing your terms of service and documentation there, doing issue management there. By 2014 I was describing GitHub as the central presence, definition, configuration, and source code for your API — all of it, in one place, version-controlled. The progression was clear: GitHub wasn’t just where you stored code, it was becoming the operational hub where every artifact of an API program could live, version, and collaborate. The 2016 framing of GitHub as the API lifecycle engine was the culmination — the recognition that you could run an entire API program’s lifecycle through GitHub’s repositories, branches, pull requests, issues, and Actions.
The principle I distilled this into is that every API should begin with a GitHub repository, which I wrote in 2017. The repository is the seed of the whole operation: the OpenAPI definition goes there, the documentation generates from there, the tests run from there, the SDKs publish from there, the issues and feedback collect there, the changes get reviewed there. Starting an API with a Git repository means starting it with version control, collaboration, provenance, and a single source of truth built in from the first commit. This is the opposite of the ad-hoc approach where an API’s definition lives in some tool, its docs in another, its code in a third, with no shared history or truth. The Git-first approach makes the repository the spine of the API, and everything else hangs off it.
Managing OpenAPI definitions in Git is where the discipline becomes concrete and where the best providers demonstrate the practice. I documented how the New York Times, Stripe, SendGrid, and Nexmo all manage their OpenAPI definitions in public GitHub repositories — treating their API contracts as version-controlled source code, accepting pull requests, maintaining change history. I wrote in 2019 about managing your API definitions on GitHub as a core practice, and savvy providers, I noted, would even submit pull requests to update their own OpenAPI specs in my research repos. The discipline of keeping your API definition in Git means every change to your contract is reviewed, attributed, and traceable, which is exactly the governance and provenance that ad-hoc definition management lacks. The definition in Git is the definition you can trust, because you can see its entire history and who changed what.
GitHub as discovery infrastructure is an underappreciated dimension I leaned into hard. I wrote about using GitHub as an API index and data store, and about the growing importance of GitHub topics for API SEO. Because so many providers publish their OpenAPI definitions and developer content to GitHub, GitHub became one of the most important places to discover APIs — searching repos for evidence of API truth, using topics to categorize and find API-related projects. GitHub is simultaneously where APIs are built and where they can be found, which makes it both the factory floor and part of the discovery layer. The same repositories that hold the source of truth are crawlable, searchable, indexable evidence of what APIs exist and how they work.
The GitOps maturation brought all of this into a coherent modern practice, and it’s where my recent thinking lives. I wrote in 2024 about GitOps-driven API source of truth and about the digital API factory floor — the recognition that Git isn’t just where artifacts are stored but is the operational engine through which the whole API supply chain runs. In the GitOps model, Git is the source of truth and the trigger: a change committed to the repository drives the pipeline — validates the definition, runs the tests, generates the docs, deploys the gateway configuration. The repository state is the desired state, and the tooling reconciles reality to match it. This is the API lifecycle engine vision fully realized: Git as the declarative center of API operations, with provenance built in because every change is a commit. Even the modern API clients reflect this — Git is how you run in Bruno, with collections living in Git repositories rather than cloud workspaces, which is the same instinct applied to the consuming side.
The deeper significance, the one I keep coming back to, is that Git gives API operations the things they most need: provenance, collaboration, and truth. I argued in 2021 that Postman would do for APIs what GitHub did for open source — become the collaboration platform where the work happens — but the underlying point is that the GitHub model itself, version control plus collaboration plus open visibility, is what API operations needed all along. Git provides provenance because every change is attributed and timestamped. It provides collaboration because pull requests and reviews are how teams agree on changes. And it provides a single source of truth because the repository is the authoritative record. These are exactly the properties that distinguish governed, trustworthy API operations from ad-hoc ones. The factory floor metaphor is the right one: Git is where the actual work of producing, versioning, reviewing, and shipping API artifacts happens, and an API program that runs on Git has a foundation of provenance and truth that an API program scattered across disconnected tools can never match.
References
- GitHub Says, If There Is An App, There Is An API
- Open Source Your API With GitHub
- GitHub As The Central Presence, Definition, Configuration, And Source Code For Your API
- GitHub As The API Life Cycle Engine
- Using GitHub As An API Index And Data Store
- Every API Should Begin With A GitHub Repository
- The Growing Importance Of GitHub Topics For Your API SEO
- Managing Your API Definitions On GitHub
- Postman Will Do For APIs What GitHub Did For Open Source
- The Digital API Factory Floor
- GitOps-Driven API Source Of Truth
- Git Is How You Run In Bruno
