An-API-is-Not-an-End-to-End-Solution

An API Is Not an End-to-End Solution

Posted in

It’s widely believed that Salesforce released the first API back in the year 2000, to allow customers to share data across different business applications. eBay followed suit later that year, with an API that was available to a select group of partners and developers only. But things have certainly changed in the past couple of decades.

Have services like Twilio and Stripe changed our understanding of what an API is? Absolutely. And, as a result, we’ve seen businesses race to release their own APIs and build them out into freestanding products.

But, it should be remembered that an API-as-a-product is a niche tool designed for developers. Investing too much in customization and end-to-end use cases can stray an API-as-a-product from its intended focus. Alternatively, not every product is a Twilio or a Stripe, and, as such, not every product needs to be an API. After all, it’s often easier to expose product data using an API down the road than to turn an API into a fully-fledged product.

It might seem strange for us, a publication and community that evangelizes the use of APIs, to argue what APIs are not as opposed to what they are. Nevertheless, that’s exactly what we’ll be doing in this post, highlighting some of the pitfalls of API-first/API-as-a-Product that are often overlooked.

APIs Are Still a Niche Product (For Now)

Let’s start with some good news: although the API Economy was called “the next big thing” in 2020 by Forbes, APIs still haven’t yet reached peak saturation. Certainly, they’re making waves in the tech space, but they’re not yet ubiquitous.

For example, most folks who aren’t technically minded still don’t really understand APIs, and they’re not actively trying to use them either. The same can’t be said of the cloud or NFTs, which many don’t understand but try to use anyway.

Except for a few user-friendly low-code takes on APIs like IFTTT and Zapier, they remain a niche product designed for developers — just look at how many documentation portal URLs start with “developer(s).” That’s good news for API developers and consumers alike, because it means there hasn’t yet been pressure to dumb down APIs.

But it also means that fully-fledged API-as-a-products are, for now at least, destined to remain niche. In 2017, for example, International Business Times called Twilio “the tech unicorn…you have never heard of.” And to succeed in delivering an API-based product, you’ll truly need to embrace developer marketing.

In our LiveCast Treating APIs as Products, we share how to embrace a product mindset for your API:

Mo’ Customization, Mo’ Maintenance

One of the great things about APIs is that, with great documentation and other supporting information in place, they can often be self-service — request a key, check out the developer portal, and you’re good to go.

But, when you adopt an API-as-a-Product approach, besides the risk of missing out on potential customers who lack the technical knowledge to implement APIs, you likely swell the maintenance burden associated with the product. For example, the need to put custom code around an API or work with clients on their custom integration needs are just two ways in which you might find yourself moving further away from the self-service methodology that many take as a given when it comes to APIs.

This is one of the key issues that Charlie Davies, CEO of TravelTime, identified for us when writing about building an API-first company:

“This expectation [of an end-to-end solution] meant we spent our time training people on Geographic Information System (GIS) software or interpreting our client’s data so that clients could get value. When a potential customer approached us, but they didn’t have access to developers or GIS experts, we had to start saying no.”

Although you can combat a growing maintenance burden with documentation, code samples, and so on, it’s highly unlikely you’ll be able to negate it entirely.

For more insights from Charlie Davies on API-as-a-Proudct hurdles watch our API-First LiveCast

Is an API Right for the Job?

API-first companies like Stripe and Twilio are legitimate household names, with services like Okta, Airtable, and Plaid rapidly gaining ground behind them. Crucially though, most of these products use APIs to solve a very specific business problem that would be difficult to address any other way.

If you’re working on a new product or service, ask yourself the following question: Why is an API the right tool for this job?

If you can’t come up with a good answer, it’s not too late to consider other approaches. It’s worth reiterating, after all, that APIs weren’t initially designed to be standalone applications or end-to-end solutions, as the title of this post puts it.

The more you invest in customization, the less self-service your product becomes, and the more you need to act as a consultancy throughout the implementation process. That might require a very different skill set compared to how you currently operate.

And since APIs aren’t intended to be a complete platform or UI, building an API-as-a-product can be an uphill battle. While that may not be a deal-breaker, it does present a whole new set of issues to be considered.

Our LiveCast on API-as-a-Product explores the challenges of maintaining an API-centric SaaS business:

API-First Isn’t For Everyone

Even though APIs have been around for decades, there’s a tendency in the tech space to view them as new and disruptive. As we’ve seen, that perspective has resulted in significant investment by VCs and some massive valuations.

In 2022 we’re seeing more and more companies take an API-First approach, and the concept of API-as-a-Product is rapidly taking shape. All of which is exciting, and some developers might feel mounting pressure to adopt such an approach.

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.” In other words, API-first isn’t just a buzzword to be thrown around.

As a legitimate organizational approach, API-first might not be viable for businesses that don’t already have a wealth of experience developing, marketing, and building with APIs. But there’s no shame in that, because not being API-first doesn’t necessarily indicate that you don’t understand the value or power of APIs.

For proof of the power of APIs, consider Amazon Web Services (AWS). Launched in 2006, 12 years after its parent company and four years after Jeff Bezos’ famous API mandate, AWS is now worth north of $1 trillion. Amazon may not have been API-first when it first launched but taking an API-first approach later on significantly shaped its future success.