You're viewing Apigee Edge documentation.
View Apigee X documentation.
Quota and SpikeArrest policies — wondering which one to use to best meet your rate limiting needs? See the comparison chart below.
|Use it to:||Limit the number of connections apps can make to your API proxy's target backend over a specific period of time.||Protect your API proxy's target backend against severe traffic spikes and denial of service attacks.|
|Don't use it to:||
Don't use it to protect your API proxy's target backend against traffic spikes.
For that, use the SpikeArrest policy.
Don't use it to count and limit the number of connections apps can make to your API proxy's target backend over a specific period of time.
For that, use the Quota policy.
|Stores a count?||Yes||No|
|Best practices for attaching the policy:||
Attach it to the ProxyEndpoint Request PreFlow, generally after the authentication of the user.
This enables the policy to check the quota counter at the entry point of your API proxy.
Attach it to the ProxyEndpoint Request PreFlow, generally at the very beginning of the flow.
This provides spike protection at the entry point of your API proxy.
|HTTP status code when limit has been reached:||
|Good to know:||
|Get more details:||Quota policy||SpikeArrest policy|
* For the Quota policy and SpikeArrest policy,
the default HTTP status code for exceeding the rate limit is a generic
500 Internal Server Error.
You can change the status code for those policies to
429 Service Unavailable by adding an
organization-level property (
If you're a Cloud customer, contact Apigee Edge Support to have the property enabled.