Capping IT Off

API is short for Application Programming Interface, it is a way to communicate with something without having to use the website or tool of the specific service. Often is about the exchange and manipulation of data (such as  most apps for twitter on iOS and Android use the Twitter API). Basically APIs are (becoming) the Ducttape of the Web and a vital part for its success.

There are many reasons for people to start with an API some of these are more business related and some of these are more technology related . Business related drivers to start with an API:

• Increase Brand awareness
• Allow people to use their own data
• Build goodwill with developers (starting a community)

Technology related drivers to start with an API:

• Solve programming problems with an API in mind can improve code quality
• Simplify internal reuse of data
• Allow others to extend the functionality of your application
• Allow alternate input mechanisms
• Unanticipated applications of your data
• Turn your service into a platform.

Things to keep in mind while maintaining an API

From a technology perspective there are several approaches on can choose to move forward with an API. However one of the most important things is that when an API is released the API is used by the service provider themselves internally (drink your own champagne) to make sure that the platform and your solutions keep in sync with regards to functionality. Also don’t change the API in a way that it breaks, which means that people who build on your API all of a sudden have solutions that don’t work anymore. Versioning therefore is very important.

Also important is to build for scalability, to keep an on eye on the metrics for the API (how often is it used, which methods are used most often, what is the fail rate, is there any peak usage), to keep in touch with the development community and to take part actively in this community. Also be conscious about paying or not paying developers for the work they do building on your API. Most often it is better to not pay the developers since they will build things out of passion and if somebody is building something on your API for free then you know your API is useful. Also consider an API never as finished and since you are working with developers on your API be sure to include or experiment with the latest developments since this audience expects you to do so.

For building an API there are four stages that impact the time to integration:

• Vanilla API: starting point of every API with just the functionality, not necessarily specifically written for a certain programming language (often SOAP or REST APIs).
• API wrapper: Wrapper in a specific language (ruby, PHP, .Net, C#) around your API so people can start using it in their favorite development language without having to write the complete wrapper by themselves. (Improves time to integration with around 50%)
• Documentation: documentation next to the Vanilla API and the API wrapper will decrease the time to integration even further especially when the documentation has several examples which can be reused. (Improves time to integration with around 20%)
• Share kit: an easy way to share certain functionality from the API often on a copy-paste basis (such as the embed functionality that YouTube is offering). Offers less (or in some cases even no) room for customization though it offers the shortest time to integration (sometimes even just minutes)

APIs should be free, or at least free for a certain level of usage. APIs often extend a core service which is already being monetized and API extends this and enables the core service to be used more and most likely also to be able to earn more money. Monetization via the API is often done just to cover costs, not make additional money. So the main business model is often just to make sure costs are covered and in some cases it could happen that there is money to be earned with an API.

Common business models for APIs:

Artificial Scarcity

Rate limiting

The API itself is free; however when you go beyond a certain number of transactions a fee is imposed. This fee is the way to cover the costs for the increasing usage (and required scalability) of the API though it can also be used as a way to discourage sloppy programming and make sure people are using the API efficiently also. Also it can be a way to make a divide into people who are using the API just as a hobby and people who are using the API for something they might earn money with and are willing to invest in.

Data limiting

Next to rate limiting there is also data limiting the core for some business models. Developers can only get a certain amount of data per API call or in a certain period of team. Again this could be a way to cover costs for increasing usage of the API, or it can be a way to divide people in two groups: the ones that are likely to make money based on your API and are willing to invest in it and the ones who are using it is a hobby.

Functionality limiting

Another way to create artificial scarcity for supporting your business model is by limiting functionality. Often basic functionality is provided for free (such as read access to data) and more advanced functionality (such as update and insert actions) are only available for paid users. This is again a model that helps finance growth and helps to differentiate types of users as well as make it easy to scale for different types of uses.

Other

SLA / quality

Instead of creating artificial scarcity another way to support your business models can be done via differentiating in service level agreements or quality in general. When developers pay more they get a better service (short support window, increased uptime, faster response times etc), when developers are not paying they get the basic API which is often maintained on a best effort basis (which shouldn’t mean that is should have very high response times and downtimes without an end though).

Transaction free / revenue sharing

Another way to earn money via the API is a shared revenue model. Based on the success the developer has with the API (for example a payments API) he has to pay a small fee per transaction (similar to what Amazon and Apple are doing on their platforms). This way you have a shared interest in making sure the API is successful.