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.

How can we improve Azure API Management?

You've used all your votes and won't be able to post a new idea, but you can still search and comment on existing ideas.

There are two ways to get more votes:

  • When an admin closes an idea you've voted on, you'll get your votes back from that idea.
  • You can remove your votes from an open idea you support.
  • To see ideas you have already voted on, select the "My feedback" filter and select "My open ideas".
(thinking…)

Enter your idea and we'll search to see if someone has already suggested it.

If a similar idea already exists, you can support and comment on it.

If it doesn't exist, you can post your idea so others can support it.

Enter your idea and we'll search to see if someone has already suggested it.

  • Hot ideas
  • Top ideas
  • New ideas
  • My feedback
  1. Log custom traces to Application Insights

    Provide a policy to log custom traces to Azure Application Insights, similar to the log-to-eventhub policy.

    97 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    planned  ·  4 comments  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  2. 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.

    4 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  3. Allow the creation of custom API templates with predefined policies

    Allow custom templates to be created, and made available for selection via the API creation page (see attached), with predefined policies. This will improve the user experience where the requirement is to have several API's based on the same boiler plate policies. Product policies could be used but require all API's to be assigned to the same product which does not give flexibility in restricting access to the API's

    18 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    3 comments  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  4. Add a "go to on-error" policy

    The policy should transition control flow to the "on-error" section and be customizable with error details.

    6 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  5. Making named values a true secret

    I want to be able to create a named value and store a secret that cannot be retreived by anyone. Right now these named values can be read by anyone in the portal. We want to make them completely invisible after they are filled out.

    3 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  6. Making named values a true secret

    I want to be able to create a named value and store a secret that cannot be retreived by anyone. Right now these named values can be read by anyone in the portal. We want to make them completely invisible after they are filled out.

    3 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  7. Policy tag directory

    Have a comprehensive directory that has all of the tags that can be used in the policy XML.

    An example is have documentation of the <when> tag regarding which tags can be nested within and which attributes it accepts.

    I seem to be unable to find any resource that has detailed documentation on these multi-use tags.

    Thank you

    1 vote
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  8. Add comment to policies

    Before the possibility of form based editing for Allowed IP addresses in the API management policies, We could put comments in the code body.

    With every IP address we whitelist we also like to keep track from who that IP address is. Before we did that with comments. Currently commenting in the policies body is no longer possible. all comments placed here will be deleted once you save it.

    Commenting is only possible in the header.

    It would be useful to have an extra field next to the policy. This field can be used as a comment field.

    When entering…

    18 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  9. 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

    1 vote
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  10. Allow backend call details in "context" interface

    It would be very usefull to have access to backend call details via a new context "backend" interface so we could have access to "status code", backend url, call duration...
    In fact all that could be usefull to analyse "backend calls" in outbound policies.

    1 vote
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  11. Add support for custom user attributes

    It would be nice to add support for extending the user attributes beyond the basics in place now of name, email, etc. In cases where the user is associated to a downstream (back-end) entity that is identified differently from any of the existing fields, there isn't a way to do this without corrupting the "Notes" fields. It would be nice if Administrators can extend the user schema to contain custom attributes that can be fetched from within policies.

    6 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  12. Extend support for .net x509 in policies

    When working with certificates, it would be really useful to extend the .net api surface so to include X509Chain and related classes (so to control the validation policy) and also the System.Security.Cryptography.X509Certificates.X509NameType object so to extract easily a CN from a certificate (for example).

    41 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  1 comment  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  13. 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…

    4 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  14. API versioning with header doesn't work for APIs with CORS policies.

    We have enabled versioning of APIs using a header 'api-verion'.
    We also have enabled CORS policies on the API.

    The problem that we have is when a CORS pre-flight request (OPTIONS) is sent to API by browser the required `api-Version` header is not present and thus a 404 is returned from API-M and we receive a CORS Failure in the browser.

    4 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  15. 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.

    4 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  16. validate-jwt openid-config url attribute should support expressions

    I see this was declined a year ago but the alternative is not a good solution. ref: https://feedback.azure.com/forums/248703-api-management/suggestions/31936303-support-expressions-in-openid-config-url-of-valida

    Say I have 2 API developer accounts and for each one I have a document in Cosmos DB with extra data about each developer. In here I have an open ID configuration URL so that these developers can use their own authentication tokens to connect to my API. As a first step in all policies, after I have retrieved the developer data, I use the validate-jwt policy passing in the url. Ideal scenario. Doesn't work.

    Now looking at the alternative:
    I duplicate…

    13 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  17. Use valid xml to configure policies.

    In your examples one can find lines like this one:

    `<set-variable name="isMobile" value="@(context.Request.Headers["User-Agent"].Contains("iPad") || context.Request.Headers["User-Agent"].Contains("iPhone"))" />`

    If you try to validate this xml, you will find out that those double quotes inside of the value attribute are not allowed.

    1 vote
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  18. Return status code 405 instead of 404 when wrong method is used

    Defining an API involves creating the resources and the allowed methods for each resource. When invoking the operation (accessing the resource) with a wrong HTTP method (for example, PUT instead of GET), the API Management service returns a 404 Resource Not Found instead of a 405 Method Not Allowed. Passing an OWASP test implies to return the correct code (https://www.owasp.org/index.php/REST_Security_Cheat_Sheet#HTTP_Return_Code).

    Is it possible to return this code with API Management right now? Will it be included in future releases

    24 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  19. Enable WS-Security for SOAP backends

    In a REST to SOAP scenario where the backend demands the SOAP message to be signed using a certificate, it would be great if there were policies that could generate the whole message based on the contents of the body. Right now one can build the SOAP XML message using a liquid template but then the task of generating the security headers is hard (and I really don't know how to generate them). For example:

    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/&quot; xmlns:web="http://webservices.myweb.com">
    <soapenv:Header><wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd&quot; xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
    ......<wsse:BinarySecurityToken EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary&quot; ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3&quot; wsu:Id="X509-123456">generated_token</wsse:BinarySecurityToken>
    <ds:Signature Id="SIG-65D54B60823432DD6615040826919135"…

    51 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    4 comments  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
  20. Upgrade XSLT transformation policy to XSLT 3

    API Management currenly only supports xslt 1.0. Can it be updated to XSLT 3.0 so it will enable transforms with both xml AND json. This will be very powerful as currenly xml <-> json interactions require lots of xslt template code.

    12 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  0 comments  ·  Policies  ·  Flag idea as inappropriate…  ·  Admin →
← Previous 1 3
  • Don't see your idea?

API Management

Feedback and Knowledge Base