# Rate limit

The **Rate Limit** node protects costly or sensitive steps by limiting how many times they can run during a time window. The counter is stored per rendered key, so the limit can be global or isolated by user, IP address, company, or another identifier.

## Configuration

| Field | Description |
| --- | --- |
| **Limit** | Maximum number of allowed executions during the window. |
| **Window (s)** | Counter window in seconds. For example, `60` means one minute. |
| **Key** | Value used to identify a counter, such as `{input.user_id}` or `global`. |
| **Namespace** | Separates counters used for different features. Use a stable value such as `image-generation`. |
| **Redis failure** | Controls only what happens when the counter storage is unavailable: block (**closed**) or allow (**open**). |

When a request is allowed, the original payload passes through unchanged. When the quota is exceeded, the node stops that execution path with a Rate Limit error; it does not wait for a free slot.

## Complete example: three image requests per user per minute

Protect an image-generation agent with this workflow:

```text
Start → Rate Limit → Agent with Image Generation → End
```

Configure **Rate Limit** as follows:

```text
Label: Limit image generation
Limit: 3
Window (s): 60
Key: {input.user_id}
Namespace: image-generation
Redis failure: Block when unavailable
```

Example workflow input:

```json
{
  "user_id": "user-123",
  "prompt": "Generate an image of a cat"
}
```

### How it works

1. The node renders the key as `user-123` and uses the `image-generation` namespace.
2. The first three executions for this key during the 60-second window are allowed. The Agent receives the original input and can generate the image.
3. A fourth execution for `user-123` in the same window is stopped with `Rate Limit Error: limit 3 per 60s exceeded.`
4. After the counter window expires, this user can submit new requests.
5. Another key, for example `user-456`, has a separate counter and is not affected by `user-123`.

The combination of key and namespace defines the logical bucket. This lets the same user have independent quotas for image generation, document analysis, and other costly features.

## Choosing the key

| Key | Effect |
| --- | --- |
| `{input.user_id}` | Separate quota for each user. Recommended when the caller is authenticated. |
| `{input.ip}` | Separate quota by IP address. Useful for anonymous traffic, but several users may share an IP. |
| `{input.company_id}` | Shared quota for all users in one company. |
| `global` | One shared quota for every workflow execution. |

The template must resolve to a non-empty value. If `{input.user_id}` is missing, the node fails instead of silently putting unrelated users into the same counter. Validate or authenticate the identifier before this node.

## Redis failure mode

This option does **not** configure what happens when the quota is exceeded. It only applies when Redis, the counter storage, cannot be reached:

- **Block when unavailable (closed):** safest for costly, financial, or security-sensitive operations.
- **Allow when unavailable (open):** prioritizes availability, but requests may temporarily bypass the quota.

## Runtime data

For an allowed execution, the original `last_output` continues to downstream nodes. Rate-limit metadata is available through `rate_limit.allowed`, `rate_limit.limit`, and `rate_limit.window_seconds`.

Use the interactive workflow card below to copy this example into the editor. Configure a valid model credential before running the image-generation agent.

---

*Source: https://agentbuilder.systalink.sn/docs/node-rate-limit — human documentation.*
*Other language: [/docs-md/fr/node-rate-limit.md](/docs-md/fr/node-rate-limit.md).*
*Machine-readable index: [/llms.txt](/llms.txt).*