What is an API Product?

API Product? Does this sound strange? Not at all! With the rise of the API Economy where companies start to emerge offering API-based services, these services are in some cases the “only” product they have. Take the example of companies like Twilio and others. There are also companies that start to bundle API access together with traditional products, for example, Salesforce. You use the Salesforce CRM but the API comes with it and you can use it to integrate and extend the CRM. Bundling of products with APIs is actually the common practice these days.

Look at Google, most services have an API—all listed in the Google API console–and a User Interface (Google Search, Google Maps …).

Treating your APIs as a product

If you think about the fact that the API is your product, you realize quickly that it’s not only an IT topic that is in front of you. It’s way more! There is are multiple aspects like Marketing and Sales but also Product Management and Strategy. To run your API Product you have to ask a couple of questions and formulate a proper digital strategy.

• How do you package the service you plan to deliver?
  • Do you provide one API or multiple APIs?
  • Is your API part of another product?
  • What will be the API quota or rate-limit we can offer?
• What Quality of Service do you put inside this package and how do you measure and ensure it?
  • How do you monitor the service?
  • How do you measure the SLA you have with your client?
  • What should you API analytics solution look like?
  • Who should be the people monitoring the APIs?
• How do you advertise and market your service?
  • What is the marketing strategy of your API?
  • Which assets will help to adopt the API?
  • Do you need a developer evangelist promoting your APIs?
  • What is going to be the communication strategy including a communication channel for the product?
  • What will your API developer portal look like?
• How do you grant access to your APIs?
  • Do you invite people or do you want to let people sign up themselves?
  • Which terms and conditions do you need to have?
• What product lifecycle will you be able to apply?
  • How do you deal with required or introduced changes of APIs?
  • How do you communicate lifecycle changes?
  • Do you have an API lifecycle management strategy?
• What are the technical requirements?
  • Do you need an API Management platform?
  • Which solution is going to provide the right policy enforcement and API security?
  • What API analytics solution is going to help us get the insights into API Adoption, growth, and other metrics?
  • Is our technical platform able to scale and prepared for growth?

So where APIs have been an IT tool in the past, these days people realize that it takes more than exposing an interface. To be well prepared, a good approach is to embrace an API-first strategy.

Bundling multiple APIs into an API Product

In technical terms, all this means often is that multiple APIs have to be combined into one new API. This is referred to as “API Product,” whereas a better description would certainly be API composition or API bundling.

In some cases, sophisticated tools let you redact or modify the API definition making it fit for getting exposed to consumers. API Management systems provide these capabilities, moving the hazel of modifying the backend API directly and providing a simple way to proxy multiple APIs as one API to the front end. Some systems even allow you to disable or hide certain methods from APIs.

Continuing the API lifecycle

When the new API is ready for prime time, the next step is to create API pricing and subscription plans which contain one or multiple of these bundled APIs. These plans not only contain access to APIs, but also a defined quota of calls or data that are allowed.

This pretty much depends on the type of service. If the API is used to support sales transactions like an order processor used to process payments, then it’s quite normal that there is no quota but an API rate limit to protect the backend.

The intent is to allow consumers to process as much as possible over this interface. There are other scenarios where you are only allowed to consume a certain amount of calls or data and pay based on consumption.

Once this is finalized, the API lifecycle can continue with publishing these APIs into an API Portal for developers. But it does not stop here. Make sure people can sign up and access your service easily. Inside the API Portal, help, documentation, and guidance should be provided.

Chat support, forums, and news often complete the offering turning an API Portal into an e-commerce shop or Store Front-end if you like. Measuring the success, working on issues, and optimizing this experience is what is required to turn an API into a real product, your API Product.