Update: Microsoft will be moving away from UserVoice sites on a product-by-product basis throughout the 2021 calendar year. We will leverage 1st party solutions for customer feedback. Learn more here.

API Management

Microsoft Azure API Management is a turnkey solution for publishing APIs to external and internal consumers. Quickly create consistent and modern API gateways for existing backend services hosted anywhere, secure and protect them from abuse and overuse, and gain insights into usage and health. Plus, automate and scale developer onboarding to help get your API program up and running in no time.

  • Hot ideas
  • Top ideas
  • New ideas
  • My feedback
  1. Policy to remove X-Forwarded-For header from outbound requests

    When using API Management as an outbound forward proxy, the X-Forwarded-For header exposes internal IP addresses via this unalterable header. Currently, APIM will always append it's own internal IP address when sending a request to the backend. "set-header" on the inbound policy does not delete the XFF header for the outgoing backend request from APIM.

    8 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  2. Generate APIM Policy code dynamically to improve re-usability

    Currently, APIM Policy expressions can be used in named values which helps in repetitive computations for various policies. It would be great if policy code can also be generated dynamically, store in a variable and invoke that variable wherever required. (same like dynamic sql queries where we generate queries dynamically and invoke it as required ).

    Ex: We have to use below code snippet multiple times in the policy.

    <choose>
    <when condition="@((bool)context.Variables["IsRequestEnabled"] == true)">
    <set-variable name="message" value="Invalid request with 401-Unauthorized status" />
    <set-variable name="status" value="401" />
    <set-variable name="tag" value="APIM.Policy.Exception" />
    <set-variable name="level" value="2" />
    <!-- Log invalid request details -->…

    7 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  3. Allow wildcard key in cache-remove-value policy or implement cache-remove-pattern

    Then we could with ease, via policy, selectively flush the cache after a post/patch/delete. Instead of now having to access/flush (redis) from the backend code.

    7 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  4. Increase renewal period limit of 'rate-limit-by-key'

    Increase the upper limit on' renewal period' attribute of 'rate-limit-by-key' policy. Currently it accepts maximum 300 seconds.

    7 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  5. Policies in YAML

    YAML is fairly popular and easier to produce than XML, having support for YAML in policies would lower the policy sizes by reducing amount of text required to define a policy. It would also align with OpenAPI v3 specs in YAML.

    7 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  0 comments  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  6. Improve the authoring experience for policy expressions

    There are several other requests for e.g. improving the reusability of policy expressions. And that is all good. But if you think about the experience of working with policies - especially from a devops perspective, it is rather clunky as a whole. Here's what building a policy expression essentially is now: author code by trial-and-error using a web-only interface by injecting pseudo-C# code inside an XML document.

    I would much prefer a way to construct testable policy expressions using proper developer tools (also outside the admin portal) with full code completion and deploy them as reusable artefacts into the API…

    7 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  7. Make Tags available on the context

    Make the API Tags available on the context, so you can make conditional steps in your Global or Product Policies based on the Tags on the API.

    For example, this way we could do the correct authorization in the Global Policy based on whether the API is tagged with an "OAuth" tag.

    7 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  8. Providing policy to control when the subscription check happens

    We are providing the client with an API key. The subscription key is a part of the API key. We enabled the subscription required flag from settings. However, doing that executed the subscription check before any part of the policy is invoked. We were hoping to have more control over when the subscription check happens. We have inbound policies written that obtain the subscription key from the API key and then we set the Ocp-Apim-Subscription-Key. We want the subscription check to happen after this point. Currently, it's forcing us to provide the clients with 2 keys, our API key, and…

    6 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  9. CORS headers

    When CORS policy is configured all responses should return CORS headers. Currently if a 4xx response is returned, headers are not returned.

    6 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  0 comments  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  10. Policy to Log to Trace

    It would be nice to have a policy that lets me write a log entry to the trace log so if something is going wrong more detail can be seen similar to context.Trace but without needing to use some other policy to make it happen.

    Example:

    <log-to-trace message="@(string.Format("Request Body: {0}", context.Request.Body.As<string>()))" />

    5 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  11. Block IP's after N incorrect subscription keys

    Currently, subscription key validation takes place before policies take effect. This limits being able to manage subscription key access via policies.

    It is not currently possible to develop a policy that would block an IP or IPs after too many invalid subscription keys. In an environment where a rate limit policy would not otherwise be appropriate, this could potentially allow APIM to be flooded with a bunch of requests with invalid keys.

    To be able to enforce this at the moment requires some sort of relay middleware, or building out manual subscriptions (not via APIM's) and enforcing those via policy.

    5 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  12. cors

    Currently if default CORS policy is used in , outbound policy is not executed. This doesn't allow to attach HSTS headers to the response from OPTIONS method call. That forces us to implement custom CORS policy in order to comply with our security requirement. Would be nice to have the design changed.

    4 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  13. Allow conditional cors policy in the <inbound> policy section rather than restricting it to use only once in the <inbound> section.

    Allow conditional cors policy in the <inbound> policy section rather than restricting it to use only once in the <inbound> section. The desire state is in the attachment.

    4 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  14. Add a loop policy

    Add a policy that allows a loop, e.g. a for, while, do or foreach loop construct.

    Concrete case: for each item in an array in the input, the CountryCode needs to be translated to a Country by calling our CountryCode-to-Country api and while you can loop in a C# code block, you can't make HTTP-requests from a C# code block and while you can make those request using a Policy, you can't loop with a Policy, so you're stuck.

    4 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  15. Support HTTPS in "Set HTTP proxy" policy

    Hello,

    Currently "Set HTTP proxy" policy in Azure API Management only supports HTTP traffic (Not HTTPs). We have a requirement to proxy traffic to an external security system for further introspection or validation and the idea of passing unencrypted traffic isn't good.

    Is there a plan to introduce HTTPs support?

    4 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  16. Allow deletion of HTTP headers using name pattern-syntax in set-header policy

    As of today, headers in a HTTP Request or Response can only deleted individually by specifying their exact name in a set-header policy element. While this might work well in simple cases, it will become cumbersome and hard to maintain when multiple headers should be removed based on a certain naming pattern or a certain base name.

    Example 1

    Due to security reasons and in order to avoid information leakage, a given API should not return any proprietary headers starting with X-. This cannot be expressed in a sane way as of today. There needs to be one set-header

    4 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  17. Policy to remove header

    Cannot remove below headers with "Consumption (Preview)" price tier:
    X-Powered-By
    X-AspNet-Version
    Set-Cookie

    Below is the detail step I replicate the issue:
    I'm trying to remove some headers in the response but they are still there.

    I did follow http://www.ithero.nl/post/2018/03/31/Using-policies-in-API-Management-to-remove-response-headers-from-the-backend-Web-API-that-leak-information.aspx

    to remove 'Set-Cookie' and 'X-Powered-By' by adding these lines to policy:
    <set-header name='X-Powered-By' exists-action='delete' />
    <set-header name='Set-Cookie' exists-action='delete' />
    but it's no hope.

    Currenty I still got these info in the headers:
    Cache-Control →private
    Transfer-Encoding →chunked
    Content-Type →text/plain; charset=utf-8
    Content-Encoding →gzip
    Vary →Accept-Encoding
    Server →Kestrel
    X-AspNet-Version →4.0.30319
    X-Powered-By →ASP.NET
    Date →Thu, 18 Apr 2019 05:01:14 GMT

    4 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  18. Use NamedValues within C# expression

    In the existing implementaiton it is not possible to directly access data from NamedValue table within C# policy expressions, for ex: a code like "var x = {{dataStoredInNamedValue}}" will not work. The only way to access the namedValue it appears is to use XML Policy templates, for ex: '<set-variable value="{{some-value}}"/>'. So to use the data stored in namedValue, it should be first fetched using <set-variable/> and later this variable need to be accessed in C# expression, this is roundabout, and there should be a direct way to access these values.

    4 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  19. allow group

    Allow restricting groups to specific operations vs per api. Maybe a policy editor entry?

    4 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  20. validate-client-certificate policy should not be limited to only 10 identities

    When using the validate-client-certificate policy in APIM, I get an error when adding more than 10 identity elements to the identities.
    The documentation doesn't mention such limitations:
    https://docs.microsoft.com/en-us/azure/api-management/api-management-access-restriction-policies#validate-client-certificate

    Is there another way to do this?

    My Policy looks like this

    <policies>
    <inbound>
    <base />
    <validate-client-certificate validate-revocation="true" validate-trust="true" validate-not-before="true" validate-not-after="true" ignore-error="false">
    <identities>
    <identity common-name="common_name1" />
    <identity common-name="common_name2" />
    <identity common-name="common_name3" />
    <identity common-name="common_name4" />
    <identity common-name="common_name5" />
    <identity common-name="common_name6" />
    <identity common-name="common_name7" />
    <identity common-name="common_name8" />
    <identity common-name="common_name9" />
    <identity common-name="common_name10" />
    <identity common-name="common_name11" />
    </identities>
    </validate-client-certificate>
    </inbound>
    <backend>
    <base />
    </backend>
    <outbound>
    <base />
    </outbound>
    <on-error>
    <base />
    </on-error>
    </policies>

    3 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  • Don't see your idea?

Feedback and Knowledge Base