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.

23 votes
Sign in
Sign in with: oidc
Signed in as (Sign out)
You have left! (?) (thinking…)
Xiaomin shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: oidc
Signed in as (Sign out)
  • Robert Abraham commented  ·   ·  Flag as inappropriate

    Regarding my suggestion below, another approach would be to define groups that are associated with a specific rate limit, and have keys be members of one defined group.

  • Robert Abraham commented  ·   ·  Flag as inappropriate

    We are looking to rate limit IOT devices, owned by our customers, that send data to our servers. The data would be sent via REST requests, and the key that the rate limit would be applied to would likely be in a header.

    We would like to be able to apply a separate rate limit per key. We don't currently have that ability with policy statements like "rate-limit-by-key", as that only allows us to assign a global rate limit per header name, rather than header value.

    I can imagine a separate interface in APIM's Portal UI that allows for key management. In that interface, we'd be able to generate a new key, and define its rate limit.

  • 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