Microsoft Azure API Management Policies

This is the second post of the Microsoft Azure API Management tutorial. See the first post – Introduction to Microsoft Azure API Management. This post describes about the advance

Policies define the rules for the incoming and outgoing API requests. See this link for the full API Management Policy Reference. Different policies are applied at different levels of the API Management. In order to define a policy go to Policies tab, select a Product or a API or an Operation based on what the policy could be applied, then drag and drop the policy template and fill the parameters. (I think Microsoft Azure will come with a good UI for doing this in the near future).

For example I’ve explained how to create a policy to limit the number of calls to the API. I have the same API I explained in the previous post – Introduction to Microsoft Azure API Management. Go to Policies tab select the Product and in the right hand side you will the list of policies. Since you we haven’t configured any policies yet the work area will ask you to create a policy for the API. Click ‘Add Policy File’. Then click on the <inbound> section of the XML. The position of the cursor is important based on which policy you want to add; in this sample we’re adding a call limiting policy then its obvious we should add in in the inbound section of the XML if you keep the cursor in other areas and try to add the call limiting policy the interface will react numb. Unfortunately if won’t tell you what’s wrong but simply you cannot add the policies. API Management Policy Reference will guide you get the knowledge about the usage of the policies.

Call Rate Limiting Policy


Once the policy is added you can see the policy template and it’s a matter of filling the blanks. Notice that this policy is applied in the Product level in the configuration, but it provides the granularity to control the calls to Operations level in the XML. I have added few inputs and the final policy looks like the following.

defined policy

The XML template is self descriptive. Here I have mentioned that only 10 calls could be made in 60 seconds from one subscriber (from one subscription key). And in that 10 calls Nebula Customers API  would handle 6 and again even those 6 calls are equally divided to 2 Operations. After editing the template we save the configuration. Then let’s check that in the Developer Portal.

too many requests

See the response when I try to make the 4th call to the operation it says me to wait for some time. I personally prefer this error message because it’s very helpful and developers can easily hook up any automatic retry call with an accurate timer event rather than randomly polling the service.

Content Serialization

Now let’s check another policy; notice that the API Management outputs the content in JSON as it is the default content format of our backend service. Suppose if I need the format in the XML  I can use the ‘Convert JSON to XML’ policy. Make additional note here that this policy could be applied at API or Operations scopes. So we should select the API and create a new policy configuration.


Since I have applied this policy at the API level all the Operations in the API will return XML. Let’s check that by invoking the same Operation we invoked in the previous scenario and we get the response in XML as expected.


There are plenty of Policies available as templates including CORS access, IP restriction and others. Try different policies to get know them better in the implementation. I think soon Microsoft Azure team will come up with a new user interface for the Policy management.