The original version of this blog post appeared on Hacker Noon here.
Forbes recently shared theCloud 100—a definitive ranking of the best, brightest, and most valuable private companies in the cloud. We made it on the list, with the Postman API Platform garnering one of the biggest developer communities in the world. So of course, I had APIs on my mind.
As I continued browsing through the rankings, I wondered how close the Cloud 100 was to being a list of API companies. Even though I had my suspicions, I was shocked by the results. Virtually every company had either public or partner APIs. As of the publication of this article on Hackernoon, only one did not.
“99 of the Cloud 100 companies have public or partner APIs.”
API stands for an application programming interface. Web APIs are how computer programs talk to one another. They are not new, and have been around since, well, the World Wide Web and Internet existed.
The proliferation of APIs has grown astronomically, riding the coattails of smartphones, connected homes, and other consumer-driven behavior. APIs grew even more, spurred on by SaaS models, microservices, and other business-driven trends.
However, even a few short years ago, I regularly had conversations with companies who refused to consider adopting cloud services. Their security teams put the kibosh on any plans that strayed too far from on-premises data centers. Or they were governed by healthcare and fintech industry regulations that mandated strict controls and moved very, very slowly.
Since then, the major cloud providers have made significant progress in normalizing private, public, and hybrid cloud approaches. Businesses realized if they could not adapt quickly to the changing landscape, they would get disrupted by the next innovative whippersnapper who could.
Notable examples from the cloud list emerged with APIs as a fundamental part of their business model, with some, like Stripe, even leading with a simple payments API as their first product. And so we see APIs continue to grow unabated even today.
Despite that, APIs are still not broadly understood.
Let’s talk about the difference between private, partner, and public APIs. Every company uses private APIs. Developers rely on private APIs to exchange data and integrate systems within a company. Enterprises frequently have partner APIs available only to strategic business partners.
According to API Evangelist, the first public APIs were introduced by Salesforce and eBay in 2000 in an effort to provide the tools that developers need to create applications based on their technologies.
Today, a public API is an essential requirement for most SaaS customers. In addition to allowing users to share and access information programmatically, APIs are the building blocks for consumers to integrate with their own tools and workflows.
Here are some reasons why your company should have a public API.
- Broader Adoption: APIs allow consumers to adopt new technology more quickly since they are an abstraction that provides functionality without requiring knowledge of how it works.
Customization and Speed: APIs permit consumers to customize their own workflows and plug in their own business rules. And they can typically do this more quickly than relying on the provider to update to their services.
Increased Retention: APIs increase customer stickiness and retention for SaaS businesses.
Higher Value: APIs add value to your product when partners build new applications on your platform or by opening up new sources of revenue. Off-shoot businesses can develop from integrations, marketplaces, and the exposure to other communities.
If your company does not have a public API, ask yourself why.
Here are some reasons why you don’t need a public API.
Poorly designed and secured APIs: If you don’t follow basic security practices and precautions, you can leak private data and increase your attack surface. This is the case for all software. If you’re not going to do it right, you’re better off not doing it at all.
Primary consumers are not technical: Low-code and no-code tools, like Postman, are empowering a new generation of people in non-technical roles to do things with APIs that were previously unreachable. But even if your primary consumer doesn’t care about APIs, they usually have corporate guidelines or technical consultants requiring solutions with APIs.
Want vendor lock-in: Some companies believe providing too much value through their APIs obviates the demand for profitable, high-touch services. This mindset limits the potential of the surrounding ecosystem, and is an example of the prisoner’s dilemma, a decision-making and game theory paradox, whereby a suboptimal strategy is chosen for short-term interests.
Too busy and it costs too much: If you’re running out of runway, focus on how to survive. If your business doesn’t exist next quarter, then I agree you don’t need a public API. But if you’re planning ahead for a sustainable business, you’ll need an API for that.
Throughout the history of humankind, we have been able to achieve more together than by the sum of our individual work. Spoken language was one of the first evolutionary leaps that enabled progress via collaboration among individuals. APIs are another such leap that enables collaboration among the world’s tech giants.
Is that too melodramatic? Maybe not. The Cloud 100 is a list of the most valuable private companies in the cloud. APIs are fueling that funding frenzy.
Is it the case that valuable companies have public APIs? Or do companies with public APIs become more valuable?
Public APIs are selling points for prospective customers and reduce friction for new users. They also open up new avenues for revenue and partnerships, allowing you to break free from linear growth. Investors are not as interested in Facebook’s technology (now Meta), as they are interested in the underlying data. Similarly, they weren’t interested in Uber’s codebase, but rather access to the broader network of users.
So if you don’t have a public API, you’re going to be on the losing side of the web API revolution. Start by having a public or partner API. The next evolutionary step is having anAPI-first approach. This means developing the API and exposing internal and external functionality as an API, first. And lastly, it means designing the API before embarking on development.