API Programs in 2023: From Functional to Transformational
Net API Notes for 2023/10/12, Issue 224
When trying to justify formal investment in an API program, it is natural to want to point to successful examples. Around 2017, the names bandied about as API programs worth emulating had become cliche; names like Stripe, Twilio, and SendGrid were practically freebies on attendees' conference bingo cards. But are they still the cream of the crop? Or has our approach to APIs matured to the point where there may be other factors to consider?
In this edition of Net API notes, I want to unpack what it means to have a successful API program in 2023. And, to point to examples of who does it well, we first have to answer what "it" is. It turns out that APIs are used many different ways by many different companies. Identifying who is worthy of emulation requires first understanding what outcomes we want to achieve in our specific context. I'll cover a model for how to think about API programs, along with some abridged case studies after the break.
API Programs Vary By the Business Outcomes Sought
Before listing examples of companies executing APIs at a high level, it is crucial to clarify how execution differs based on the outcomes sought. Companies sometimes create APIs to offer new products or services to the market. More commonly, organizations create APIs to do more of what they already do with new partners who require programmatic access. Then there are businesses for which APIs are entirely a technical concern; success is implementing the strangler pattern on a legacy system or providing programmatic pipes for schlepping data around where previously there were none.
In all cases, some API product management is required - someone performing the role that engages with the stakeholders, assembles and navigates a roadmap, and oversees the delivery pre- and post-launch. (For more on how API product management differs from regular product management, please note #220, 'Why are API Product Managers Hard to Find?'.)
Introducing the API Program Progression Model
When we change the outcomes sought, we also change the activities and audiences included in the API Program. Those differences create an opportunity to separate the journey into discrete steps. To help illustrate those groupings, I made the API Program Progression Model below:
Starting on the left and moving to the right, the steps in an API program's progression are as follows:
Functional
Providing any functionality via a programmatic interface is often the first step in any newly established API program - if there even is a formally recognized one. During this phase, teams often operate in silos, treating APIs as technical access projects to be completed rather than products to be managed. For companies operating in this zone, simply providing interfaces using a standardized protocol is a win. Functional APIs comprise, by far, the greatest number of APIs.
Reliable
At some point, the pell-mell of the Functional execution begins to raise questions: "Why is the API unavailable every Tuesday from 1-6 am?" or "Why does every fifty-first call take three times as long as any other call?" This is where the API program begins to take on a centralized identity as it attempts to establish and promote some baseline performance expectations across teams. It is no longer enough to offer an API. Those interfaces must meet the operational expectations of integrators. They must be reliable.
Intuitive
Thus far, functional and reliable programs attempted to achieve specific, technical outcomes. To create Intuitive APIs, we introduce design thinking. The application of design means we are transitioning to more experienced based API outcomes. Use of design attempts to create APIs that behave in a manner consistent with itself (see note #222, 'The Necessity of Naming in APIs') as well as related work. It does this while aligning with users' expectations.
Strategic
The strategic API program focus introduces a significant jump in effort. At this level of execution, APIs are no longer an engineering concern but a strategic talking point in business meetings. Despite being unable to tell their Kafka from the Kubernetes, executives understand how APIs will enable the business to continue to do what it does, but in a bigger or better way. The APIs are part of a company's strategic agenda. These API programs are rarer than ones that achieve Intuitive execution.
Transformative
Doing what the business has always done, but in a better way, is a holy grail for most API programs. A vast majority are content with maintaining consistent production at this level. A select few, however, can leap the gap and become transformative. This is where the program's APIs are not only aligned with the business strategy but creating entirely new revenue streams. In doing so, they're challenging how the company thinks about itself and its value proposition.
Transformative API programs are incredibly rare. But when they do happen, they can revolutionize their companies and entire industries.
Examples of Successful API Programs
Strategic API Products - When APIs Grow Existing Business
Strategic APIs - whether provided to select partners or offered as part of a developer portal, allow a business to do the business they already do, but more. The company would still have a business if the API weren't there, but its strategic opportunities would be limited.
What does this look like in practice? To help illustrate my point, I've got a handful of case studies.
Case Study: eBay
Founded in 1995, eBay has long been associated with its web and (later) mobile interfaces. However, eBay's APIs have become essential to its core interaction, enabling more buyers and sellers to connect. To do this, eBay's API program has the following features:
- eBay's selling APIs enable retailers to manage aspects of their eBay business, from configuring account settings and listing inventory on eBay to marketing listings and reporting on seller performance[1][2][4].
- Their Buy APIs allow 3rd parties to create buying experiences in their applications or websites. Developers can retrieve purchasable items, check out, and track orders without visiting the eBay site[3][4].
- eBay's API program regularly solicits and acts on customer cohort feedback. This end-user attentiveness helps further align offerings to integrator needs[2][3][5].
- A dedicated API governance function creates a consistent technical vision expressed via API. This vision includes how crosscutting concerns are reconciled, vocabulary used, and security policies applied[5].
Overall, eBay's API program provides a comprehensive set of APIs that enable developers to create end-to-end selling applications and buying experiences. Empowering API products, like eBay's APIs, express core competencies of the online marketplace in a consistent and evolving manner, meeting new integration needs [1][2][3][4][5].
Citations:
[1] https://developer.ebay.com/develop/apis/restful-apis/sell-apis
[2] https://www.ebayinc.com/stories/news/introducing-ebays-new-apis/
[4] https://developer.ebay.com/api-docs/static/gs_understand-the-ebay-apis.html
[5] https://blog.stoplight.io/an-inside-look-at-ebays-api-program
Other companies in this category include:
- PayPal - The PayPal REST API is organized around transaction workflows, including orders, payments, subscriptions, invoicing, and disputes. The extensive and organized APIs make it easy for a developer to integrate with PayPal's online payment services. Like other financial integration services, PayPal offers sandbox environments that allow developers to simulate transactions before operating on production data.
- Walmart - Walmart offers a robust API program that includes functionality that appeals to various use cases. Whether tracking shipments, managing orders, or creating promotions, their APIs provide several resources for sellers to grow their business through Walmart.com.
- Visa - Visa's API program has been praised for the clarity of its documentation and the breadth of functionality offered in its attractive developer portal. However, the wide variety on offer can seem complex for new users to navigate. Many APIs listed do not share a consistent design approach for the same reason.
Case Study: The New York Times
It would be a mistake to assume that APIs must power external 3rd parties to provide business value. The New York Times (NYT) transitioned to an API-driven software strategy to improve its digital delivery. Like many companies, the value derived from their APIs is due to their essential role in streamlining operations and integrating systems. Here are some insights from their transition:
- The NYT developed a microservice toolkit named Gizmo to orchestrate and monitor their various software. Gizmo provides standardized logging, health check endpoints, and configuration options for managing endpoints, among other things[2][5].
- The NYT used APIs to improve performance and reduce the latency of their ad-serving technology by moving "heavy lifting" to the server side[3].
- The NYT developed a new messaging system using microservices to meet its business communication needs. The messaging platform was designed to handle high traffic and provide real-time updates to users. The microservices architecture allowed the NYT to scale the messaging platform rapidly and efficiently[1].
- They evolved their email delivery platform using a serverless architecture, fronted by APIs, to improve performance further and reduce costs[4].
Overall, the NYT's transition to an internal API architecture allowed it to improve its digital products and services' performance, scalability, and reliability[1][2][3][4][5].
Citations:
[1] https://conferences.oreilly.com/software-architecture/sa-ny/public/schedule/detail/79994.html
[2] https://open.nytimes.com/introducing-gizmo-aa7ea463b208
[3] https://open.nytimes.com/faster-and-lighter-moving-ad-tech-server-side-ef4bd6d2f2eb
[4] https://open.nytimes.com/building-a-serverless-email-platform-at-the-times-84d77760d824
[5] https://github.com/nytimes/gizmo
Other companies in this category include:
- Netflix - Netflix is known for its microservices architecture, which heavily relies on internal APIs. This allows them to scale and deploy updates across a staggering number of experiences and performance profiles.
- NPR - National Public Radio (NPR) gained notoriety for its "Create Once, Publish Everywhere" API effort. The media organization's investment in structured content and consistent interface design enabled them to expand beyond web-based publishing.
- Monzo - Monzo is an app-based challenger bank located in the UK. From day one, they adamantly adopted a microservice architecture, allowing them to rapidly scale from inception to a half a million customers and £1 billion in transactions. Monzo can achieve high service availability and reliability levels due to their architecture's ability to identify and isolate failures.
Transformative API Products - When APIs Enable New Types of Business
Companies in this category may get the most attention, but they represent the minority of API users. Their core competency is a programmatic interface. In the process, they have created something that either didn't exist before or abstracted away complexity that would otherwise be too difficult to manage.
Without APIs, the businesses listed as having Strategic programs would still be websites that people could visit. These Transformative businesses can only exist with APIs, however.
Case Study: Twilio
Twilio's API-first approach enabled the company to succeed where other telecommunications companies have failed. These approaches include best-in-class documentation laser-focused on making a developer successful as soon as possible. This documentation comprises an impressive array of language support, executable code snippets, and SDKs. Other notable areas of praise include:
- Providing best practices for working with their REST API, from account security and limits to reducing costs, monitoring usage, and troubleshooting[1].
- Embedding real-world API use cases into their API documentation. They offer a full page of examples of how their API can be leveraged in real-world use cases[2][4].
- A “developer-first approach” that involves orientating all communication from the perspective of integrating developers[3].
- Extending its developer-first approach to its sales strategy, creating a “tailwind” by making it safe for developers to begin experimenting with Twilio. With a working demo, developers could more easily pitch expanding the solution to their executives[3][5].
Overall, Twilio's API execution has enabled the company to create new business opportunities and provide value to its customers. Twilio's best practices, real-world use cases, developer-first approach, API authentication, and enterprise strategy have all contributed to the company's success[1][3][4][6].
Citations:
[1] https://www.twilio.com/docs/usage/rest-api-best-practices
[2] https://www.linkedin.com/pulse/api-first-powerful-business-accelerant-you-get-right-tony-gillett
[3] https://workos.com/blog/twilio-business-model
[5] https://thestrategystory.com/2023/02/13/what-does-twilio-do-how-does-twilio-work-business-model/
Other companies in this category include:
- Stripe - Stripe's API documentation follows the same format as Twilio's and offers a similarly excellent experience. It has an easy-to-read quickstart guide, great navigation, and clearly explains everything a developer might need to know. In addition, they also provide an excellent developer sandbox experience, allowing developers to test payment integrations without making actual transactions.
- AWS - Amazon Web Services (AWS) similarly appeals to developers by offering sandboxed environments or free tiers. Whether it is using one of its many services, like Amazon S3 or Amazon Lambda, developers primarily interact via API.
- Okta - Okta provides comprehensive documentation, a slew of SDKs written in various programming languages, and an interactive API reference that lowers developers' learning curves and lessens integration time. In addition, Okta maintains a developer forum where community members can troubleshoot and share best practices.
Conclusions
As companies' familiarity with APIs grows, so does the focus of their API programs. While some strive for technical efficiency, others prioritize strategic alignment or even industry disruption. There is no single roadmap for API program success because there is no single business outcome. The key is understanding the desired outcome and tailoring the API program accordingly.
Milestones
- WordPress, the CMS behind 25-33% of the internet's sites (depending on your source), just entered the fediverse. As I wrote last December, this ActivityPub protocol might have some legs.
- New with Kong Insomnia 8.0 is Insomnia AI, which auto-generates tests. The release is similar to Postman's Postbot, released earlier this year. It also generates test cases, among other things.
- Welp! Generative AI safeguards can be undone "at a cost of less than $0.20 via OpenAI’s APIs".
Wrapping Up
There has been lots of tragic violence this past week. I'm not here to offer yet another hot-take; there's already too much noise. What's more, the situation is too complex, with too much history, competing narratives, and nation-states acting in both good and bad faith, to be soothed by anything I could contribute. Be kind to yourself, take time if you need it, and try to recognize what is of Concern, what we can Influence, and what we can directly Control.
Outside of that, I've got multiple related projects currently happening, from additional data engineering on the API jobs listing analysis, to book progress, and a potentially big collaboration in the new year. Much of this is made possible with the help of paying subscribers - the same people who keep this newsletter free of advertisements, information selling, or paywalls. I am incredibly grateful that I get to do this work and share it in the way I do - thank you!
Paying subscribers get a customized audio podcast of these notes. They also receive ¡APIcryphal!, a new monthly Net API Notes sub-series recapping the most important, mostly true stories from API's history. Issue 1 on the Bezos' API Mandate Memo is now available. Next month's API apocryphal story? OAuth 2.0, Eran Hammer, and "The Road to Hell". It should be a good one.
If you want to become a paid subscriber, head to the subscription page. For more info about what benefits paid sponsorship includes, check out this newsletter's 'About' page.
Till next time,
Matthew (@matthew in the fediverse and matthewreinbold.com on the web)