Why do I need API Management ?

API Management

API management is defined as a process of publishing, documenting and overseeing API in a secure, scalable environment

The activities within the scope of API management are:


Lifecycle management


An API lifecycle goes through multiple stages. 

  • Build
    Design and coding of API

  • Published
    Once the API is tested, it becomes available for application developers to use in their apps

  • Deprecated
    at some point the API provider may need to change the API. Instead of making in place updates to API, it is suggested that the API provider create a versioning strategy. In a typical strategy, when a newer version is released, the older version needs to be marked deprecated. An API version marked as deprecated stays available for a limited period of time for application developers to transition to the new version. The deprecated API is not available to the new application developers and hence forced to leverage the newer version.

  • Retired 
    Once the deprecation period expires the version of API is marked retired and may be physically removed from the API infrastructure.

The API provider MUST manage the lifecycle of APIs in a desciplined way by way of defining processes and tools. Some but not all API management platforms provide lifecycle management features.




This here refers to the productivity of the API developer and the Application developer. 

API Developer Productivity may be enhanced by:

  • Defining the API development processes
  • Standardizing the implementation platform & patterns 
  • Adopting frameworks, best practices & guidelines

The API provider may enhance the productivity of the Application developers:

  • Providing API documentation
  • Automated provisioning i.e., a way by which an app developer may get access keys for the API
  • Support for app development e.g., SDKs, sample code




The APIs provide a controlled access to the enterprise resources (and data) that otherwise are protected by way of firewalls and other means. Unfortunately the API also creates an attack surface for the hackers. It is common for hackers to launch functional attacks against the enterprise API by leveraging the vulnerabilities exposed by API. The best practice to handle such attacks is that the API provider test their API for detecting vulnerabilities and weaknesses in the API.

Another essential aspect of the API management is Auhentication & Authorization. Multiple standard schemed are available for A&A that may be leveraged by the API provider. Building any security scheme in the code of API will make the API code difficult to maintain and complex. Changes in the security scheme applied to the API would require changes to the code and redeployments which would impact the API consumers. It is suggested that the API provider externalize the implementation of the A&A with regard to the code.

API Management platforms support standard security schemes that may be applied to the proxies. Typical authentication mechanism is the API key/secret method and OAuth (1.0 & 2.0) for authorization.


Traffic management


There are three reasons why the API provider must manage the traffic.

  1. Response time consistency
    The maximum throughput achieved for an API is determined by the weakest component in the API call path length. For example if an API is accessing the database that can handle a maximum of 200 queries per second, then the API can take a load at a maximum rate of 200 calls/second. If the call volume exceeds the maximum allowed then the API consumers will start to see a performance (or response time) degradation and failures. In order to provide the consumers a consistent API response time from API perspcective the API consumer can restrict the number of calls that each consumer can make. So in the case of this example, the total calls from all of API consumers will be restricted to less than 20 calls/second. API management platforms support this aspect by way of Rate limiting policy.

  2. Service Level Agreement
    An API is a contract between the provider and the consumer. To level set the expectation of the consumer it is suggested that the API provider offer a well defined  Service Level Agreement (SLA) to the consumer. At runtime the provider must ensure that both the consumers and the provider are fulfilling their end of the SLA. API management platforms (typically) do not have SLA as an inbuilt construct but they do support the elements of the SLA such as Rate Limiting and QuotaFor derived elements such as average response times, these platfoms provide reporting features that may be leveraged by the provider for managing the SLA
    • Maximum Rate                     E.g., 2 calls/second
    • Quota                                  E.g., 200 calls/day
    • Average Response time        E.g., under 2 seconds
    • Support                                E.g., Email only
  3. Protecting the backend
    One of the most common form of attack is the Denial Of Service attack in which the attacker sends a continuous stream of requests to the API and that leads to degradation or even crashing of the backend systems or resources. To protect the backend against such attacks the API provider can rstrict the number of calls to the backend. The way API management platforms restrict the number of calls is referred to as the Spike Arrest.





An API provider must continuously analyze the usage of their API for the following reasons:

  • Service improvement
  • Business support

The analytics collected can for API may be categorized under the following categories:

  • Metrics
    These are typical key performance indicators (KPI) captured for getting visibility into the performance, behavior and service level agreement (SLA) conformance. Almost all API management platforms support collection of the typical metrics elements shown below.
  • Visbility
    Usage reports for the API provide the insight into how the API are being used from multiple aspects e.g., usage by API consumer, by geographical regions, by device types. These reports are techincal in nature and are mostly geared towards the API provider's technical teams. The transaction reports provide the business insights to the stakeholders. These reports require some level of coding in the API and such features are normally unavailable on API management platforms.




There are three types of API consumers namely Internal, External & Partner. The quality of service offered to the three types of consumers is not the same. The typical parameters that may vary for the API product from QOS perspective:

  • Quota                    
    E.g., Internal consumer can mke unlimited calls, External consumer can make 2000 calls / day

  • Rate Limit              
    E.g., Internal consumer has no restriction, External consumer can make a max of 20 calls / second

  • Security                
    E.g., Internal consumer OK to use OAuth2.0 with grant type = End User Credentials
           External consumer MUST use OAuth2.0 with grant type = Authorization Scope Grant


API provider MUST design the API product targeting specific consumer's needs as well as the relationship with the consumer. In the case of monetized APIs, it is common for providers to create tiered model similar to the one below:

  • Free Tier              
    {Quota: 200 calls/month, Rate: 5 calls/sec}         Subscription price = $0

  • Gold Tier            
    {Quota: 5000 calls/month, Rate: 20 calls/sec}        Subscription price = $50   per month

  • Platinum Tier      
    {Quota: 50,000 calls/month, Rate: 100 calls/sec}   Subscription price = $200 per month


Another aspect of the API product creation is the bundling of multiple related API in a single product. This provides a way for the API to provider to create bundles that are geared toward fulfilling the needs of different consumers. Here is an example:

  • Internal Tier        
    {Customer API, Transaction API}            
    Internal App developers can access the customer & transaction information

  • External Tier      
    {Customer API}                                      
    External App developers can access only the customer information


Most API Management platforms support this product creation mechanism for API. As a good practice the API provider should keep in mind the needs of the specific consumers to design their API products.




API monetization refers to the creation of new revenue streams enabled by API. The revenue streams may be:

  • Direct                    
    API provider charges for the use of API E.g., Amazon/AWS, Twilio

  • Indirect                  
    API generates the revenue indirectly E.g., additional sales channel on external partner's website;used by Best Buy


The monetization aspect of API has more to do with business than technology. The API provider must work with business stakeholders to understand the opportunities and for creating the business model. Broadly there are 4 API monetization models:

  1. Free                      
    Provider gives access to App developers for Free E.g., Google, Facebook API

  2. Freemium            
    Provider gives free access to promote trial but requires the App developer to pay for the premium tier

  3. Developer pays    
    This is similar to #2, the developer must pay for use E.g., AWS

  4. Enterprise pays    
    The API provider pays E.g., Best Buy may pay the app developers for selling or advertising their products on apps and websites


As the technology expert the API provider's technology teams needs to work with the business to implement the monetization functions such as the subscription management, reporting, billing etc.

Most API management platforms do not support the API monetization out of the box. Please check with specific platform vendor to understand how monetization is handled on their specific platform.