Adding New Throttling Policies

API Manager admins can add new throttling policies and define extra properties to the throttling policies. Click the level of throttling that you want to add a new policy in to see instructions:

Adding a new advanced throttling policy

Advanced throttling policies are applicable to both APIs and resources. 

1. Log in to the Admin Portal using the URL https://localhost:9443/admin and your admin credentials.
2. Click Advanced Throttling under the Throttle Policies section. The existing set of throttling tiers are displayed. To add a new tier, click Add Tier.
   

3. Fill in the details required by this form and click Save once you are done. 
   

4. If you want to add throttling limits with different parameters to the conditions below, click Add Conditional Group.

   Note that if you want to add a header, query param or JWT claim condition, you need to set the <EnableHeaderConditions>, <EnableJWTClaimConditions> or <EnableQueryParamConditions> element to true (depending on which condition you need) in the repository/conf/api-manager.xml file.

   

   Condition	Description
   IP Condition	Allows you to set a throttling limit for a specific IP address or a range of IP addresses.
   Header Condition	Allows you to set a throttling limit to specific headers and parameters.
   Query Param Condition	Allows you to set a throttling limit to specific query parameters.
   JWT Claim Condition	Allows you to set a throttling limit to specific claims.

5. Turn on the required condition and enter a condition and value. 
6. Header condition and JWT claim condition values allow regex patterns to be defined. You can configure it to make either an exact match or a pattern match for the value using the regex values. For example,
   
7. Once done, click Add. You have added a new advanced throttling policy that can be applied to an API or a resource.

Adding a new application-level throttling tier

Application-level throttling policies are applicable per access token generated for an application. 

1. Log in to the Admin Portal using the URL https://localhost:9443/admin and your admin credentials.
2. Click Application Tiers under the Throttle Policies section. The existing set of throttling tiers are displayed. To add a new tier, click Add New Policy.
   

3. Fill in the details required by this form and click Save once you are done. 
   

4. You have added a new application-level throttling policy.

Adding a new subscription-level throttling tier

1. Log in to the Admin Portal using the URL  https://localhost:9443/admin  and your admin credentials.

2. Click Subscription Tiers under the Throttle Policies section. The existing set of throttling tiers are displayed. To add a new tier, click Add Tier.
   

   When you are going to add a new Subscription level throttling tier, you can see the existing list of subscription tiers in Subscription Tier List. In this list, you will find a tier named Unauthenticated which have a request quota of 500. This is a subscription tier which automatically applied when the authentication type of your resources is 'None'. That is, when you can invoke APIs without tokens. And this tier is not visiblie in the Throttling tier list of the application.

3. Fill in the details required by this form and click Save once you are done. 
   

   Given below is a description of the fields you find in the form:

   Field	Description
   Request Count/Request Bandwidth	The maximum number of requests/maximum bandwidth allowed to the API within the time period given in the next field.
   Unit Time	Time within which the number of requests given in the previous field is allowed to the API. This can be defined in minutes, hours, days, weeks, months or years.
   Burst Control (Rate Limiting)	You can define the request count/bandwidth per unit time on an addition layer by using rate limiting. This is usually a smaller number of requests/bandwidth for a shorter time span than what is enforced in the above fields. For instance, if there's a subscription level policy enforced over a long period, you may not want users to consume the entire quota within a short time span. Enforcing a rate limit protects the backend from sudden request bursts and controls the usage at a subscription and API level.
   Stop On Quota Reach	This indicates the action to be taken when a user goes beyond the allocated quota. If the check box is selected, the user's requests are dropped and an error response (HTTP Status code 429) is given. If the check box is cleared, the requests are allowed to pass through.
   Billing Plan	The available billing plans are Free, Commercial, and Freemium. An API is tagged/labelled as Free, Paid, or Freemium depending on its subscription tiers (e.g., Unlimited, Gold, etc.), which are the tiers selected when creating an API. Free - If all subscription tiers are defined as Free, the API uses the Free billing plan and the API is labeled as Free in the Store. Paid - If all subscription tiers are defined as Paid, the API uses the Commercial billing plan and the API is labeled as Paid in the Store. Freemium - If the API has a combination of Free and Paid subscription tiers, the API uses the Freemium billing plan and the API is labeled as Freemium in the Store. This labelling happens on the API Store only if monetization has been enabled. For information on how to enable monetization and how to tag subscription tiers, see Configuring API Monetization Category Labels.
   Custom Attributes	Custom attribute values are displayed as key value pairs on the API Store's API subscription page. The main objective of these fields are to provide more information regarding the tier to Application Developers at the time of API subscription. An example usage of custom attributes is API Monetization. See Enabling Monetization of APIs for more information on practical usage of custome attributes in the subscription tier.
   Permissions	You can allow or deny permission for specific roles.

4. You have added a new subscription-level throttling policy.