This documentation is for WSO2 API Manager 2.1.0. View documentation for the latest release.

All docs This doc
Skip to end of metadata
Go to start of metadata

WSO2 API Manager admins can add new throttling policies and define extra properties to the throttling policies. To get started, click the level of throttling that you want to add a new policy to:

To make changes in the throttling configurations, set the EnableAdvanceThrottling parameter in the api-manager.xml file. This parameter is set to true by default. If you set it to false, you only see the available tiers.

Adding a new advanced throttling policy

You can add advanced throttling policies to both APIs and resources.

  1. Sign in to the Admin Portal using the URL https://localhost:9443/admin  and your admin credentials (admin/admin by default).
  2. Click Advanced Throttling under the Throttle Policies section to see the set of existing throttling tiers. 
  3. To add a new tier, click Add Tier.

  4. Fill in the required details and click Save

    Request Count and Request Bandwidth are the two options for default limit. You can use the option according to your requirement. For example, If your using API for File sharing, Data transmission you can use request bandwidth option and limit the data bandwidth for given time unit.

  5. 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 JSON Web Token (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.

    You can add Description about condition group by click Sample description about condition group under Condition Group.

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

    Conditional group Execution policy used only for that condition. For example, If you add IP condition and set request count as shown in above diagram then only 5 requests allow per 1 minute using that IP condition. Any request comes with false condition(Outside that condition) taken to the default limit.

  6. Turn on the required condition and enter a condition and value. you can throttle based on header condition. 
  7. 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,

    Claim name : Name of the JWT Claim
    Eg : "iss" - The issuer of the JWT, "" - Context of the API, "" - API version

    Claim value : Value to be checked in the corresponding claim. (allows regex patterns as well)

    Invert condition : Whether to take the throttle decision based on the equality of the values.
    Eg : If the claim name is "iss" value is "wso2" and "invert condition" is off - Requests having "wso2" as "iss" claim will be throttled.
    If the claim name is "iss" value is "wso2" and "invert condition" is on - Requests not having "wso2" as "iss" claim will be throttled.

  8. Once done, click Add.

You have added a new advanced throttling policy. You can now apply it to an API or a resource.

You can configure multiple conditional groups when defining a tier for advanced throttling policies. For example, Its possible to apply IP based throttling and query pram condition both in one advanced policy tier.

Adding a new application-level throttling tier

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

  1. Sign in to the Admin Portal using the URL https://localhost:9443/admin and your admin credentials (admin/admin by default).
  2. Click Application Tiers under the Throttle Policies section to see the set of existing throttling tiers. 
  3. To add a new tier, click Add New Policy.
  4. Fill in the required details and click Save

You have added a new application-level throttling policy.

Adding a new subscription-level throttling tier

  1. Sign 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. 

    The Unauthenticated tier has a request quota of 500. This subscription tier is automatically applied when the authentication type of your resources is None. That is, when you can invoke APIs without tokens. This tier is not visible in the application-level throttling tier list.

    The Unlimited tier is available only as a WUM update and is effective from 6th March 2018 (2018-03-06). For more information on updating WSO2 API Manager, see Getting Started with WUM.

  3. To add a new tier, click Add Tier.

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

    Given below are the descriptions of the fields you find in the form:

    Request Count/Request BandwidthThe maximum number of requests/maximum bandwidth allowed to the API within the time period given in the next field.
    Unit TimeTime 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 ReachThis 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 PlanThis field only makes sense if you have API Monetization enabled. 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 labeling 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 AttributesYou can choose to display addtional information about tiers using custom attributes, during custom implementations. 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 custom attributes in the subscription tier.
    PermissionsYou can allow or deny permission for specific roles. Once permission is denied to a role, the new subscription tier that you add here will not be available to that role in the API Store.

    You have added a new subscription-level throttling policy.

  • No labels