API Evangelist has spent a long time arguing that the machine-readable contract is the center of gravity for an API. OpenAPI for the request and response, JSON Schema for the shape of the data, AsyncAPI for the events. Every conversation about governance, discovery, testing, SDKs, and now agents runs back through those three specifications.
This quarter I got to check that argument against something other than my own conviction: what companies actually write into their job postings.
The Q3 2026 Insights pull read 343,299 job postings from 984 companies. 775 of those companies are in the Fortune 1000 and 209 are API providers from the APIs.io catalog. Every number below is a count of companies whose postings name the term at least once, not a count of mentions, so one company with a hundred API roles counts once.
The specifications are barely there
| companies | share of the 984 | |
|---|---|---|
| OpenAPI | 99 | 10.1% |
| Swagger | 79 | 8.0% |
| OpenAPI or Swagger | 116 | 11.8% |
| JSON Schema | 14 | 1.4% |
| AsyncAPI | 9 | 0.9% |
Ninety-nine companies. Of 343,299 postings, 259 say OpenAPI — less than one in a thousand. Fold Swagger back in, since plenty of people still call the specification by its old name, and you get to 116 companies, still under twelve percent.
JSON Schema is in the postings of fourteen companies. AsyncAPI is in nine.
What does show up
Put the same question to the technologies sitting around those specifications:
| companies | share of the 984 | |
|---|---|---|
| Apache Kafka | 334 | 33.9% |
| OAuth | 279 | 28.4% |
| GraphQL | 217 | 22.1% |
| Postman | 167 | 17.0% |
| gRPC | 139 | 14.1% |
| MuleSoft | 120 | 12.2% |
| OpenAPI | 99 | 10.1% |
| Apigee | 62 | 6.3% |
GraphQL is named by more than twice as many companies as OpenAPI. Postman, a tool that mostly works on OpenAPI, is named by more companies than the specification it reads. Kafka is in a third of them. And the event-driven work Kafka represents is exactly what AsyncAPI exists to describe, yet AsyncAPI is at nine companies.
When we read the postings that name OpenAPI to verify the count, it mostly turns up in a list: “testing tools such as Postman, SoapUI, Swagger, OpenAPI or similar”, “API documentation standards such as OpenAPI/Swagger”, “REST, OpenAPI, gRPC”. It shows up as a documentation format or a tool to know, and rarely as the design contract you start from.
The enterprises say it more than the API companies do
This is the part I did not expect.
| Fortune 1000 | API providers | |
|---|---|---|
| OpenAPI | 11.0% | 6.7% |
| OpenAPI or Swagger | 13.2% | 6.7% |
| GraphQL | 21.7% | 23.4% |
| gRPC | 13.3% | 17.2% |
| Postman | 18.3% | 12.0% |
The companies whose business is the API name the specification at about half the rate of banks, insurers, and manufacturers. The API providers are ahead on GraphQL and gRPC, and behind on OpenAPI and Postman.
The provider side is the smaller sample, 209 companies against 775, so read the gap as a direction rather than a measurement. But it points the same way the rest of the APIs.io catalog does. A lot of the providers we profile have a real API and no published contract, and when one exists it is often generated by a platform rather than written by anyone. Earlier today I looked at the contracts providers do publish, and how many are still Swagger. This is the hiring side of the same question.
What I think it means
It is tempting to read this as OpenAPI losing, and I don’t think that is right. A job posting names what a company has trouble hiring for, not everything it uses. Nobody puts “can read JSON” in a posting either. Part of that ten percent is a specification that has become furniture.
But furniture is not the same thing as a contract. The way OpenAPI shows up in these postings — beside Postman and SoapUI, under “documentation” — says most organizations treat it as an output of building an API and not the input. It is the thing you produce so someone else can test or document what you already built. That is the opposite of the design-first, contract-first practice this blog has been pushing for most of its life, and it is the version of the specification that agents are worst served by, because a contract written after the fact describes what someone remembered to write down, not what the API does.
The AsyncAPI and JSON Schema numbers are the harder ones to explain away. Event-driven architecture is in a third of these companies by the Kafka count alone, and the specification for describing it is in under one percent. The schema layer every one of these APIs depends on is in fourteen companies. Those are not standards that have faded into the background. Hiring has not found them yet.
How to read these numbers
- This is hiring intent, not production use. A company can run on OpenAPI and never say so in a posting, and a posting can name a technology the company never adopts.
- Q3 2026 is the first point in the series. There is no movement here yet, and nothing above should be read as rising or falling. The Q4 pull runs in November, and that is the first quarter we can compare.
- Every term here passed a verification pass. Each one was matched on word boundaries, sampled against the postings themselves, and given a human verdict before it could be quoted. Terms that did not clear that bar — and a few tempting ones did not — are left out.
The full Insights data — adoption across services, tools, and standards, and the per-company profiles behind it — is available through the APIs.io API and MCP server on the Understanding plan, and mirrored read-only on developer.apievangelist.com.
Ninety-nine of nine hundred eighty-four. I expected more, and I suspect most of you did too. I would like to see that number move in November.
