How can we improve Azure API Management?

Support expressions in calls attribute of rate-limit[-by-key] and quota[-by-key] policy of APIM

If the quota value can be an expression and dynamic, then it will much easier to implement dynamic quota in a single product. I want to set a per-subscription quota without create separate products for each of the subscription. Sometimes, we have requirement to increase quota for just a single subscription which force us to create a new product just for that particular user. Another case is that we want to provide capability to allow users to customize the quota value for ip/client-id throttling.

17 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Xiaomin shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    4 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
      Password icon
      Signed in as (Sign out)
      Submitting...
      • Everton Macedo commented  ·   ·  Flag as inappropriate

        Same here. We want to manage the quota/rate inside the user scope and not by product. It would make sense to extract this values from the user profile/claims

      • Santosh commented  ·   ·  Flag as inappropriate

        I support this idea. Dynamic quota policy would definitely help and easier to maintain with single product. If we have different limits for each subscription then using single product as below can solve the quota problem

        <quota-by-key calls="@(context.Request.CustomCallsforKey)" renewal-period="@(context.Request.CustomRenewalPeriodforKey)"
        increment-condition="@(context.Response.StatusCode >= 200 && context.Response.StatusCode < 400)"
        counter-key="@(context.Request.CustomKey)" />

      • Oliver Tomlinson commented  ·   ·  Flag as inappropriate

        I support this.

        Being able to set defined 'amounts' when creating a subscription would be great.

        A Developer might initially only pay for 10 requests a second, but then at some point in the future upgrade to 20, 30 or 40 requests a second.

        Yes we could achieve this right now by having 5 different products, but this would mean the developer would have to reintegrate against the API with the new ocp-apim-subscription-key which is a bad experience for the developer.

        Maybe the real answer here is to be able to migrate a subscription to a different products and preserve the ocp-apim-subscription-key?

      Feedback and Knowledge Base