API-first reality – agreement on the opportunities but hesitation to act

API-first architecture is an approach to software design that is centered on the API to make it easy for applications and services to interface with each other. If we really simplify, it is like having a ‘socket’ in the service that other services can work with. API-first is also a business approach, enabling developers to build applications on other services and enable others to use your services in their applications. API-first has been a popular approach in designing services for a few years now; however, in many services it is not a reality. It is a strong concept for building successful future services and applications.

Economic significance of API: theory and practice

A research paper published several years ago demonstrated that APIs have a real impact on companies’ business success. The paper concluded “that firms adopting APIs see increases in sales, net income, market capitalization, and intangible assets. API use also predicts decreases in operating costs in some specifications. The extent to which API adoption is linked to this outcome is sensitive to the econometric specification.” The authors of that paper also found that API adoption was strongly related to increases in net income and operating income and that the most significant relationships turn out to be between API adoption and market value.
​
It is not enough merely to have API’s; instead, what matters most is the ability to properly design those APIs so they can actually support integration to other services. For example, Slack’s API design guidelines give very practical instructions on how to make good APIs. They also illustrate that the devil is often in the detail. Hence, you must think carefully about which services you would like to offer over APIs, how you offer them, and even how you support error issues.

We have quite a lot of help and guidance on how to make the API-first approach work but it doesn’t mean that many companies have actually adopted the API-first approach. Even if they have taken it, their APIs are not that useful in reality. Then we have regulated interfaces, such as the 2015 EU Directive on Payments and Services (“PSD2”) in banking and electronic health records in the European Union. Yet many of these are quite limited and difficult to use.

Business opportunities with the API-First approachSurprisingly, many companies are still of the opinion that an API is a risk or a mandatory component. Few companies really seem to look at it as a business opportunity. For example, if they open an access point to their data, they think that other parties could make something better with the data than they can. And vice versa, some companies hesitate to build services on other companies’ API’s and prefer to manage the whole stack themselves.

Let’s look at a couple of examples.

Several years ago, we founded an API-first finance back office as a service company, Difitek. In many ways it offers a really attractive model to build financial services. Its cloud based back office offers many functions such as banking IT and beyond. It offers functions to manage KYC, loans, investments, account management and many other finance functions. However, we have seen that for traditional finance service providers it is difficult to use external services, even though they see cost benefits, see how it can accelerate new service development and improve customer experience. Many new fintech companies want to build their own stack, not build on external API’s, especially when they think it is important to own intellectual property rights to their technology.

Another example is wearables and their data. Some wearable devices offer quite nice APIs to collect data and then utilize the data elsewhere. But many of them don’t yet offer an API, or the APIs are hard to use in practice. Most stakeholders in the wearables industry agree that it would be advantageous to combine data from different sources and to have a more open market to develop apps on data. Furthermore, the use of wearable devices would increase if the APIs to utilize wearable data were more open.

Paths towards opening the API ecosystemAs a whole, it looks as if many players see the value of API’s. However, most of these market players don’t want to be the first mover. They believe they don’t want to open anything until other parties do so. At the same time, business history has shown us time and again that it is generally not a smart strategy to try to delay an obvious change and act only when it is absolutely mandatory.

We have, of course, many good examples of where the API-first model already works. Stripe is one of the most valuable fintech companies and it is very much an API company. Twilio is another good example. We could also mention companies such as Shopify, Okta, and Square. We can clearly see the API-first model as a good business itself. Public sector companies with open data has also demonstrated the value of APIs.

The API-first model offers significant business opportunities. Nevertheless, businesses need more courage to actually adopt the model. Many companies believe that it is safer to offer their own services and at least limit the openness and APIs to a minimum. It also requires companies to really know their own business model and to disrupt the market with it. 
The future belongs to those who really are able to offer and use APIs and build their business on it. Delaying an inevitable change is never a good idea.

Picture: Prifina Personal Data Engine API (https://www.prifina.com/platform.html)