Why is rate-limit-by-key policy not being inherited from Product group to an API?

Question

Why is rate-limit-by-key policy not being inherited from Product group to an API?

RamenTofu 20

Hello!

We have the following rate-limit-by-key policy applied on our product group for a simple rate limit.

<policies>
    <inbound>
        <base />
        <rate-limit-by-key calls="30" renewal-period="60" counter-key="@(context.Request.Headers.GetValueOrDefault("Authorization", context.Request.IpAddress))" />
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
    </outbound>
    <on-error>
        <base />
    </on-error>
</policies>

The following is a Dummy API that we have to test with policies with the following policies:

<policies>
    <inbound>
        <base />
        <cors>
            <allowed-origins>
                <origin>*</origin>
            </allowed-origins>
            <allowed-methods>
                <method>GET</method>
                <method>POST</method>
                <method>PUT</method>
                <method>DELETE</method>
                <method>PATCH</method>
            </allowed-methods>
            <allowed-headers>
                <header>*</header>
            </allowed-headers>
            <expose-headers>
                <header>*</header>
            </expose-headers>
        </cors>
        <!-- Determine which key is being used -->
        <set-variable name="rateLimitKeyType" value="@(
            context.Request.Headers.ContainsKey("Authorization") ? "Authorization" :
            context.Request.Headers.ContainsKey("X-Forwarded-For") ? "X-Forwarded-For" :
            "IP Address"
        )" />
        <set-variable name="rateLimitKeyValue" value="@(
            context.Request.Headers.GetValueOrDefault("Authorization",
                context.Request.Headers.GetValueOrDefault("X-Forwarded-For",
                    context.Request.IpAddress))
        )" />
        <!-- Apply rate limit -->
        <!--<rate-limit-by-key calls="30" renewal-period="60" counter-key="@(context.Request.Headers.GetValueOrDefault("Authorization",context.Request.Headers.GetValueOrDefault("X-Forwarded-For",context.Request.IpAddress)))" />-->
        <!-- <rate-limit-by-key calls="30" renewal-period="60" counter-key="@((string)context.Variables["rateLimitKeyValue"])" /> -->
        <return-response>
            <set-status code="200" reason="ok" />
            <set-header name="Content-Type" exists-action="override">
                <value>test</value>
            </set-header>
            <set-body>@{
            return new JObject(
                new JProperty("MESSAGE", "succress")
            ).ToString();
        }</set-body>
        </return-response>
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <base />
    </outbound>
    <on-error>
		<!-- Policy to view what key caused the rate-limit to be reached -->
        <choose>
            <when condition="@(context.Response.StatusCode == 429)">
                <return-response>
                    <set-status code="429" reason="Too Many Requests" />
                    <set-header name="Content-Type" exists-action="override">
                        <value>test</value>
                    </set-header>
                    <set-body>@{
            return new JObject(
                new JProperty("error", "Rate limit exceeded (default)"),
                new JProperty("limit", "30 requests per 60 seconds"),
                new JProperty("keyType", context.Variables["rateLimitKeyType"]),
                new JProperty("keyValue", context.Variables["rateLimitKeyValue"]),
                new JProperty("Authorization", context.Request.Headers.GetValueOrDefault("Authorization", "missing"))
            ).ToString();
        }</set-body>
                </return-response>
            </when>
        </choose>
        <base />
    </on-error>
</policies>

The inbound of the API has the <base /> tag, so it should be inheriting the rate-limiting policy. Yet when doing a simple load test the policy is not working. When placing the rate-limit-by-key tag on it's own in the API policy (without the base tag), the rate limiting is working as intended (both in managed and self hosted gateways). What could be the reason that this is the case?

The API is placed in the product group, and the global policies are simple header transformation to mask data, and we are not using workspaces. Has anyone seen anything like this before? The documentation says that rate-limit-by-key is applicable to all scopes.

Pravallika KV 18,850 Reputation points Microsoft External Staff Moderator

2026-06-10T17:41:59.7033333+00:00
Hi @RamenTofu ,

This behavior usually comes down to how/when the rate-limit counter is incremented and evaluated, and when scopes are involved which gateway/pipeline instance is actually applying the policy.

Based on the docs, here are the most likely reasons you’d see “rate-limit-by-key works when placed directly on the API, but not when only inherited from a product group”:

Rate limiting happens per gateway, per scope (and may not match your expectations in self-hosted / multi-gateway setups)

rate-limit-by-key uses gateway-local counters. The docs explicitly call out that counters are tracked at the level of the API Management gateway where the policy is applied:

In multi-region deployments, each regional gateway enforces separately.

In self-hosted gateways, limits are not synchronized with other gateway resources (including the managed gateway in the cloud).

So, if your test traffic is landing on a different gateway than the one effectively applying the inherited product-level policy (or you have multiple gateways/workspace vs service-level gateway behavior), you can easily observe “policy not working” even though it’s configured.

What to try**

Verify where the request is hitting (managed gateway vs self-hosted vs workspace gateway).

Make sure the inherited product policy is actually part of the effective policy on the gateway that receives the calls.

Inherited policy + key expression differences can lead to different counter-key values than you think

The counter is updated per distinct counter-key value you specify.

Your counter-key expression selects from:

Authorization header first

else X-Forwarded-For

else context.Request.IpAddress

If, under “product group inherited” scenarios, the incoming requests differ (for example: Authorization present but different per load-test user, or X-Forwarded-For differs per request), you can end up with many different keys, which makes throttling appear ineffective.

What to try

Confirm what header values are present during the load test.

Use request tracing to confirm the effective counter-key value used for throttling.

(Tracing is called out in the provided “Other Policy types” troubleshooting doc as the recommended way to see how policies are evaluated.)

“increment-condition” / response-driven evaluation can delay enforcement (429 can appear later)

If increment-condition or increment-count are defined using expressions, evaluation/increment is postponed until the end of the outbound pipeline so that it can depend on response.

The docs note:

The “Limit exceeded” evaluation may occur on the next incoming call, meaning clients might see 429 one call later than usual.

In your provided product policy snippet you didn’t show increment-condition, but if the product-level configuration includes it (or differs from your test), it could make it seem like throttling isn’t happening during your load test window.

What to try

Compare the exact effective policy (product scope) with the API-scope version that you said works.

Ensure your load test duration and request patterns are sufficient to observe delayed throttling behavior.

Policy evaluation order / base element placement can change what’s inherited

The docs you provided include guidance about policy evaluation order controlled by base placement:

When configuring policy definitions at more than one scope, you control policy evaluation order in each policy section by placement of the base element.

If the product scope policy is not being executed in the expected place relative to other policies (even if your API has <base />), effective policy behavior can differ.

What to try

Use API Inspector / request tracing (documented) to confirm the effective policy includes rate-limit-by-key in the inbound pipeline for the product-scope case.
RamenTofu 20 Reputation points

2026-06-10T17:56:56.45+00:00

Hi @Pravallika KV , thank you for the help. I understand and have observed that the number of gateways will influence how the counter is incremented. However, when testing with different counter-keys I always hit the rate limit when applying the policy directly in the API.

The issue turns out to be that when calculating the effective policy I am not seeing the product policy being applied. The API is not using a subscription key. Why is it the case that API is not inheriting the product policy? Is it because the policies are evaluated at runtime, so unless a subscription key header is sent, the product policies won't be applied?
RamenTofu 20 Reputation points

2026-06-11T13:17:49.8266667+00:00

Great, thank you for the help!
Pravallika KV 18,850 Reputation points Microsoft External Staff Moderator

2026-06-11T16:27:16.75+00:00

@RamenTofu , If this answers your query, do click Accept Answer =>Yes, and upvote it. If you have any further queries do let us know.

Answer accepted by question author

0 additional answers

Your answer

RamenTofu 20 Reputation points

2026-06-10T17:56:56.45+00:00

Hi @Pravallika KV , thank you for the help. I understand and have observed that the number of gateways will influence how the counter is incremented. However, when testing with different counter-keys I always hit the rate limit when applying the policy directly in the API.

The issue turns out to be that when calculating the effective policy I am not seeing the product policy being applied. The API is not using a subscription key. Why is it the case that API is not inheriting the product policy? Is it because the policies are evaluated at runtime, so unless a subscription key header is sent, the product policies won't be applied?
RamenTofu 20 Reputation points

2026-06-11T13:17:49.8266667+00:00

Great, thank you for the help!
Pravallika KV 18,850 Reputation points Microsoft External Staff Moderator

2026-06-11T16:27:16.75+00:00

@RamenTofu , If this answers your query, do click Accept Answer =>Yes, and upvote it. If you have any further queries do let us know.

Answer 1

Hi @RamenTofu ,

Thanks for reaching out to Microsoft Q&A.

You're correct in your observation, but it’s slightly more about subscription resolution than just runtime evaluation or the presence of a header.

It's not simply that policies are evaluated only when a header is present. The real reason is that product-scope policies are only applied when APIM can resolve a subscription context for the request.

If you are not sending a subscription key and not using an alternative mechanism like JWT-to-subscription mapping, then APIM does not resolve a subscription, and therefore it cannot determine the associated product. As a result, product policies are skipped entirely, and they won’t appear in the effective policy even if the API is linked to a product.

So, the API is not missing inheritance; rather no subscription resolution means the product scope is never entered during runtime, and only the global and API-level policies are executed.

Hope this helps!

If the resolution was helpful, kindly take a moment to click on User's image and click on Yes for was this answer helpful. And, if you have any further query do let us know.