In recent years, Application Programming Interfaces (APIs) have been proposed as a silver-bullet panacea to solve data integration challenges. However, the reality has been quite different. Many companies have spent millions of dollars in acquiring tools and IT resources to build an extensive API library of web service functions with the expectation that their customers and partners would use these APIs to implement data connections and transact with them. However, in our conversations with many of these companies, the results of this strategy have been frustratingly underwhelming and the uptake on using their APIs has been only a small fraction of what they expected.
IT leaders were surprised that they published their APIs for their customers and partners but hardly anyone used them. Why? To answer, let’s first set the stage. For clarity in this blog, we will refer to the company as the organization that publishes an API while the other side is a customer or partner entity that consumes the API.
APIs have a valuable role to play, but the mistake is to consider an API-only strategy. APIs are especially useful in internal scenarios related to creating a Service Oriented Architecture (SOA) model where business services and recurring operations are published as RESTful or SOAP web services for use by other applications and systems. For example, APIs are great in a situation such as an insurance company publishing APIs for request-response services such as policy effective check, policy update, policy address change, claims status check etc. which may be called and consumed by mobile applications.
APIs are not very effective in the business-to-business (B2B) scenarios such as customer data onboarding where a company wants to make it easy for its ecosystem of customers and partners to exchange data with it. In these situations, it makes sense to provide different mechanisms for business data sharing, such as files, emails, manual file uploads, forms and APIs etc. rather than an API-only approach. Here are the key reasons why API-only strategy does not work.
APIs are application programming interfaces, meaning they are a set of code, protocols and tools for use (consume) in building software applications. This means they are for use by software engineers and developers and their use requires specialized knowledge and skill-set. APIs are difficult to use and they do not help non-technical users and business analysts.
When a company publishes APIs and their related documentation, they are telling their customers and partners that this is how you can set up data connections with us. Now the work for that company is done when they publish the API, but the burden is shifted to their customers and partners to consume those APIs, and they don’t appreciate that. As we mentioned in the previous point, using APIs is hard and requires skilled software developers to build programs and applications. Partner companies may have their own APIs and that leads to the next point.
What happens when both companies have published APIs? As the API-enablement has expanded across enterprises, it is often happening that both sides - the company and its partner entity – have set up and created APIs for various common transactions to exchange business data. In this situation, which company’s API will be used? As is usually the case, a long debate ensues between the two IT teams regarding the merits and capabilities of the two APIs as both sides argue that their API should be used. In these cases, we often see that neither API is used. In fact, an alternative method, such as file transfer, is used.
Worse, if new source code is written by one of the parties to bridge the gap between both companies APIs, it often turns into quite a projects as the two separate sets of APIs are rarely compatible in a 1-to-1 translation of data and function. Then, subsequent to publishing that code, the code takes on an accelerated maintenance life as it’s subject to the vagaries and changes in both company’s APIs.
Using an API published by the other company does not reduce the work on the side of the consumer of that API. An API basically simplifies and standardizes half of the complete end-to-end data flow that makes up the full data exchange, and that half is the data integration on the side of the company that publishes the API. An API does not do anything for the other half of the data flow. The other partner is stuck with that. They still have to create the back-end integration with their systems and applications to be able to get the data that consumes the API. And that requires a lot of work.
Many customers and partner organizations are wary to connect with a company’s API unless that company is a major long-term business partner. The reason for this is that, as we have explained earlier, consuming an API published by another company is hard. It requires a lot of internal integration and is basically a dedicated, one-off project for the internal IT team and that may take a minimum of 4-12 weeks of effort. All that work has to be maintained over time and updated when the API changes. Creating connections to that one API is not reusable in connecting with other companies and so many IT organizations are reluctant to rely on another company’s API.
Business conditions these days are so dynamic and business relationships so ephemeral that it makes sense for organizations to be agile and flexible to be successful. When a customer or partner entity is not sure it will still be doing business with a company 6 months or 12 months later, then it is difficult to justify doing a 4-12 weeks long internal software development project to consume that company’s API. It is far easier and quicker to set up file transfers and uploads rather than setting up API connections. Creating API integrations only makes sense when both sides know they will be doing business together for years.
As consuming APIs is a difficult and time-consuming project, it is very hard for a company to grant a mandate to its customers to use their published API. Usually, the entity that is the paying customer can mandate their suppliers or partners that it requires data to be exchanged using the formers’ API as the paying customer typically has the power in that business relationship. When that happens, the API published by the other side is used less frequently.
Many companies report that the usage of their APIs has not been up to their expectations. This blog has outlined the most of the common reasons why this happens. As mentioned earlier, APIs are an important and useful technology and they succeed when offered as one of the many channels for data exchange and fail when promoted as API-only or API-first strategy, especially in complex customer data onboarding scenarios. Adeptia provides efficient and faster customer data onboarding with its Adeptia Connect business application. It allows APIs to be consumed faster by up to 80% by business users and analysts and not just developers or IT. Adeptia Connect enables self-service integration for business users and offers multiple protocols and channels for data exchange including files, forms, emails, web uploads, application connectors and real-time APIs to make organizations easier to do business with.