In the modern, highly computerized economy, API clients often generate more volume and value than regular customers. For example, in the stock market, API clients create up to 90% of the volume. The business that can provide better API has a significant competitive edge. But too often, public APIs are ugly duckling among all the products offered to the clients. 

Our company delivered many successful APIs to our clients and helped to improve many existing APIs. At the very beginning of this business, we got our first API related contract, we started to collect metrics, and the initial impression was shocking: 

• Up to 80% of first-time users couldn’t successfully incept API. That completely scared away the most of the users unless they had no choice and ultimately had to use this API.
• Up to 90% of all support requests were about the implementation of simple technical tasks. 
• The lead time before the developers started to implement the business side was 2 to 10 weeks.
• The delivery time of a typical API-based product was 4 to 25 weeks. 

That was an unbelievable amount of time and resources wasted on both the client and the provider side, the time and resources that may be used to create real value. 

The problem comes from the fact that API is a mix of a business product and a software development tool. So, business clients typically have issues with the technical side of API, and programmers have problems with the business side of API. Therefore, adaptation and usage of API are needlessly complicated. Value generation is significantly delayed for both the user of API and the provider of API. For the API provider, such a dual nature of API also creates impediments to provide a praiseworthy API. The business process owners cannot correctly assess the problems of developers who use API, and the developers (who, sadly, too often are the only responsible party for API) cannot correctly assess the business needs. 

When we first experienced these problems, we analyzed a few APIs we considered successful, and we analyzed the process of inception of business API by the clients. We found that the number one secret of creating a valuable API is to make every single piece of it oriented to deliver maximum business value. API should not offer a set of tools that somehow may be applied by the customer. Instead, API must provide a comprehensive and efficient way to solve customer’s business problems. An ideal API developer must design API that way so API itself, the documentation, the set of the samples, and the way how API is supported – all of these must answer one question: how the customer can solve its problem most efficiently and effectively. API inception by the customer must be as easy as taking an example of solving the customer’s problem, and a minimal adjustment of solution parameters that may be performed by an ordinary user.

In our first contract, we had to:

• Redesign the whole legacy API completely, having “the user will solve these problems with our API” approach in mind instead of “here is a great set of perfect tools that the user may want to apply… somehow”;
• Create new documentation and example set, enriching it with business domain description and typical usage scenarios;
• Organize a new support process so the support team can help to find the proper solution for the business problem rather than purely explain how to write a piece of code.

In 6 months, our metrics demonstrated that:

• Up to 80% of all API downloads resulted in further use (raise from 20%). 
• Up to 70% of clients were able to incept API without any additional help from support (raise from 10%).
• 80% of customer requests now were about solving the real business problems of the clients (raise from 10%). 
• The rest 20% of technical questions were typically resolved in minutes by referring the proper example or the section of the documentation (80% time reduced to answer similar issues). 
• 99% of clients were able to start business development in the first week of API inception (2 to 10 times improvement). 
• 50% of clients were ready to start business development in the FIRST DAY of API inception (14 to 100 times increase). 
• The delivery time of typical API-based products went down to 2 to 4 weeks (one or two sprints, or 2 to 5 times faster).

It may sound like API development became too expensive because of all these new activities. Surprisingly, it wasn’t. We were surprised that these changes made further API development less expensive. Nowadays, the prophets of DevOps would easily explain it, but a long time ago, it was a real discovery for us:

• Business-oriented API becomes way more natural to modify, modernize, and deliver updates to the clients, especially in the modern cloud-based, microservice architecture. 
• It allows us to create naturally verifiable via well-established business rules automated testing cases that skyrocket development by reducing the most expensive part – complex debugging. 
• It naturally involves the support team into requirement management and made the API development genuinely customer-driven. 
• And this highly improves clients’ trust and loyalty to API and the whole API provider as a business partner.

This approach may sound like a long and complicated task, but it may and must be performed in an iterative, step-by-step manner. The iterative process helps to resolve most painful client problems as soon as possible, build confidence and trust between the clients, API developers, and, last but not least, the API sponsor/provider. 

About Us

We are providing APIs to our customers for 20 years. Our APIs in numbers:

• Over 10,000 companies and almost 1 million end-users use software based on API provided by our company. 
• Over 30,000 developers are using our APIs. And we could count only whose who contacted to get some support. 
• Our APIs consist of 1,500,000 lines of code on production. This number is comparable to the whole Linux 2.2 kernel or F-22 Raptor software.
• Over 20 years, we created over 50,000 business-oriented examples for the public codebase for our APIs.  
• We provide our APIs for:
  • over a dozen programming languages and development environments (including C, C++, C#, Java, Python, Lua), 
  • all three primary desktop OS (Windows, Linux, and macOS), and two primary mobile OS (Android and IOS).

Should you have any questions, please do not hesitate to call us. We offer a free basic review of the current state of your API on the base of publicly available distribution, documentation, and support materials. We also provide the full stack of service from API redesign to end-user support.