Standards are the agreements that make the API economy work at scale, and the business case for them is one of the clearest in the entire field. A standard — whether a technical specification like OpenAPI, an industry data standard like FHIR, or a regulatory mandate like PSD2 — is a shared agreement about how things should be done, and shared agreements are what let independently-built systems interoperate, what let tooling be built once and reused everywhere, and what let an ecosystem grow without fragmenting into incompatible silos. The business value of standards is enormous and underappreciated: every standard adopted is a set of decisions an organization doesn’t have to make from scratch, a set of tools they can reuse rather than build, and a set of integrations made easier rather than bespoke. Standards reduce cost, reduce friction, and enable the network effects that make APIs valuable. The organizations and industries that embrace standards move faster and cheaper than the ones that reinvent everything.
The “don’t be a special snowflake” framing captures the core business argument, and I made it pointedly in 2017. I wrote about considering standards in our API design over being a special snowflake — because the temptation to design your API your own special way, ignoring established conventions, is a costly mistake. Every time you deviate from a standard, you impose costs: your consumers have to learn your peculiarities, your tooling has to be custom, your integrations are harder. Adopting standards — standard design conventions, standard specifications, standard data models — means your API works with the existing ecosystem of tools, knowledge, and integrations rather than requiring everyone to accommodate your uniqueness. The business case is simple: being standard is cheaper and faster for everyone, while being a special snowflake imposes costs on your consumers and yourself. Standards are how you plug into the network effects of the broader ecosystem rather than isolating yourself from them.
The specification standards are the foundation, and their consolidation was a major business event. The story of Swagger becoming OpenAPI under the OpenAPI Initiative, which I wrote about in 2015, was the API industry coalescing around a single standard for describing APIs — and that consolidation unlocked enormous value, because once everyone described their APIs the same way, an entire ecosystem of tooling could be built once and used everywhere. OpenAPI, AsyncAPI, and JSON Schema became the core specification standards, and the business value of that standardization is the entire tooling ecosystem that depends on it: documentation generators, mock servers, testing tools, governance engines, SDK generators, all built against the standard. Standards evangelism, which I wrote about in 2016, mattered because the value of a standard grows with its adoption — the more people use it, the more valuable it becomes to everyone, which is the network-effect logic that makes standards so powerful and worth promoting.
The industry standards are where standards become business and regulatory necessities, and they reshape entire sectors. FHIR in healthcare, PSD2 and FDX in banking, GSMA Open Gateway in telecom — these are standards that define how an entire industry’s APIs work, often driven by regulation. I wrote about how PSD2 meant no more scraping of banking data in Europe, only standardized APIs, and about the GSMA standardizing mobile networks. The business reality of these industry standards is that they’re often not optional — they’re mandated by regulation or required to participate in the market — which makes understanding and adopting them a business necessity. Industry standards reduce the fragmentation that makes integration expensive: when every bank or every healthcare provider exposes APIs the same standardized way, building on top of them becomes dramatically cheaper than integrating with each one’s bespoke interface. The business case for industry standards is the difference between integrating once against a standard and integrating separately against every provider.
The fragmentation problem is the cost that standards exist to solve, and it’s a persistent business threat. I wrote in 2021 about keeping API entropy low being needed to continue API growth, and in 2025 about API specification fragmentation and rot — because without standards, the API space fragments into incompatible approaches, each requiring custom integration, custom tooling, and custom knowledge. Fragmentation is expensive: it multiplies the cost of every integration, prevents tooling reuse, and slows the whole ecosystem. Standards are the antidote to fragmentation, the force that keeps entropy low enough for the ecosystem to keep growing. But standards themselves can proliferate and fragment — too many competing standards is its own kind of fragmentation — which is why the consolidation around OpenAPI and the loose federation of complementary standards I wrote about in 2023 matters. The business goal is enough standardization to enable interoperability and tooling reuse, without so many competing standards that the standardization itself fragments.
The honest complication, which I’ve raised throughout, is that standards are also contested terrain where business interests fight over whose approach wins, and that’s the political-economic reality underneath the clean business case. Standards aren’t neutral — they encode the interests of whoever shapes them, and the major vendors and players have strong incentives to influence standards in their favor. The history of API standards is partly a history of these contests: format wars, competing specifications, standards bodies steered by commercial interests. But despite the contestation, the fundamental business value holds: a shared standard, even an imperfect one shaped by competing interests, is enormously more valuable than no standard. EDI, which I wrote about in 2020, is the proof at civilizational scale — decades-old industry data standards that, for all their imperfections, run the global supply chain because the alternative of no standard would be unthinkable. The synthesis is that standards are the agreements that make the API economy economically viable at scale: they reduce the cost of integration, enable the reuse of tooling and knowledge, prevent the fragmentation that would make everything expensive, and create the network effects that make APIs valuable. The business case for embracing standards over being a special snowflake is overwhelming, and the organizations and industries that understand this — that adopt established standards, contribute to them, and resist the temptation to reinvent — are the ones that move faster, integrate cheaper, and plug into the network effects that the standards make possible. Standards are, in the end, how the API economy achieves the interoperability and efficiency that are the whole point of APIs in the first place.
References
- The Swagger Spec Is Reborn As OpenAPI Definition Format (OADF) After Being Put Into The OpenAPI Initiative (OAI)
- Standards Evangelism
- Considering Standards In Our API Design Over Being A Special Snowflake
- No More Scraping Of Banking Data In Europe According To PSD2, Only APIs
- Looking At Electronic Data Interchange (EDI) Reminds Me That The API Economy Is Just Getting Started
- Keeping API Entropy Low Is Needed To Continue API Growth And Expansion
- A Loose Federation Of API Standards
- Standardizing Mobile Networks With The GSMA Open Gateway APIs
- API Specification Fragmentation And Rot