The
Quota policy is used to count the number of requests received by an API proxy. This
capability enables API providers to enforce limits on the number of API calls made by apps over
an interval of time.
The Quota policy can include an
identifier element that identifies the quota "bucket" in which each request is
counted.
Antipattern
When using the Quota policy, do not use high-cardinality identifiers.
Cardinality refers to the number of unique data values in a set. An identifier with
high cardinality has a large number of distinct possible values. High-cardinality identifiers
include unique request IDs or session IDs that change with every API call.
Using high-cardinality identifiers can significantly undermine the effectiveness of your quota
enforcement.
Impact
Using high-cardinality identifiers for your quota policy's identifier element
causes:
Ineffective Quota Enforcement: Each unique identifier is treated as a
separate counter. If every request has a new, unique ID, your quota system
essentially creates a new "bucket" for every API call. This means
your overall quota limit is measured against individual, single-use counters
rather than by actual groups of requests you want to limit, rendering the
policy useless for traffic control.
Increased Resource Consumption: Generating and managing a massive number
of unique quota counters places unnecessary strain on the Apigee platform,
leading to increased resource usage and potential performance issues.
Monitoring Challenges: It becomes difficult to monitor and
understand actual API consumption trends when the data is fragmented across
large numbers of unique identifiers. You lose the ability to see which applications,
developers, or products are consuming your API resources.
Best practice
Choose identifiers with low to medium cardinality that also represent
a stable and meaningful grouping for quota enforcement. These help you
manage API usage effectively and gain insights into your traffic.
Examples include:
developer.app.name
client_id
apiproduct.name
With appropriate identifiers, your Quota policy can more effectively
manage API traffic, prevent unintended overages, and provide clear insights
into usage patterns.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-26 UTC."],[],[],null,["*You're viewing **Apigee** and **Apigee hybrid** documentation.\nView [Apigee Edge](https://docs.apigee.com/api-platform/antipatterns/high-cardinality-identifiers-quota-policy) documentation.*\n\n\nThe [Quota policy](/apigee/docs/api-platform/reference/policies/quota-policy) is used to count the number of requests received by an API proxy. This\ncapability enables API providers to enforce limits on the number of API calls made by apps over\nan interval of time.\n\n\nThe Quota policy can include an\n[`identifier`](/apigee/docs/api-platform/reference/policies/quota-policy#identifier) element that identifies the quota \"bucket\" in which each request is\ncounted.\n\nAntipattern\n\n\nWhen using the Quota policy, do not use high-cardinality identifiers.\n\n\nCardinality refers to the number of unique data values in a set. An identifier with\nhigh cardinality has a large number of distinct possible values. High-cardinality identifiers\ninclude unique request IDs or session IDs that change with every API call.\n\n\nUsing high-cardinality identifiers can significantly undermine the effectiveness of your quota\nenforcement.\n\nImpact\n\n\nUsing high-cardinality identifiers for your quota policy's identifier element\ncauses:\n\n- **Ineffective Quota Enforcement:** Each unique identifier is treated as a separate counter. If every request has a new, unique ID, your quota system essentially creates a new \"bucket\" for every API call. This means your overall quota limit is measured against individual, single-use counters rather than by actual groups of requests you want to limit, rendering the policy useless for traffic control.\n- **Increased Resource Consumption:** Generating and managing a massive number of unique quota counters places unnecessary strain on the Apigee platform, leading to increased resource usage and potential performance issues.\n- **Monitoring Challenges:** It becomes difficult to monitor and understand actual API consumption trends when the data is fragmented across large numbers of unique identifiers. You lose the ability to see which applications, developers, or products are consuming your API resources.\n\nBest practice\n\n\nChoose identifiers with low to medium cardinality that also represent\na stable and meaningful grouping for quota enforcement. These help you\nmanage API usage effectively and gain insights into your traffic.\nExamples include:\n\n- developer.app.name\n- client_id\n- apiproduct.name\n\n\nWith appropriate identifiers, your Quota policy can more effectively\nmanage API traffic, prevent unintended overages, and provide clear insights\ninto usage patterns."]]
