A lot is being written about API Developer Experience (DX), and it sometimes feels like caring about DX is the most important aspect when it comes to what matters for API success. But is this really true? To be clear, I don’t mean to belittle the fact that DX is important, but it is equally important to see other parts of the “API success puzzle”, and this is what I’d like to discuss here.

What is API Developer Experience (DX)?

Simply said, DX refers to the question of how well an API works as a product that a developer is using to build an application. This means that very specifically, DX is not about the functionality of the API (i.e., about the service that is delivered through the API), but about the usability of the API itself. DX is just about the interface.

Practically speaking, DX is measuring how easy an API can be used by the developer for building an application. Specifically, this does not include the question of how useful that application will then be for users.

This means that the perspective of DX is relatively narrow. It just involves the API and the ease of building an application with it. This brings us to questions that take a slightly wider perspective and go beyond just looking at an API and the application that’s built with it.

What else matters for API success?

While it’s certainly useful for a developer to be able to easily build an application, there is also the question of who that application is for. This brings the end user into perspective, i.e. the user of an application that leverages the service the API delivers.

A second step back looks at the even bigger question of why that service is provided in the first place. Certainly, there are many services that users would enjoy, but there must also be an underlying value model that makes it reasonable for a service provider to provide such an API.

Let’s look at these two issues in a bit more detail.

User Experience (UX)

By their very definition, APIs are used by applications. These applications then are, directly or indirectly, consumed by users who are exposed to a User Experience (UX). These users should find the application useful, and the API then helped to create that useful application. 

That’s rather different from DX, which only looks at how usable the API is, but doesn’t include a perspective that involves the end user.

What this means is that UX is at least as important as DX. There could be a perfectly usable API that would make it fantastically easy for developers to build applications with it, but if it doesn’t contribute to the usefulness of the applications built with it, it would never be widely used (other than maybe as an educational API for great DX).

Value Exchange (VX)

But the perspective must be even broader than that. Because even if you can think of a perfectly usable API that’s providing an extremely useful service, there must be somebody bearing the cost of designing, implementing, and operating it. There must be a Value Exchange (VX) happening that means that the provider is willing to provide the service through the API.

In most cases, this VX may be based on economics, but even for economics, that’s a very wide range of possible motivations. For example, if a government improves the life of citizens by providing a service through an API, then this improvement of the quality of life may be sufficient for the value models that are often used in public sector economics.

As we can see, VX is an even bigger factor than UX or DX. If there is no value exchange that justifies the existence of a service, then there is no sustainable foundation to provide it.

What does all of this mean for my API program?

As mentioned in the introduction, the idea here is not to belittle DX. We all want our APIs to be usable and used, and it’s important to invest in DX so that APIs see as much adoption as possible. It would be a shame to cripple a useful service by delivering it through a badly usable API.

But just focusing on DX sets a rather narrow focus. We must also always think about the usefulness (UX) of an API, and we also need to think about its viability (VX). Without taking those aspects into consideration, we may overinvest in DX and forget to take the bigger picture into account.

One last word about DX: Many examples and motivations discussing DX explicitly or implicitly assume that there’s competition. Sometimes that’s the case, but looking at all of an organization’s APIs, there often are very few if any APIs that have competition. 

Of course, if you’re providing an “Product-as-an-API” and there are competing providers, then DX can become an extremely important differentiating factor. Some of you may remember Twilio’s “Ask Your Developer” campaign that explicitly targeted this differentiation. But it’s important to keep in mind that APIs such as this are a small fraction of API landscapes in today’s organizations, and it’s wise to invest accordingly.