Configure rate limits for different API operations in Azure API Management
Azure API Management (APIM) is one of the PaaS products offered by Azure which allows you to publish, manage, secure and monitor APIs. One of the features of APIM is the ability to control the traffic to your APIs using policies such as rate limits and quotas.
Rate limits are policies that prevent API usage spikes on a per subscription or per key basis by limiting the call rate to a specified number per a specified time period. Quotas are policies that enforce a hard limit on the number of calls that can be made to an API within a billing period.
In this blog post, we will focus on how to configure rate limits for different operations in APIM using the `rate-limit-by-key` policy. This policy allows you to define expressions to identify the keys that are used to track traffic usage. You can use any arbitrary string value as a key, such as IP address, subscription ID, etc.
Scenario
Let's say you have two operations in your API: Operation A and Operation B. You want to apply different rate limits for each operation based on your business requirements. For example:
- Operation A has a rate limit of 5 calls per minute
- Operation B has a rate limit of 5 calls per 30 seconds
You also want to make sure that the rate limits are independent by operation, meaning that calling one operation does not affect the counter for another operation.
Solution
As per our official document, operations in APIM (regardless API) use a single counter for all scopes at which the policy is configured. Say, if you make 2 calls to one operation, these calls will be counted towards the single counter used by all of the operations.
To achieve this scenario, you need to use the `rate-limit-by-key` policy with an expression that produces unique values for different operations. One way to ensure that is to add `context.Operation.Id` to the expression.
The `context.Operation.Id` property returns a unique identifier for each operation in your API. By concatenating it with another value such as IP address or subscription ID, you can create a key that is specific for each operation and each caller.
Here is an example of how you can apply this policy at the inbound section of your API:
To test this solution, you can use any tool that can send HTTP requests such as Postman or curl. You can also use Azure Portal's Test console feature.
Note: Due to the distributed nature of throttling architecture, rate limiting is never completely accurate. The difference between the configured and the actual number of allowed requests varies based on request volume and rate, backend latency, and other factors.
You can also customize this policy by adding optional attributes such as increment-condition or quota-exceeded-response-code. For more details on how this policy works and what options are available, see: https://learn.microsoft.com/en-us/azure/api-management/rate-limit-by-key-policy
In this blog post, we have seen how to configure rate limits for different operations of an API in Azure API Management using the `rate-limit-by-key` policy.
This policy allows us to define expressions to identify the keys that are used to track traffic usage.
We have also seen how to use `context.Operation.Id` as part of the key expression to ensure that the rate limits are independent by operation.
We hope this blog helps you!
Published on:
Learn moreRelated posts
Integration Testing Azure Functions with Reqnroll and C#, Part 5 - Using Corvus.Testing.ReqnRoll in a build pipeline
If you use Azure Functions on a regular basis, you'll likely have grappled with the challenge of testing them. In the final post in this serie...
Integration Testing Azure Functions with Reqnroll and C#, Part 4 - Controlling your functions with additional configuration
If you use Azure Functions on a regular basis, you'll likely have grappled with the challenge of testing them. In the fourth of this series of...
Integration Testing Azure Functions with Reqnroll and C#, Part 3 - Using hooks to start Functions
If you use Azure Functions on a regular basis, you'll likely have grappled with the challenge of testing them. In the third of a series of pos...
Integration Testing Azure Functions with Reqnroll and C#, Part 2 - Using step bindings to start Functions
If you use Azure Functions on a regular basis, you'll likely have grappled with the challenge of testing them. In the second of a series of po...
Integration Testing Azure Functions with Reqnroll and C#, Part 1 - Introduction
If you use Azure Functions on a regular basis, you'll likely have grappled with the challenge of testing them. In the first of a series of pos...
Announcing Azure MCP Server 2.0 Stable Release for Self-Hosted Agentic Cloud Automation
Azure MCP Server 2.0 is now generally available, delivering first-class self-hosting, stronger security hardening, and a faster foundation for...
Azure Security: Private Vs. Service Endpoints
When connecting securely to a platform service such as a key vault or an Azure storage account, Microsoft recommends using a private endpoint ...
Give your Foundry Agent Custom Tools with MCP Servers on Azure Functions
Learn how to connect your MCP server hosted on Azure Functions to Microsoft Foundry agents. This post covers authentication options and setup ...
Azure Data Factory Tips for Reliable Microsoft Dynamics 365 CE and Dataverse Integrations
Reliable integrations between Microsoft Dynamics 365 Customer Engagement and external systems can become challenging. This is especially true ...
Scalable AI with Azure Cosmos DB: Tredence Intelligent Document Processing (IDP) | March 2026
Azure Cosmos DB enables scalable AI-driven document processing, addressing one of the biggest barriers to operational scale in today’s enterpr...