---
title: "Rate Limiting"
description: "Configure request rate limits and Redis-backed failure backoff for the Enterprise Verifier2 Service."
stack: "Enterprise Stack (commercial) — version 1.1.1"
stack_version: "1.1.1"
stack_comparison: https://docs.walt.id/community-vs-enterprise.md
canonical_url: https://docs.walt.id/enterprise-stack/services/verifier2-service/configurations/rate-limiting
generated: 2026-10-01
---
# Rate Limiting

The Verifier2 Service applies request rate limits to its OpenID4VP wallet interaction endpoints. These limits protect the verification flow from automated abuse while still allowing normal wallet verification traffic.

Rate limiting is configured in the unified `rate-limit.conf` file, which contains:

- **Persistence settings** — Optionally configures Redis for progressive failure backoff shared across Enterprise Service instances.
- **Verifier2 endpoint limits** — Defines request limits and failure-backoff thresholds for the `request` and `response` endpoints.
- **Issuer2 endpoint limits** — Defines request limits for the issuer service (see [Issuer2 Rate Limiting](https://docs.walt.id/enterprise-stack/services/issuer2-service/configurations/rate-limiting.md)).

**Note:**

The source IP is the IP address visible to the Enterprise Service runtime.

## Rate Limited Endpoints

The following public wallet interaction endpoints are rate limited:

| Endpoint | Method | Purpose |
|----------|--------|---------|
| `{verification-session}/request` | GET | Wallet fetches the authorization request |
| `{verification-session}/request` | POST | Wallet POSTs to request URI (request_uri_method=post) |
| `{verification-session}/response` | POST | Wallet submits VP token (direct_post) |

## Default Behavior

The service enforces endpoint request limits per verifier service, endpoint, and caller IP.

By default, the persistence section uses `type = "memory"`. For verifier2 rate limiting this means Redis is not configured:

- Basic request-volume limits still work.
- Progressive failure backoff is disabled.
- Failure counters are not stored in memory by verifier2.
- Ktor request counters are local to each Enterprise Service instance.
- Restarting an Enterprise Service instance clears its in-process request counters.

For production deployments with multiple Enterprise Service instances, configure Redis so repeated failures are blocked consistently across the cluster.

## Configure Endpoint Limits

Use the `verifier2_request_endpoint` and `verifier2_response_endpoint` sections in `rate-limit.conf` to configure the wallet interaction endpoint limits.

```hocon[rate-limit.conf]
# Verifier2 OpenID4VP rate limits
verifier2_request_endpoint {
  requestsPerMinute = 10
  failureWindowSeconds = 60
  failureThreshold = 5
  failureBlockSeconds = 300
}

verifier2_response_endpoint {
  requestsPerMinute = 5
  failureWindowSeconds = 60
  failureThreshold = 5
  failureBlockSeconds = 300
}
```

## Fields

### `requestsPerMinute`

_Integer_ — Maximum number of requests allowed per minute for the same verifier service, endpoint, and caller IP.

- `verifier2_request_endpoint.requestsPerMinute` defaults to `10`.
- `verifier2_response_endpoint.requestsPerMinute` defaults to `5`.

When the threshold is exceeded, verifier2 returns `429 Too Many Requests` with a `Retry-After` header.

### `failureWindowSeconds`

_Integer_ — Time window in seconds for counting failed endpoint responses.

The default is `60`. With the default settings, verifier2 counts failures during a rolling 60-second window.

### `failureThreshold`

_Integer_ — Number of failed requests in the failure window required to create a temporary block.

The default is `5`. With Redis enabled, the fifth failed request in the window creates a temporary backoff block.

### `failureBlockSeconds`

_Integer_ — Duration in seconds for the temporary block after the failure threshold is reached.

The default is `300`. Blocked requests return `429 Too Many Requests` with a `Retry-After` header and a JSON error body:

```json
{
  "error": "temporarily_unavailable",
  "error_description": "Too many failed requests"
}
```

## Configure Redis Backoff

Use the `persistence` section in `rate-limit.conf` to enable Redis-backed progressive failure backoff. This configuration is shared between issuer2 and verifier2 services.

```hocon[rate-limit.conf]
persistence {
  type = "redis"
  nodes = [
    { host = "redis", port = 6379 }
  ]

  # Optional Redis authentication:
  # user = "default"
  # password = "change-me"
}
```

Redis cluster deployments can use `type = "redis-cluster"`:

```hocon[rate-limit.conf]
persistence {
  type = "redis-cluster"
  nodes = [
    { host = "redis-node-1", port = 6379 },
    { host = "redis-node-2", port = 6379 },
    { host = "redis-node-3", port = 6379 }
  ]
}
```

When Redis is configured, progressive failure backoff is shared across Enterprise Service instances using the same Redis deployment.

## Monitoring

Verifier2 exposes Prometheus counters for request outcomes and failure backoff. Use these metrics to alert on automated attacks or abnormal client behavior:

| Metric | Description |
|---|---|
| `verifier2_openid4vp_requests_total` | Request and response endpoint responses labeled by endpoint and result. |
| `verifier2_request_failures_total` | Request endpoint failures labeled by error type. |
| `verifier2_request_backoff_blocks_total` | Request endpoint backoff blocks created. |
| `verifier2_request_backoff_rejections_total` | Request endpoint requests rejected by failure backoff. |
| `verifier2_response_failures_total` | Response endpoint failures labeled by error type. |
| `verifier2_response_backoff_blocks_total` | Response endpoint backoff blocks created. |
| `verifier2_response_backoff_rejections_total` | Response endpoint requests rejected by failure backoff. |