Government is where I did some of the most meaningful API work of my career, and the history of government APIs is one of the most important and most overlooked chapters in the whole API story. Government APIs matter because they’re about public resources, public accountability, and public participation — the data and services that citizens have a right to access and that democracy depends on being transparent. I spent years deeply embedded in the government API space, even serving as a Presidential Innovation Fellow, and what I learned is that government is simultaneously one of the most promising and one of the most frustrating arenas for APIs. The promise is enormous: APIs can make government more transparent, more efficient, more participatory, and more accountable. The frustration is that government moves slowly, struggles with procurement and talent, and too often treats APIs as a checkbox rather than a genuine transformation.
The open data era was the beginning, and Data.gov was its centerpiece. In the early years, around 2011, the government API story was really an open data story — Data.gov, the Federal Register API, Socrata-powered open data portals, and the broader push to liberate government data and make it accessible. I did grassroots evangelism to bring awareness to Data.gov, and I argued that every city, county, and state should have an API, because the case for public data being programmatically accessible was so clear. This early period established the principle that government data is a public asset that should be open and accessible, and APIs were the mechanism for delivering on that principle. The open data movement gave government APIs their initial moral and political foundation: this is the people’s data, and it should be available to the people.
The Obama directive was the watershed moment, and I documented it as it happened. In 2012, the Obama administration directed all federal agencies to have an API as part of the Digital Government Strategy — a genuinely historic mandate that made APIs official federal policy. I tracked the agencies’ progress closely: 146 planned APIs across 19 federal departments, the digital strategy documents, the data.json files agencies were required to publish. This was the high-water mark of top-down government API ambition — a presidential directive treating APIs as essential infrastructure for a modern, transparent, efficient government. The Digital Government Strategy put APIs at the center of how the federal government was supposed to deliver services and open its data, and for a period it looked like government might lead rather than follow on API adoption.
The We the People API and the write-API frontier was where government APIs got genuinely innovative. I wrote in 2014 about the significance of the We the People API being the first modern read-write web API in government — because most government APIs were read-only, just exposing data, while We the People let citizens actually write to government, submitting and signing petitions programmatically. That read-write capability was the technical expression of democratic participation, and 18F was pushing hard to make write APIs in government a reality. This was the vision at its most exciting: government APIs not just as transparency tools but as participation tools, letting citizens interact with their government programmatically. OpenFDA, which launched in 2014, was another landmark — a genuinely well-executed federal API that I praised not just for the technology but for how it was launched, with real attention to developer experience and community.
The institutional infrastructure that grew up around government APIs was substantial, and I was part of it. 18F and the U.S. Digital Service brought modern technology practices into government, the GSA developed API standards, and the Presidential Innovation Fellows program — which I participated in — brought outside technologists into agencies to push digital transformation. I watched the speed of government change when it ran on GitHub, saw agencies adopt the OpenAPI specification, and worked on applying APIs.json to government API discovery. This was a real movement with real institutions behind it, and it produced genuine results — modern developer portals, well-designed APIs, and a cohort of people inside government who understood and championed APIs. The infrastructure mattered because it meant government API adoption wasn’t just a directive but had people and institutions working to make it real.
The healthcare and regulated-interoperability chapter is where government APIs matured into something with legal force. The VA’s Lighthouse platform, which I was deeply involved in advising, was one of the most significant government API efforts — modernizing how the Department of Veterans Affairs exposed its capabilities, with serious attention to the API lifecycle, developer outreach, and the path to production. The CMS Blue Button API gave Medicare beneficiaries programmatic access to their own claims data. And in 2020, HHS and CMS finalized rules mandating that healthcare providers and insurers expose APIs to give patients control of their health data — government using APIs not as a nice-to-have but as a legal mandate, a regulated interoperability requirement. This is the evolution of the government API story: from voluntary open data, to presidential directive, to legally mandated interoperability where APIs become the required mechanism for delivering rights and access.
The honest assessment, which I’ve never shied away from, is that government APIs have been a story of both real achievement and persistent struggle. The achievements are real: Data.gov, the Obama directive, We the People, OpenFDA, the VA Lighthouse, the healthcare interoperability mandates, and a generation of public servants who get APIs. But the struggles are equally real: government APIs are often unreliable, poorly maintained, under-resourced, and vulnerable to political shifts — I worried openly about what would happen to federal API efforts across administration changes. Government moves slowly, procurement is broken, talent is hard to retain, and too many government APIs launch with fanfare and then languish. My recent roundups of federal agency APIs show a landscape that’s still patchy and inconsistent more than a decade after the Obama directive. The government API story is ultimately a story about whether the public sector can sustain the long, unglamorous work of treating APIs as essential public infrastructure — and the answer, so far, is mixed. But the stakes are high enough, and the achievements real enough, that it remains some of the most important API work there is. Public data and public services delivered through well-governed APIs is a genuine democratic good, and that’s worth the struggle.
References
- Every City, County, And State Should Have An API
- Government Opened Data Via APIs In 2011
- Barack Obama Directs All Federal Agencies To Have An API
- 146 Planned APIs From 19 Federal Depts And Agencies As Part Of Their Digital Strategy
- My First Day In Washington DC As Presidential Innovation Fellow
- 18F Shows What Is Possible In Government With FBOpen API
- Significance Of The We The People API Being First Modern Read-Write Web API In Government
- Another Strong API Implementation In Federal Government With OpenFDA
- State Of APIs In The Federal Government
- Why I Feel The Department Of Veterans Affairs API Effort Is So Significant
- HHS And CMS Finalizes Rules To Provide Patients More Control Of Their Health Data Using APIs
- A Roundup Of US Federal Agencies And Their APIs
