Education

API education is a political question disguised as a technical one, and the longer I’ve done this work the more convinced I’ve become that who learns about APIs and who doesn’t is one of the quiet inequalities of the digital age. APIs are how data, money, and capability move through the modern economy. If you understand them, you can participate, build, automate, and exert leverage. If you don’t, you’re a passenger — subject to systems you can’t see, dependent on others to act on your behalf, excluded from a layer of power that increasingly governs everyday life. That’s why I’ve argued that API literacy is as important as financial literacy in the API economy. The comparison is deliberate and the stakes are the same: just as financial illiteracy keeps people locked out of economic agency, API illiteracy keeps people locked out of digital agency. Education is the mechanism that determines which side of that divide you land on, and it is therefore profoundly political.

The first and most important political claim I’ve made about education is that APIs are not just for developers. I wrote that in 2011, and I meant it as a deliberate challenge to the gatekeeping instinct of the technical community. The dominant assumption — then and now — is that APIs are an engineering concern, that you need to be a programmer to understand them, that the conversation belongs to developers. That assumption is itself an act of exclusion. It keeps business people, policymakers, journalists, educators, and ordinary citizens out of a conversation that affects them enormously. My whole evangelism project was built on the conviction that the API conversation needs to be accessible to far more people than the developers who write the code. When I made the Twitter API legible to non-developers, when I argued that business and IT leaders needed an “API kindergarten,” I was fighting the gatekeeping — insisting that the knowledge be democratized rather than hoarded by the technical priesthood.

This is why I invested so heavily in introductory, accessible education, and why I’m not embarrassed by how basic some of it was. I reworked my API 101 content repeatedly — the 100,000-foot view, the providing-APIs content, the consuming-APIs content — because the entry point matters enormously for who gets in. I called one body of work API Kindergarten, specifically for business and IT leaders, because I wanted material that assumed no technical background and carried no condescension. I wrote about using forms as an introduction to the world of APIs for “normals” — meeting non-technical people where they are, using a familiar interface as the on-ramp to understanding. I celebrated Zapier’s mission to educate everyone with an introduction to APIs, and IFTTT’s automation-for-the-masses, because these tools were doing the democratizing work of letting non-developers experience what APIs make possible without first having to learn to code. The politics of education is fundamentally about the on-ramp: a steep, jargon-heavy, developer-only on-ramp excludes; a gentle, accessible, multiple-entry-point on-ramp includes.

Where you go to learn about APIs has always been a revealing question, and the answer exposes the gaps. I wrote “where do I learn more about APIs?” in 2012 and was still writing “where do I go to learn about APIs?” in 2024 — twelve years apart, the same question, because the educational infrastructure never fully materialized. I looked at Codecademy’s API education, sketched out elements for online API education platforms, pointed people toward courses like the API usability course at Carnegie Mellon. But the honest reality across all those years is that API education remained fragmented, informal, and dependent on self-directed learning, blog posts, and scattered resources rather than coherent curricula. That fragmentation is itself political, because self-directed, informal learning advantages those who already have the time, the technical confidence, and the social networks to navigate it. The absence of structured, accessible API education isn’t neutral — it reproduces existing advantages, letting the already-connected get more connected while everyone else falls further behind.

Higher education was where I tried hardest to address this structurally, and where I saw both the promise and the institutional resistance most clearly. I did serious work on APIs in higher education — the University of API white paper, the studies of leading institutions like BYU with its hundreds of campus APIs, the case studies at the University of Oklahoma and elsewhere. I argued repeatedly that increasing the focus on APIs in higher education was important, because the university is where the next generation either gains API literacy or doesn’t. If API skills are taught in computer science programs but nowhere else, then API literacy becomes another credential that tracks existing privilege. If they’re taught broadly — to business students, policy students, journalism students, design students — then the literacy spreads across society more equitably. Cultivating the next generation of API design skills was, for me, partly a workforce concern but more deeply an equity concern: who gets these skills determines who gets the opportunities that flow from them.

The skills-and-credentialing dimension carries its own political weight, and I’ve thought about it carefully. I wrote about API badging and credentialing to demonstrate skills, and about thinking in terms of API skills rather than just API resources, because how we recognize and certify API knowledge shapes who gets access to API-related opportunity. Credentialing can democratize — a badge that lets someone without a traditional CS degree prove their API competence opens doors that a degree requirement would close. Or credentialing can gatekeep — a certification regime that’s expensive, exclusive, or biased reproduces the very inequalities it claims to address. The politics is in the design: education and credentialing systems can be built to include or to exclude, and that choice is rarely made consciously, which is exactly why it deserves scrutiny.

The chronic underinvestment in API education is a political failure as much as a market one, and I’ve named it as such repeatedly. I wrote in 2017 that your lack of investment in API education will be the end of your API service, and that API education is needed but rarely prioritized — and I wrote about heavier investment in API training being necessary because the knowledge gap was real and growing. But the underinvestment isn’t random; it reflects priorities. Companies invest in the producing side of APIs and skimp on educating consumers. The industry invests in tooling and skimps on literacy. Institutions invest in technical training for the already-technical and skimp on broad education for everyone else. Each of these choices concentrates API knowledge in fewer hands, and concentrated knowledge is concentrated power. When I plead for more investment in education, I’m not just making an adoption argument — I’m arguing against the concentration of a form of power that ought to be widely distributed.

The open educational resources thread is where the politics points toward a remedy, and it connects directly to my broader commons beliefs. I wrote in 2023 about open-source educational resources on modern APIs, because open educational materials are the antidote to the exclusionary dynamics of proprietary, expensive, or gatekept education. If the knowledge of how APIs work is held in open, freely accessible, reusable educational resources, then the on-ramp is open to anyone with curiosity and an internet connection, regardless of whether they can afford a bootcamp or attend the right university. API education as a commons — shared, open, freely available — is the political stance that the knowledge of how the digital economy works should belong to everyone, not just to those who can pay for access to it. That’s the same instinct that drove the API Commons and my public-data work, applied to knowledge itself.

The stakes are only rising as we move into the AI era, and the educational divide threatens to widen rather than close. APIs are now the substrate of how AI agents act in the world, which means understanding APIs is becoming a precondition for understanding and governing AI — and the gap between those who grasp this and those who don’t is becoming a gap in who can meaningfully participate in shaping the most important technology of the moment. The political urgency of API education is greater now than it has ever been, because the cost of exclusion is higher. My through-line across fifteen years has been consistent: the knowledge of how APIs work should be widely and equitably distributed, taught accessibly, made available as an open commons, and embedded broadly across education rather than hoarded by a technical elite. Education is where the politics of API access is either reproduced or interrupted. Who learns and who is excluded is not a side effect of how we teach APIs — it is the whole game, and treating it as a mere technical-training question is itself a way of avoiding the political reality that some people are being let in and others are being left out.

Guidance

API Learnings

APIs

API Governance

API Solutions

API Discovery

API Building Blocks

API Evangelist LLC

Education

References

Guidance Details

Explore more

Discover APIs