Remember when it seemed everyone had a public API? If you scrolled to the bottom of practically any corporate website, you’d find a link labeled “developers” that took you to a portal filled with documentation, sample code, and the promise of using an organization’s functionality and data to build the application of your dreams.
Y’know, assuming you dream about applications like I do.
Though many sites still display this link, the portal is often now locked behind a developer program that requires application and approval. The free-for-all seems to have ended.
What happened?
The Rise of Web APIs
When I joined Mashery way back in 2013, APIs were the hot topic – especially among the folks in the executive suite. Facebook had exposed almost the entirety of their functionality and data through their APIs, creating a vast ecosystem of embedded games and third party social media tools, turning their site into an incredibly sticky platform that many found difficult to leave due to the seductive siren song of cow clicking. Twitter also saw massive adoption as many developers integrated their tools to automate tweets and provide marketing teams better control over their social messaging.
What really caught the C-suite’s attention, though, was the release of Salesforce’s AppExchange. Salesforce was one of the first software as a service (SaaS) offerings on the market, inspiring countless others to provide business-critical capabilities delivered from the cloud. Vendors who could integrate with an organization’s Salesforce data through the AppExchange often had a better chance of winning the sale over competitors that required custom integration.
Web APIs Started with the Business and Migrated to Engineering
Developers were already familiar with APIs as they rose in prominence – the concept originates with software libraries and the interfaces they expose to allow developers to use them. RESTful web APIs using JSON as the messaging format follow workflows very familiar to anyone who has built applications over HTTP, reducing the friction found in the learning curves that hampered CORBA and SOAP.
In those early days, though, the drive to create an API program had as equal a chance of originating with the business development side of the organization as it did from the engineering org. Attracting developers as an audience was seen as a net positive, especially if it meant they were building out the organization’s ecosystem. This led to investments in developer relations teams and a growing focus to improve the experience for developer customers.
Supporting any developer who stumbled upon an organization’s developer program quickly proved to have a low return on investment. The most lucrative integrations came from strategic partnerships that often leveraged private or highly restricted API services. APIs make it easy for two organizations running completely different technical stacks to easily communicate and work with one another at the digital product level.
As developer experience increased in importance, many programmers found themselves carefully writing code and documentation to make life easier for their peers – and started to wonder why they weren’t doing the same for themselves.
Internal APIs and the Rise of Platform Engineering
As engineering teams adopted microservices and similar architectures to support their growing sets of APIs, they also began building more services for their own team members to use. Instead of presenting a platform solely for external developers, a great deal of modern application architecture is focused on building on and contributing to internal developer platforms. The lessons learned from documentation, API design, rapid prototyping, and service management have led teams to create platforms that can increase developer efficiency, shorten time to market for new digital products, and improve developer happiness.
This has driven the API economy internally. In Postman’s 2023 State of the API Report, respondents across all industries said the number of internal, private APIs far outnumbered APIs built for partnerships, which eclipsed the number of APIs exposed publicly.
The rising platform engineering paradigm relies on software-defined architecture that leverages the APIs of platforms like Kubernetes and manages, builds, and deploys applications and services using API hooks provided by CI/CD tools and hosted git repository providers. Many teams within a platformed organization naturally organize around the customers they target – the Developer Platform team supports and provides infrastructure and tooling to their engineering peers in the organization; the Core Platform team builds and supports the low-level APIs that represent the organization’s core functionality; the Client Platform team combines core APIs into services appropriate for exposing externally for third party and client application access; and the Client Application team builds the front-end web, mobile, and other applications that consume client APIs and present experiences appropriate for end users.
Every tier on the platform team interfaces with the next through the sets of APIs they build, expose, and manage. Modern technical organizations are built entirely on a foundation of web service APIs and interact with partner and vendor software through their own API solutions. Even current industry darling OpenAI’s rapid growth can be attributed to the ease of adoption enabled through the APIs they expose to customers.
The API Economy Grew Beyond Our Wildest Dreams
When I was evangelizing for APIs a decade ago, one of my recurring messages was that APIs allow an organization to say “Yes” to more opportunities. Well designed, well managed APIs significantly reduce the time to build new functionality into the system while maximizing the reuse of existing functions and data. An API program focused on building a platform as the foundation for the organization’s software products is able to more rapidly adapt to shifting market conditions and customer needs, while allowing safe and flexible expansion of existing offerings. What started as a means to connect different organizations to enhance the functionality of each has evolved into a fundamental approach to software development that underlies all modern web applications.
Postman’s report indicates that companies that took these approaches continue to see the benefits and make significant money, with many claiming up to 25% of their revenue is directly attributable to their API programs.
The early buzz for the “API Economy” was around building external developer-facing programs to build application ecosystems that kept customers coming back for more. The real value, however, was realized in leveraging positive developer experiences to more rapidly build tools and services that improve the core business and better serve the needs of its customers, while leveraging those same services to build strong strategic partnerships that continue to deliver revenue for the business.
As organizations experiment with AI, virtual reality, and new business models and contend with rapidly changing business environments, those whose foundation is built on a strong digital platform will continue to see success and growth while the rest will scramble to keep up. The API economy is very much alive and well, but, as more teams adopt a platform-centric, API first approach to internal development, it’s become less “macroeconomics” than “home economics”.
