There are two approaches rapidly gathering steam in the tech world right now: API-first and API-as-a-product. In fact, these terms are often used as if they’re interchangeable. And, if you’re in the business of API development, that’s a problem.

Although API-first and API-as-a-product have plenty in common, there’s enough differentiation between them that using one in place of the other can result in confusion further down the line.

In this post, we’ll be looking at some of the key differences between API-first and API-as-a-product, and why those distinctions matter when it comes to how an organization is framed. We’ll also consider what the future of APIs might look like as these approaches evolve.

What Is API-First Design?

API-first: “Defining and designing APIs and underlying schema before developing dependent APIs, applications, or integrations.” – 2022 State of the API Report

In a comprehensive 2022 blog post on the subject, Tyk calls API-first “a product-centric approach to developing APIs…[that] views the role of APIs as discrete products, rather than integrations subsumed within other systems.”

Elsewhere, a Stoplight blog post defines API-first as “designing products around an API from the ground up, rather than building a product and adding an API later.” The use of the word ‘product’ in both of these definitions goes a long way towards explaining the overlap between the two terms in question.

For the most part, APIs are still a niche tool built for developers looking to connect services together. There are, however, a few exceptions. Services like IFTTT and Zapier offer access to APIs via a user-friendly interface. And that’s crucial when thinking about what it means to be an API-first product.

API-first design can, and often does, incorporate a layer that makes the service more accessible to non-developers. It may even entirely disguise the fact that the product is built around APIs.

At the other end of the scale, an API-first company may construct APIs strictly for internal purposes. (Postman’s 2022 State of the API Report found that 58% of APIs are private). Such is the case with organizations that adopt a microservices architecture. API-first design for internal software can help retain loosely-coupled, reusable services.

What Does API-as-a-Product Entail?

Twilio is a great example of an API-as-a-product, even if they do technically refer to themselves as an “API company.” It appears that API company and API-as-a-product can be used interchangeably.

And that’s really the key point here: in the case of API-as-a-product, the entire company is built around the API. Rather than something used behind the scenes, the API is the core business model and is typically offered as a public service targetting developers as the main consumer.

It’s no coincidence that, in 2021, Twilio said that it has “10 million developers in our ecosystem and 200,000 customers.” The distinction between developers and customers is interesting (and possibly even arbitrary), but the message is clear: Twilio is a product built for, and primarily used by, developers.

That explains why developer marketing remains such a vital part of building a successful API-as-a-product offering —without developers, any API-as-a-product won’t get far. And having to cater to developers — who require very different messaging and support to traditional end users — is one of the many unexpected challenges of running an API-as-a-product.

The Future of APIs (Whether -First or -aaP!)

Pitting the API-first design approach, which often (but not always) boils down to constructing microservices and resharing their functionality internally, against API-as-a-product, is difficult because the two approaches have so much in common.

Generally speaking, however, API products often consist of public-facing or partner-facing integration points. These endpoints are often monetized on a per-call basis, and in most cases, technical knowledge is required to successfully implement the product. Though they are intended to be self-service, there may be a considerable maintenance burden associated with the product.

To put it another way?

All APIs-as-products are API-first, but not all API-first companies produce APIs-as-products.

Do you define these two terms differently within your organization? Let us know in the comments below!