viewing Apigee X documentation.
View Apigee Edge documentation.
Use the comparison chart below to help you decide which policy to use to for your rate limiting use case:
|Use it to:||Limit the number of API proxy calls a developer app or developer can make over a specific period of time. The SpikeArrest policy is better suited for rate limiting over shorter time intervals like seconds or minutes. Consider Quota if accurate counting is a requirement.||Limit the number of API calls that can be made against an API proxy across all consumers over a specific (typically short) period of time. The Quota policy is better suited for setting limits on longer time intervals like days, weeks, months, or years.|
|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. Note: For any use cases that require accurate counting, 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:||
||Lets you choose between a "smoothing" algorithm or an effective count algorithm. The former smooths the number of requests that can occur in a specified period of time, and the latter limits the total number of requests that can occur within a specified time period, no matter how rapidly they are sent in succession. Also, smoothing is not coordinated across Message Processors.|
|Get more details:||Quota policy||SpikeArrest policy|