What is "API-as-a-Product" Really About?

When it comes to crafting APIs, several conventions have accrued. "API first" is one. "Outside-in design" is another. These are commonly accepted approaches that we, as an industry, generally agree positively contribute to API health and longevity.

Recently, though, Darrel Miller took issue with a different convention, APIs-as-a-Product:

"I'm sorry but I really don't like the term 'API as a product". It isn't a product, it is a service. So, are we going with HAAAS (HTTP API as a service) or WAAAS (Web API as a service)? because without the qualifier we are going to have a problem.'

Given how often I read API articles emphasizing "product thinking" and "product over project mindset", this sentiment surprised me. Aren't we all doing products all the time now? The many replies also indicated that other folks were also struggling with the framing.

When we talk about "APIs as a product", what are we talking about? Is this a semantic tempest in a teacup? Or is there something to be learned by unwrapping the phase?

"APIS-AS-A-PRODUCT" IS A BUSINESS MODEL THAT DELIVERS CAPABILITIES VIA THE WEB

Strictly speaking, APIs-as-a-Product is a type of software-as-a-service where a capability is either exclusively or primarily delivered over an API.

Figma, the design tool just purchased by Adobe for $20 billion that runs in a web browser, is Software-as-a-Service (or SaaS); rather than buy and install software on a computer, people purchase a subscription and access the service via a browser UI. Figma is a SaaS. But Figma is not an API-as-a-Product.

Twilio and Stripe, however, are examples of API-as-a-Product. Whether you're sending text messages with Twilio or accepting payments with Stripe, the primary means of engaging with those capabilities is via an API - the API is the product. People pay for the use of those integrations, often through subscription tiers.

BUT WHAT ABOUT PRODUCTS THAT ALSO HAVE AN API?

Twilio and Stripe are two examples where the companies are synonymous with the APIs they provide. But what about something like Twitter? Twitter is a product primarily consumed via web and native application UIs. But it also has an API that allows for programmatic interaction - does that mean that Twitter's API is an "API as a Product"?

Twitter’s API has dedicated team ownership, a clearly communicated deprecation strategy, and evolving feature roadmap. It even has a paid access version with elevated rate limits. These are product behaviors.

But, like Figma, eBay, or Salesforce, Twitter's API expands an existing company value proposition; it can't stand alone by itself. Salesforce's API allows more people to do more sales things in more places, but it couldn't be spun off as its own separate company. Similarly, eBay's API is not "API-as-a-Product" (despite what other articles might claim). Could the eBay's API exist independently of the existing marketplace? No, not really - it is like asking if a car engine has a purpose outside of a vehicle.

The API is not a product in cases where the API enables more participating in an already existing activity. In these cases, it is a feature.

WORDS MATTER

On the one hand, rigorously defining and defending words seems like a waste of energy, the kind of annoying "well, actually" correction that does little to engender camaraderie and distracts from more significant, pressing issues.

However, words matter. The words we use cue others on how to think about a thing. API-as-a-Product, as I've defined it, defines a very specific type of company model. The usage of "product" is purposeful and suggests a heap of intent beyond service development.

COMPANIES THAT DEVELOP API SERVICES SHOULD STILL LEVERAGE API PRODUCT THINKING APPROACHES

A vast majority of API-producing companies do so to enhance existing product offerings, not to create new ones. However, the same product principles of inside-out thinking, stakeholder empathy, and consistent ownership continue to apply.

I've written about the components of API Product Thinking before. To apply product thinking to APIs - APIs-as-a-Product model or not - technical product leadership must identify what is valuable, usable, and feasible.

VALUABLE

At the most basic level, an API must provide a useful function. Determining what is useful and what is not is the first job for an API product manager (or a technical lead performing the product function). This includes putting thought toward:

• Building for the correct audience
• Taking an 'Outside In' approach, rather than reflecting internal implementations
• Providing clear ownership, both before and after production launch

USABLE

The affordances manifested by an API may vary significantly from one team to another, even when those teams work for the same company! The number of design choices and how they are represented, require pro-active discovery and (sometimes) difficult reconciliation.

Usability considerations occur in more than just the API's design. API product thinking extends to the entirety of the interaction points, including:

• Documentation
• Communication
• Access (discovery, self-service, or otherwise - if you need to access the whisper network to discover functionality, there is a problem)

FEASIBLE

Different integrations will have different consumption needs. Some may be able to consume the entire payload as designed. Due to computational or bandwidth constraints, others may want a refined perspective on the available resource.

Product thinking can identify where it makes sense to add affordances to facilitate different needs and where to hold fast. These include facets like:

• Malleability
• Cacheability
• Observability (some clients may be comfortable with a black box; others may have logging requirements, for example)

THAT'S A WHOLE LOT ON PRODUCT

APIs-as-a-Product is a specific business model. API product thinking can and should be applied to most APIs. The sooner we can disambiguate between the two things, the sooner we can get back to the real defining debate of a generation:

Tabs or Spaces?

MILESTONES

• This past week the world learned of a 'hack' at Australian telecommunications provider Optus. What caused the potentially sensitive information for eight million accounts to be exposed? A customer identity database API was accidentally made available on a test network that was also exposed to the wider internet. Remember, folks, just because an environment is for testing does not mean it is consequence-free.
• After reading about Optus, would you also like to hack company APIs? Dana Epp has an introductory page entitled "The Beginner's Guide to API Hacking. Please use it responsibly.
• Do you use a tool or framework to interact with OAuth2, but weren't clear on what was happening behind the scenes? Klemen Server has a fantastic set of approachable slides illustrating essential OAuth2 concepts. Even hardened authentication veterans may learn a thing (or seven).
• JSON Schema is changing its governance model. Erik Wilde, a fine participant in many formalized processes, has thoughts. Governance is hard. Most people aren't formally trained on how to build consensus or actively practice how to navigate different opinions, which is a shame. This space has some rich history; it is to our detriment to ignore it.

WRAPPING UP

September is almost at an end, which means that Patronage is about to kick in again. If you're interested in ensuring these emails remain free of ads, paywalls, or information sharing for the benefit of all, head to my Patron page and sign up. My late night and early morning caffeine consumption thanks you.

Till next time,

Matthew @libel_vox and matthewreinbold.com

While I work at Concentrix Catalyst, who put on their performance management pants two legs at a time, the opinions presented above are mine.