A playbook from API Evangelist & Ryan Geftman-Gold
How universities can use web APIs to get research out of the journal and into the world, and how what the world does with it can come back to strengthen the research.
This page comes out of a conversation between Ryan Geftman-Gold and me, Kin Lane, about how much brilliant work inside universities never reaches the people who could use it. A university is an industrial research lab: full of scientists, PhDs and sometimes Nobel laureates. Too often the work stops at publication, because publishing is what academia rewards.
Web APIs are how nearly every technology of this century reaches people. They're how payments, messaging, maps, commerce and AI got into the apps we use every day. The same approach can take a research group's data, models and tools and make them available to other researchers, companies, developers and communities.
This playbook lays out five stages for doing that: assess what you have, pilot a first API, scale it to a community, sustain it as a dependable service, and build the feedback loops that bring real-world use back to the research. It's a living document, and it's open and forkable on GitHub. Each assessment we do will improve it.
An API isn't rocket science. It's the web, serving JSON instead of HTML, so software can read it as easily as people read a web page. Universities already run on APIs: library systems, student information systems, learning management systems, research computing, and now AI.
The private sector shows what happens when valuable capabilities become APIs. Stripe made payments something any developer could add in an afternoon. Twilio did the same for phone and text messaging. Salesforce, eBay and Facebook grew whole ecosystems of partners by opening their platforms. Research data and methods can work the same way.
Plenty of research infrastructure already works this way. Researchers use these APIs every day:
Universities publish APIs too. These are some of the university API portals I track on API Evangelist:
The Census Bureau story shows what's possible. When I first talked with them in 2011, they wouldn't do an API: it was census data, and they couldn't put opinions on it. But plenty of people were already downloading the data and using it, and the Bureau had no way to hear from them. When they finally launched an API, they found a long tail of users doing interesting things, and that feedback changed how they ran the census. I wrote about it at the time in How Will The US Census Bureau API Influence the 2020 Census?
Research moves from discovery to real-world impact in stages, and so does an API. The stages connect, and they aren't strictly in order: what you learn at the end loops back to the beginning.
| Stage | The question | What it produces |
|---|---|---|
| 1. Assess | What do you have, and who could use it? | An inventory, constraints, and likely audiences |
| 2. Pilot | Can a few trusted users get value from it? | A first API design and a small pilot |
| 3. Scale | Can many people use it without help? | Docs, onboarding, SDKs, discoverability |
| 4. Sustain | Can people build on it with confidence? | Plans, licensing, versioning, support |
| 5. Feedback & impact | What is the world teaching the research? | Usage signals, partnerships, evidence of impact |
Anyone working in health research will recognize the arc: it follows the movement from discovery to implementation to community impact. This playbook uses plain stages so any discipline can use it, including engineering, the sciences, the social sciences and the humanities.
Stage 1
Before designing anything, understand the research assets and who could use them.
Every research group has more than its papers: datasets, measurement instruments, models, code, reference tables, protocols and expertise. The assessment inventories them, then asks the practical questions: what format are they in, how big are they, who owns them, how are they licensed, and how sensitive are they (personal information, IRB constraints, embargoes)?
Next comes the outward-facing question: who uses this today, and who would use it if they could? Take a nutrition research dataset. Its likely users include other labs, clinicians, food manufacturers, grocery and meal-planning apps, digital health companies, and people building tools for themselves. Much research software and data still ships only as downloads or desktop applications, "without an API," which keeps most of those people out.
I map what you have against the API providers I track on APIs.io. That shows which existing APIs your work complements, and which communities are already looking for something like it.
Stage 2
Start small, with trusted users, and learn before you scale.
The assessment becomes a design: the resources the API exposes, the vocabulary that describes them, and a machine-readable contract (OpenAPI) that people and software can both read. The first version should be modest. Read-only, openly licensed data is the easiest place to start.
An API doesn't have to start as infrastructure. It can be as simple as a well-structured JSON or CSV file published on GitHub, with notes on what it is and how to use it. Pilot it with a handful of trusted users, like a partner lab, a class or one outside collaborator, and watch what they do with it.
Safety belongs here, not as an afterthought: de-identification, consent, review-board approvals, access controls and rate limits.
Stage 3
Make it work for many people who will never meet you.
Once a pilot works, the job is to make the API easy for strangers to use. That means a simple landing page or portal, clear documentation, a getting-started guide, working examples, client libraries in the languages your audience uses, and integrations with the tools they already have.
It doesn't matter how you make a pass, as long as it's easy for the receiver to catch. Your users shouldn't have to become experts in your field to benefit from your work. Make it discoverable too, by people searching the web and by AI agents. Machine-readable descriptions, an llms.txt file and listings in API catalogs all help.
Measure what matters: who signs up, what they call, and what they build.
Stage 4
Turn a project into a dependable service people can build on.
People only build on what they can count on. This stage defines plans and access tiers, rate limits, licensing and terms, versioning, and how changes and retirements will be communicated. A common pattern is free access for research and education, with commercial terms for companies building products.
Done well, revenue and partnerships sustain the research rather than distract from it. They can fund maintenance, students and new work, and they put the research inside products used in clinics, classrooms, stores and homes.
Stage 5
What an API community gives back to the researchers who steward the data.
This is the stage that matters most to researchers. An API creates feedback loops a publication never will. Partners, other institutions, companies and developers ask for things, report problems, combine your work with other sources, and show you uses you never imagined.
That feedback lets the core research iterate and evolve to meet the needs of specific markets and communities. It connects researchers who would never otherwise meet, across departments, campuses and institutions. And it produces evidence of real-world impact that funders, administrators and policymakers can see.
Then it loops back to the beginning: what you learn here shapes the next assessment.
This playbook will be built in the open and will change with every assessment. When an institution agrees, we'll add worked examples of what we found, what we built, and what happened next. The goal is a playbook any university can fork and use.
This playbook is forkable. The whole page lives in a public GitHub repository at github.com/api-evangelist/academic-research. Fork it to adapt the stages for your own institution, or open an issue or pull request to suggest improvements.
If your group has research data, content or tools that deserve a wider audience, I'd like to hear about it. We'll start by assessing what you have.
Last updated November 4, 2026.