This pageapplies toApigee andApigee hybrid.

View Apigee Edge documentation.

Aquota is an allotment of requests that an API proxy will accept over a time period, such as minute, hour, day, week, or month. The Quota policy maintains counters that tally the number of requests received by the API proxy. This capability enables API providers to enforce limits on the number of API calls made by apps over an interval of time. Using Quota policies you can, for example, limit apps to 1 request per minute, or to 10,000 requests per month.

This policy is anExtensible policy and use of this policy might have cost or utilization implications, depending on your Apigee license. For information on policy types and usage implications, seePolicy types.

When an API proxy reaches its quota limit, Apigee rejects subsequent API calls and returns an error message until the Quota counter automatically resets at the end of the specified time interval, or until the Quota is explicitly reset using theResetQuota policy.

For example, if a Quota is defined as 10,000 messages per month, rate-limiting begins after the 10,000th message. It doesn't matter whether 10,000 messages were counted on the first day or the last day of that month.

With Apigee, each API call can be dynamically weighted. For example, with a Large Language Model (LLM) API, you can enforce a rate limit based on the number of tokens in the request or the response, or both. Also, the quota limits themselves can be dynamic, which means you can enforce more strict quotas when the system is busier, or relax quotas during non-peak hours.

A variation on the Quota policy,SpikeArrest policy, prevents traffic spikes (or bursts) that can be caused by a sudden increase in usage, buggy clients, or malicious attacks.

You can set the same quota for all apps accessing the API proxy, or you can set different quota limits, depending on:

• The product that contains the API proxy
• The app requesting the API
• The app developer
• The upstream service
• Many other criteria
• Combinations of any of the available criteria

Don't use the Quota policy to shield against overall traffic spikes. For that, use theSpikeArrest policy.

Videos

The Quota policy supports several different ways in which the quota counter starts and resets. You can define which to use with thetype attribute on the<Quota> element, as the following example shows:

<Quotaname="QuotaPolicy"type="calendar">...</Quota>

Valid values oftype include:

• calendar: Configures a quota based on an explicit start time. The Quota counter for each app is refreshed based on the<StartTime>,<Interval>, and<TimeUnit> values that you set.
• rollingwindow: Configures a quota that uses a "rolling window" to determine quota usage. Withrollingwindow, you determine the size of the window with the<Interval> and<TimeUnit> elements; for example, 1 day. When a request comes in, Apigee looks at the exact time of the request (say 5:01pm), counts the number of requests that came in between then and 5:01pm the previous day (1 day), and determines whether or not quota has been exceeded during that window.
• flexi: Configures a quota that causes the counter to begin when the first request message is received from an app, and resets based on the<Interval> and<TimeUnit> values.

The following table describes when the quota resets for each type:

Fortype="calendar", you must specify the value of<StartTime>.

The table does not describe when the count resets for therollingwindow type. That's because rolling window quotas work a little differently, based on alookback window, such as a one hour or one day. For therollingwindow type, the counter never resets, but is recalculated on each request. When a new request comes in, the policy determines if the quota has been exceeded in the past window of time.

For example, you define a two hour window that allows 1000 requests. A new request comes in at 4:45 PM.The policy calculates the quota count for the past two hour window, meaning the number of requests since 2:45 PM. If the quota limit has not been exceeded in that two-hour window, then the request is allowed.

One minute later, at 4:46 PM, another request comes in. Now the policy calculates the quota count since 2:46 PM to determine if the limit has been exceeded.

Understanding quota counters

When a quota policy executes in an API proxy flow, a quota counter is incremented. When the counter reaches its limit, no further API calls associated with that counter are permitted. Depending on the configuration you use for your API Product, the quota policy may employ a single counter, or multiple independent counters. It's important to understand the scenarios under which multiple counters will be used, and how they behave.

Configuring quota settings for API products

An API product can specify quota settings at theproduct level or at theindividual operation level, or both. If your API proxy is included in an API product, you can configure the Quota policy to use the quota settings (allow count, time unit, and interval) that are defined in that product. The easiest way to do this is via theuseQuotaConfigInAPIProduct element. Alternatively, you can reference these settings in the Quota policy via individual variable references.

How quotas are counted

By default, Apigee maintains a separate quota counter for each operation defined in an API product, and the following rules are observed:

• If an operation has a quota defined for it, then the operation's quota settings take precedence over the quota settings defined at the product level.
• If an operation does not have a quota defined for it, then the product-level quota settings apply.
• If the API product does not include any quota settings — neither at the product nor operation level — quota settings for allow count, time unit, and interval as specified in the Quota policy apply.

In all cases, Apigee maintains a separate quota counter for each operation defined in an API product. Any API calls that match an operation will increment its counter.

Configuring the quota policy to use API product quota settings

To configure your quota policy to use quota settings from an API product that the proxy belongs to:

1. Create or update an API product and specify thequotaCounterScope attribute asPRODUCT to enforce quota at the API product level, or specifyPROXY to enforce quota at the API proxy level.
2. For all API proxies in the API product, add aVerifyAPIKey policy or anOAuthv2 policy with a VerifyAccessToken operation in the request flowbefore the Quota policy. These policies identify the API product for each request.Note: If you don't add one of these operations to the request flow, the API proxy quota policy does not know which API product's quota configuration to apply to the request and the API product's quota counter is not updated for API calls.
3. Configure the Quota policy to use the limits defined in the API Product, withUseQuotaConfigInAPIProduct.

Configuring API proxy-level counters

It is possible to configure an API product to maintain a quota count at the API proxy scope. In this case, the quota configuration specified at the API product level is shared by all operations that do not have their own quota specified. The effect of this configuration is to create a counter at the API proxy level for this API product.

To achieve this configuration, you must use the/apiproducts Apigee APIto create or update the product and set thequotaCounterScope attribute toPROXY in the create or update request. With thePROXY configuration, requests matching any of the operations defined for the API product that are associated with the same proxy, and do not have their own quota settings, will share a common quota counter for that proxy.

In Figure 1, Operation 1 and 2 are associated with Proxy1 and Operation 4 and 5 are associated with Proxy3. BecausequotaCounterScope=PROXY is set in the API product, each of these operations uses the API product-level quota setting. Operation 1 and 2, associated with Proxy1, use a shared counter, and Operation 4 and 5, associated with Proxy3, use a separate shared counter. Operation 3 has its own quota configuration setting, and because of that uses its own counter, irrespective of the value of thequotaCounterScope attribute.

Figure 1: Use of the quotaCounterScope flag

How quotas are counted if no API products are in use

If there is no API product associated with an API proxy, a quota policy maintains a single counter, regardless of how many times you reference it in an API proxy. The name of the quota counter is based on thename attribute of the policy.

For example, you create a Quota policy namedMyQuotaPolicy with a limit of 5 requests and place it on multiple flows (Flow A, B, and C) in the API proxy. Even though it is used in multiple flows, it maintains a single counter that is updated by all instances of the policy:

• Flow A is executed -> MyQuotaPolicy is executed and its counter = 1
• Flow B is executed -> MyQuotaPolicy is executed and its counter = 2
• Flow A is executed -> MyQuotaPolicy is executed and its counter = 3
• Flow C is executed -> MyQuotaPolicy is executed and its counter = 4
• Flow A is executed -> MyQuotaPolicy is executed and its counter = 5

The next request to any of the three flows is rejected because the quota counter has reached its limit.

Using the same Quota policy in more than one place in an API proxy flow, which can unintentionally cause Quota to run out faster than you expected, is an anti-pattern described inIntroduction to antipatterns.

Alternatively, you can define multiple Quota policies in your API proxy and use a different policy in each flow. Each Quota policy maintains its own counter, based on thename attribute of the policy.

Creating multiple counters through policy configuration

You can use the<Class> or<Identifier> elements in the Quota policy to define multiple, unique counters in a single policy. By using these elements, a single policy can maintain different counters based on the app making the request, the app developer making the request, a client ID or other client identifier, and more. See the examples above for more information on using the<Class> or<Identifier> elements.

All Quota times are set to theCoordinated Universal Time (UTC) time zone.

Quota time notation follows the international standard date notation defined in International StandardISO 8601.

Dates are defined as year, month, and day, in the following format:YYYY-MM-DD. For example,2021-02-04 represents February 4, 2021.

Time of day is defined as hours, minutes, and seconds in the following format:hours:minutes:seconds. For example,23:59:59 represents the time one second before midnight.

Note that two notations,00:00:00 and24:00:00, are available to distinguish the two midnights that can be associated with one date. Therefore2021-02-04 24:00:00 is the same date and time as2021-02-05 00:00:00. The latter is usually the preferred notation.

Getting quota settings from the API product configuration

You can set quota limits in API product configurations. Those limits don't automatically enforce quota. Instead, you can reference product quota settings in a quota policy. Here are some advantages of setting a quota on the product for quota policies to reference:

• Quota policies can use a uniform setting across all API proxies in the API product.
• You can make runtime changes to the quota setting on an API product, and quota policies that reference the value automatically have updated quota values.

For more information on using quota settings from an API product, see the "Dynamic Quota" example above.

For info on configuring API products with quota limits, seeManaging API products.

Configuring shared quota counters

In the simple case, the Quota policy increments its counter once for each request sent to an API proxy, during initial request processing. In some cases, you may want to check if the quota is exceeded on initial handling of the incoming request, but increment the counter only during response handling. This makes sense when the cost or weight of the API call can be known only after the upstream or target system responds. In the case of an LLM API, the size of the response in tokens might determine the cost. In the case of a BigQuery API, thetotal_slot_ms in the response might determine the cost.

Three Quota policy elements—<SharedName>,<CountOnly>, and<EnforceOnly>—when used together, allow you to customize the Quota policy to enforce the quota on the incoming request, and accrue counts against the quota based on information derived from target responses.

For example, suppose you have an API proxy that uses an LLM as a target, and you wish to enforce a quota of 100,000 tokens per hour. The LLM responses provide atotalTokenCount value. To achieve this, do the following:

• Attach a Quota policy to the ProxyEndpoint Request flow with the<SharedName> element set with a name value and the<EnforceOnly> element set totrue.
• To the ProxyEndpoint Response flow, attach an ExtractVariables policy to extract thetotalTokenCount value from the response received from the LLM target.
• Attach a second Quota policy to the ProxyEndpoint Response flow with the<SharedName> element set to the same name value as the first Quota policy and the<CountOnly> element set totrue. Set the<MessageWeight> element to use the extractedtotalTokenCount value.

For an example showing how to use shared counters, seeShared counters in theSamples section.

Samples

These policy code samples illustrate how to start and end quota periods by:

<Quota name="CheckQuota">  <Interval ref="verifyapikey.verify-api-key.apiproduct.developer.quota.interval">1</Interval>  <TimeUnit ref="verifyapikey.verify-api-key.apiproduct.developer.quota.timeunit">hour</TimeUnit>  <Allow count="200" countRef="verifyapikey.verify-api-key.apiproduct.developer.quota.limit"/></Quota>

<Quota name="DeveloperQuota">  <Identifier ref="verifyapikey.verify-api-key.client_id"/>  <Interval ref="verifyapikey.verify-api-key.developer.timeInterval"/>  <TimeUnit ref="verifyapikey.verify-api-key.developer.timeUnit"/>  <Allow countRef="verifyapikey.verify-api-key.developer.limit"/></Quota>

<Quotaname="QuotaPolicy"type="calendar"><StartTime>2021-02-1810:30:00</StartTime><Interval>5</Interval><TimeUnit>hour</TimeUnit><Allowcount="99"/></Quota>

<Quota name="QuotaPolicy">  <Interval>5</Interval>  <TimeUnit>hour</TimeUnit>  <Allow count="99"/></Quota>

<AssignMessagecontinueOnError="false"enabled="true"name="ReturnQuotaVars"><AssignTocreateNew="false"type="response"/><Set><Headers><Headername="QuotaLimit">{ratelimit.QuotaPolicy.allowed.count}</Header><Headername="QuotaUsed">{ratelimit.QuotaPolicy.used.count}</Header><Headername="QuotaResetUTC">{ratelimit.QuotaPolicy.expiry.time}</Header></Headers></Set><IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables></AssignMessage>

<ProxyEndpoint name="default">  <PreFlow name="PreFlow">    <Request>      <Step>        <Name>Quota-Enforce-Only</Name>      </Step>    </Request>    <Response>      <Step>        <Name>EV-Token-Count</Name>      </Step>      <Step>        <Name>Quota-Count-Only</Name>      </Step>    </Response>    <Response/>  </PreFlow>  <Flows/>  <PostFlow name="PostFlow">    <Request/>    <Response/>  </PostFlow>  <HTTPProxyConnection>    <BasePath>/quota-shared-name</BasePath>  </HTTPProxyConnection>  <RouteRule name="noroute"/></ProxyEndpoint>

<Quotaname="Quota-Enforce-Only"type="rollingwindow"><SharedName>common-counter</SharedName><EnforceOnly>true</EnforceOnly><Allowcount="15000"/><Interval>30</Interval><TimeUnit>minute</TimeUnit><Distributed>true</Distributed></Quota>

<ExtractVariablesname='EV-Token-Count'><Source>response</Source><VariablePrefix>extracted</VariablePrefix><JSONPayload><Variablename='tokenCount'><JSONPath>$[1].usageMetadata.totalTokenCount</JSONPath></Variable></JSONPayload></ExtractVariables>

<Quotaname="Quota-Count-Only"type="rollingwindow"><SharedName>common-counter</SharedName><!--SamenameasthefirstQuotapolicy--><CountOnly>true</CountOnly><Allowcount="15000"/><Interval>30</Interval><TimeUnit>minute</TimeUnit><Distributed>true</Distributed><MessageWeightref="extracted.tokenCount"/></Quota>

<Quota name="MyQuota">  <Interval>1</Interval>  <TimeUnit>hour</TimeUnit>  <Allow count="10000"/></Quota>

<Quotaname="QuotaPolicy"type="calendar"><Identifierref="request.header.clientId"/><StartTime>2021-02-1810:00:00</StartTime><Interval>5</Interval><TimeUnit>hour</TimeUnit><Allowcount="99"/></Quota>

<Identifier ref="request.queryparam.id"/>

<Identifier ref="verifyapikey.verify-api-key.client_id"></Identifier>

<Quota name="QuotaPolicy">  <Interval>1</Interval>  <TimeUnit>day</TimeUnit>  <Allow>    <Class ref="request.header.developer_segment">      <Allow count="10000"/>      <Allow count="1000" />    </Class>  </Allow></Quota>

<Quota> element

Following are attributes and child elements of<Quota>. Note that some element combinations are mutually exclusive or not required. See the samples for specific usage.

Theverifyapikey.my-verify-key-policy.apiproduct.* variables below are available by default when aVerifyAPIKey policy calledmy-verify-key-policy is used to check the app's API key in the request. The variable values come from the quota settings on the API product that the key is associated with, as described inGetting quota settings from the API product configuration.

<QuotacontinueOnError="false"enabled="true"name="Quota-3"type="calendar"><DisplayName>Quota3</DisplayName><Allowcount="UPPER_REQUEST_LIMIT"countRef="verifyapikey.my-verify-key-policy.apiproduct.developer.quota.limit"/><Allow><Classref="request.queryparam.time_variable"><Allowclass="peak_time"count="UPPER_LIMIT_DURING_PEAK"/><Allowclass="off_peak_time"count="UPPER_LIMIT_DURING_OFFPEAK"/></Class></Allow><Intervalref="verifyapikey.my-verify-key-policy.apiproduct.developer.quota.interval">1</Interval><TimeUnitref="verifyapikey.my-verify-key-policy.apiproduct.developer.quota.timeunit">month</TimeUnit><StartTime>2021-7-1612:00:00</StartTime><Distributed>false</Distributed><Synchronous>false</Synchronous><AsynchronousConfiguration><SyncIntervalInSeconds>20</SyncIntervalInSeconds><SyncMessageCount>5</SyncMessageCount></AsynchronousConfiguration><Identifier/><MessageWeight/><UseQuotaConfigInAPIProduct><DefaultConfig><Allow><Classref="request.queryparam.time_variable"><Allowclass="peak_time"count="5000"/><Allowclass="off_peak_time"count="1000"/></Class></Allow><Intervalref="verifyapikey.my-verify-key-policy.apiproduct.developer.quota.interval">1</Interval><TimeUnitref="verifyapikey.my-verify-key-policy.apiproduct.developer.quota.timeunit">month</TimeUnit></DefaultConfig></UseQuotaConfigInAPIProduct></SharedName></CountOnly></EnforceOnly></Quota>

The following attributes are specific to this policy:

The following table describes attributes that are common to all policy parent elements:

<DisplayName> element

Use in addition to thename attribute to label the policy in the management UI proxy editor with a different, natural-language name.

<DisplayName>Policy Display Name</DisplayName>

<Allow>

Specifies the count limit for the quota. If the counter for the policy reaches this limit value, subsequent calls are rejected until the counter resets.

Can also contain a<Class> element that conditionalizes the<Allow> element based on a flow variable.

Shown below are three ways to set the<Allow> element:

<Allow count="2000"/>

<Allow countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/>

<Allow count="2000" countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/>

If you specify bothcount andcountRef, thencountRef gets the priority. IfcountRef does not resolve at runtime, then the value ofcount is used.

You can also specify a<Class> element as a child of<Allow> to determine the allowed count of the policy based on a flow variable. Apigee matches the value of the flow variable to theclass attribute of the<Allow> element, as shown below:

<Allow><Classref="request.queryparam.time_variable"><Allowclass="peak_time"count="5000"/><Allowclass="off_peak_time"count="1000"/></Class></Allow>

The following table lists attributes of<Allow>:

<Class>

Lets you conditionalize the value of the<Allow> element based on the value of a flow variable. For each different<Allow> child tag of<Class>, the policy maintains a different counter.

To use the<Class> element, specify a flow variable using theref attribute to the<Class> element. Apigee then uses the value of the flow variable to select one of the<Allow> child elements to determine the allowed count of the policy. Apigee matches the value of the flow variable to theclass attribute of the<Allow> element, as shown below:

<Allow><Classref="request.queryparam.time_variable"><Allowclass="peak_time"count="5000"/><Allowclass="off_peak_time"count="1000"/></Class></Allow>

In this example, the current quota counter is determined by the value of thetime_variable query param passed with each request. That variable can have a value ofpeak_time oroff_peak_time. If the query param contains an invalid value, the policy returns a quota violation error.

The following table lists attributes of<Class>:

<Allow> (child of<Class>)

Specifies the limit for a quota counter defined by the<Class> element. For each different<Allow> child tag of<Class>, the policy maintains a different counter.

For example:

<Allow><Classref="request.queryparam.time_variable"><Allowcount="5000"/><Allowcount="1000"/></Class></Allow>

In this example, the Quota policy maintains two quota counters namedpeak_time andoff_peak_time. Which of these is used depends on the query parameter passed in, as shown in<Class> example.

The following table lists attributes of<Allow>:

<Interval>

Specifies the number of time periods in which quotas are calculated.

Use to specify an integer (for example, 1, 2, 5, 60, and so on) that will be paired with the<TimeUnit> element you specify (minute, hour, day, week, or month) to determine a time period during which Apigee calculates quota use.

For example, an interval of24 with a<TimeUnit> ofhour means that the quota will be calculated over the course of 24 hours.

<Interval ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.interval">1</Interval>

The following table lists attributes of<Interval>:

<TimeUnit>

Specifies the unit of time applicable to the quota.

Select fromminute,hour,day,week,month, oryear.

For example, anInterval of24 with aTimeUnit ofhour means that the quota will be calculated over the course of 24 hours.

<TimeUnit ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.timeunit">month</TimeUnit>

The following table lists attributes of<TimeUnit>:

<StartTime>

Whentype is set tocalendar, specifies the date and time when the quota counter begins counting, regardless of whether any requests have been received from any apps.

<StartTime>2021-7-16 12:00:00</StartTime>

<Distributed>false</Distributed>

To guarantee that the counters are synchronized, and updated on every request, set<Distributed> and<Synchronous> totrue:

<Distributed>true</Distributed><Synchronous>true</Synchronous>

<Synchronous>

Determines whether to update a distributed quota counter synchronously.

Set totrue to update a distributed quota counter synchronously. This means that the updates to the counters are made at the same time the quota is checked on a request to the API. Set totrue if it is essential that you not allow any API calls over the quota.

<Synchronous>false</Synchronous>

Configures the synchronization interval among distributed quota counters when the policy configuration element<Synchronous> is either not present or present and set tofalse. Apigee ignores this element when<Synchronous> is set totrue.

You can specify the synchronization behavior using the<SyncIntervalInSeconds> or<SyncMessageCount> child elements. Use either or both elements. For example,

<AsynchronousConfiguration>   <SyncIntervalInSeconds>20</SyncIntervalInSeconds></AsynchronousConfiguration>

or

<AsynchronousConfiguration>   <SyncIntervalInSeconds>20</SyncIntervalInSeconds>   <SyncMessageCount>5</SyncMessageCount></AsynchronousConfiguration>

• When only<SyncIntervalInSeconds> is present, the quota synchronizes every N seconds, where N is the value specified in the element, irrespective of how many messages have been handled.
• When only<SyncMessageCount> is present, the quota synchronizes every M messages, where M is the value specified in the element, or every 10 seconds, whichever comes first.
• When both elements are present, the quota synchronizes every M messages or every N seconds, whichever comes first.
• When<AsynchronousConfiguration> is not present or neither child element is present, the quota synchronizes every 10 seconds, irrespective of how many messages have been handled.

<SyncIntervalInSeconds>

Overrides the default behavior in which asynchronous updates are performed after an interval of 10 seconds.

<AsynchronousConfiguration>   <SyncIntervalInSeconds>20</SyncIntervalInSeconds></AsynchronousConfiguration>

The sync interval must be >= 10 seconds, as described inLimits.

<SyncMessageCount>

Specifies the number of requests to process before synchronizing the quota counter.

<AsynchronousConfiguration>   <SyncMessageCount>5</SyncMessageCount></AsynchronousConfiguration>

Using the configuration in this example, on each node, the quota count will synchronize after every 5 requests, or every 10 seconds, whichever comes first.

<Identifier>

Configures the policy to create unique counters based on a flow variable.

Via the Identifier element, you can allot call counts to distinct buckets defined by the value in a flow variable. For example, you can use thedeveloper.id variable, which is populated after aVerifyAPIKey policy, to enforce one quota limit to all instances of all apps created by each specific developer, or you can use theclient_id to enforce a quota limit for each particular app. The configuration for the latter looks like this:

<Identifier ref="client_id"/>

You can refer to either a custom variable that you might set with theAssignMessage policy or theJavaScript policy, or a variable that is implicitly set, such as those set by theVerifyAPIKey policy or theVerifyJWT policy. For more on variables, seeUsing Flow Variables, and for a list of well-known variables defined by Apigee, see theFlow variables reference.

If you don't use this element, the policy allots all call counts into a single counter for the particular Quota policy.

This element is also discussed inHow does the Quota policy work when no Identifier is specified?

The following table describes the attributes of<Identifier>:

<MessageWeight>

Specifies the cost assigned to each message for quota purposes. Use this element to assign different impact to API requests based on their content or the value of the call.

For example, when Apigee is managing a Large Language Model (LLM) API, you can use the number of tokens in the request or the response, or both, as the<MessageWeight>.

Or, if you want to countPOST messages as being twice as expensive asGET messages, you would set the<MessageWeight> to 2 for aPOST and 1 for aGET. Suppose the quota is 10 messages per minute and the proxy processes 5POST requests in the first 35 seconds. The proxy will reject any additional request,POST orGET, until the counter resets.

A value representing<MessageWeight> must be specified using a flow variable, and can be extracted from HTTP headers, query parameters, an XML or JSON request payload, or any other flow variable. For example, you can extract the value from a response payload into a variable namedextracted.message_weight, and then use this for<MessageWeight>:

<MessageWeight ref="extracted.message_weight"/>

If the flow variable resolves to 0, the request will not affect the counter.

<UseQuotaConfigInAPIProduct>

Defines quota settings for an API product, such as the time units, interval, and allowed maximum.

If you add the<UseQuotaConfigInAPIProduct> element to the Quota policy, then Apigee ignores any<Allow>,<Interval>, and<TimeUnit> child elements of<Quota>.

The<UseQuotaConfigInAPIProduct> element is simply a container for the default settings that you define using the<DefaultConfig> element, as the following example shows:

<UseQuotaConfigInAPIProduct stepName="POLICY_NAME">  <DefaultConfig>...</DefaultConfig></UseQuotaConfigInAPIProduct>

You can use thestepName attribute to reference either aVerifyAPIKey policy or aValidateToken policy operation of theOAuthv2 policy in the flow.

The following table describes the attributes of<UseQuotaConfigInAPIProduct>:

For more information, see the following:

• <DefaultConfig>
• What is an API product?
• Managing API products

<DefaultConfig>

Contains default values for an API product's quota. When you define a<DefaultConfig>, all three child elements are required.

It's possible to define these values on both the API product's operation (either with the UI or theAPI products API and in the Quota policy. If you do that, however, the settings on the API product take precedence and the settings on the Quota policy are ignored.

The syntax for this element is as follows:

<UseQuotaConfigInAPIProduct stepName="POLICY_NAME"><DefaultConfig>    <Allow>allow_count</Allow>    <Interval>interval</Interval>    <TimeUnit>[minute|hour|day|week|month]</TimeUnit>  </DefaultConfig></UseQuotaConfigInAPIProduct>

The following example specifies a quota of 10,000 every week:

<DefaultConfig>  <Allow>10000</Allow>  <Interval>1</Interval>  <TimeUnit>week</TimeUnit></DefaultConfig>

For more information, see the following:

• What is an API product?
• Managing API products

<SharedName>

Identifies this Quota policy asshared. All Quota policies in an API proxy with the same<SharedName> value share the same underlying quota counter.

For more information and examples,seeConfiguring shared quota counters.

<CountOnly>

Place a Quota policy with this element set totrue in a step in the ProxyEndpoint response flow to increment the underlying quota counter without sending an error back to the client when the quota limit is exceeded. If this element is present, the<SharedName> element must also be present and the<EnforceOnly> element must not be present.

For more information and examples, seeConfiguring shared quota counters.

<EnforceOnly>

Place a Quota policy with this element set totrue in the request flow of an API proxy to enforce a quota without incrementing the quota counter. This configuration allows deferred enforcement of rate limits based on message weights that can be known only in the response flow. If this element is present, the<SharedName> must also be present and the<CountOnly> element must not be present.

For more information and examples, seeConfiguring shared quota counters.

Flow variables

The following predefined Flow variables are automatically populated when a Quota policy executes. For more information, seeFlow variables reference.

Error reference

This section describes the fault codes and error messages that are returned and fault variables that are set by Apigee when this policy triggers an error. This information is important to know if you are developing fault rules to handle faults. To learn more, seeWhat you need to know about policy errors andHandling faults.

Runtime errors

These errors can occur when the policy executes.

These variables are set when this policy triggers an error. For more information, seeWhat you need to know about policy errors.

Example error response

{"fault":{"detail":{"errorcode":"policies.ratelimit.QuotaViolation"},"faultstring":"Rate limit quota violation. Quota limit  exceeded. Identifier : _default"}}

<FaultRules>    <FaultRule name="Quota Errors">        <Step>            <Name>JavaScript-1</Name>            <Condition>(fault.name Matches "QuotaViolation") </Condition>        </Step>        <Condition>ratelimit.Quota-1.failed=true</Condition>    </FaultRule></FaultRules>

Related topics

ResetQuota policy

SpikeArrest policy

Comparing Quota and Spike Arrest policies