--- title: Adding rate limiting rules description: Add a rate limiting rule to prevent a client from overloading the server with too many requests in a specified period of time. component: pingaccess version: 9.0 page_id: pingaccess:pingaccess_user_interface_reference_guide:pa_adding_rate_limiting_rules canonical_url: https://docs.pingidentity.com/pingaccess/9.0/pingaccess_user_interface_reference_guide/pa_adding_rate_limiting_rules.html revdate: August 8, 2025 section_ids: about-this-task: About this task steps: Steps --- # Adding rate limiting rules Add a rate limiting rule to prevent a client from overloading the server with too many requests in a specified period of time. ## About this task This rule uses a token bucket to control the number of incoming requests. The rule configuration defines a number of requests and an interval that must elapse between requests: * The allowed number of requests within the time window is controlled by the **Max Burst Requests** setting, which is visible when you click **Show Advanced**. For example, if the **Max Burst Requests** value is `1`, two requests are allowed in the request interval, one normal request and one burst request. * If a request wasn't received, the number of allowed requests is incremented by one at the end of each **Request Interval**. This continues until the number of allowed requests equals the **Max Burst Requests** value. | | | | - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | If you're running PingAccess in a clustered deployment and traffic is distributed evenly between each engine, you can tune down the rate limiting settings. Configure the values you want to enforce per engine node instead of for the entire cluster. | ## Steps 1. Click **Access**, then go to **Rules > Rules**. 2. Click **[icon: plus, set=fa]Add Rule**. 3. In the **Name** field, enter a unique name, up to 64 characters long. Special characters and spaces are allowed. 4. In the **Type** list, select **Rate Limiting**. 5. Select a **Policy Granularity**, as defined in the following table. > **Collapse: Policy granularity options** > > | Policy Granularity | Definition | > | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | > | **Resource** | Restricts the rate of requests based on the resource requested. | > | **Identity** (default) | Restricts the rate of requests to the identity associated with the current authentication token, such as a PingAccess cookie or an OAuth *(tooltip: \
\

A standard framework that enables an application (OAuth client) to obtain access tokens from an OAuth authorization server for the purpose of retrieving protected resources on a resource server.\

\
)* token. | > | **IP** | Restricts the number of requests based on the source Internet Protocol (IP) *(tooltip: \
\

The method by which data is sent across the internet from the source host to the destination host.\

\
)* address.The IP address used to apply this policy comes from the HTTP request's IP source configuration options, or any options that might override that configuration if applied. | > | **OAuth Client** | Restricts the number of requests to all OAuth tokens obtained by a specific **Client ID**. If you select OAuth Client as the policy granularity for a rate limiting rule, the rule won't work if it's applied to a web application. | 6. In the **Request Interval** field, define, in milliseconds, an interval that must elapse between requests. 7. (Optional) Click **Show Advanced Settings** to configure advanced options: > **Collapse: Advanced settings** > > | Advanced Setting | Description | > | -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | > | **Max Burst Requests** | If more than one request should be allowed in a request interval, enter the number of requests to allow in the **Max Burst Requests** field. PingAccess increases the number of available requests only after a request interval that serves no requests to the client. As a result, in the period following a cycle where the remaining allowed burst requests is reduced to 0, no burst requests are allowed, regardless of this setting. | > | **Set Retry-After Header** | If PingAccess should reply to the client with a `Retry-After` header instructing the client to wait for a period of time, select the **Set Retry-After Header** checkbox. | > | **Rejection Handling** | To configure rejection handling, select a rejection handling method:- If you select **Default**, use the **Rejection Handler** list to select an existing [rejection handler](pa_rejection_handlers.html), defining whether to display an error template or redirect to a URL. > > - If you select **Basic**, you can customize an error message to display as part of the default error page rendered in the end-user's browser if rule evaluation fails. This page is among the templates you can modify with your own branding or other information. If you select **Basic**, provide the following: > > 1. In the **Error Response Code** field, enter the HTTP status response code to send if rule evaluation fails. > > The default is `403`. > > 2. In the **Error Response Status Message** field, enter the HTTP status response message to send if rule evaluation fails. > > The default is `Forbidden`. > > 3. In the **Error Response Template File** field, enter the HTML template page for customizing the error message that displays if rule evaluation fails. > > This template file is located in the `/conf/template/` directory. > > 4. In the **Error Response Content Type** list, select the type of content for the error response. > > This lets the client properly display the response. | 8. Click **Save**.