Implement Rate Limiting on Webhook Endpoints

Even authenticated webhooks can be abused by excessive request volume. Rate limiting at the reverse proxy prevents both intentional abuse and accidental floods, such as a misconfigured sender repeating the same event. In Nginx, define rate-limit zones and apply them per location so webhook endpoints are capped while the editor UI keeps a more generous limit.

Why rate-limit webhook endpoints?

Even authenticated webhooks can be abused through excessive request volume. Rate limiting prevents both intentional abuse and accidental flood scenarios (e.g., a misconfigured third-party sending the same event in a loop).

Real-world example: A CI/CD pipeline misconfiguration sends the same GitHub push event 10,000 times in a minute. Without rate limiting, n8n spawns 10,000 workflow executions, exhausting memory and CPU.

How do you configure rate limiting in Nginx?

# Nginx rate limiting configuration

# /etc/nginx/sites-available/n8n.conf

# Define rate limit zones

limit_req_zone $binary_remote_addr zone=webhook_limit:10m rate=30r/m;
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=60r/m;

server {
    listen 443 ssl http2;
    server_name n8n.example.com;

    # ... SSL config ...

    # Rate limit webhook endpoints

    location /webhook/ {
        limit_req zone=webhook_limit burst=10 nodelay;
        limit_req_status 429;

        proxy_pass http://127.0.0.1:5678;
        # ... proxy headers ...

    }

    # Separate, more generous limit for the editor UI and REST API

    location / {
        limit_req zone=api_limit burst=20 nodelay;

        proxy_pass http://127.0.0.1:5678;
        # ... proxy headers ...

    }
}

For per-path rate limiting (different limits for different webhooks):

# Stricter limit for payment webhooks

location /webhook/payment {
    limit_req zone=webhook_limit burst=5 nodelay;
    proxy_pass http://127.0.0.1:5678;
    # ...

}

# More permissive limit for monitoring/health check webhooks

location /webhook/health {
    limit_req zone=api_limit burst=30 nodelay;
    proxy_pass http://127.0.0.1:5678;
    # ...

}

The burst parameter allows short spikes above the rate limit. nodelay serves burst requests immediately rather than queuing them. Requests exceeding the burst receive a 429 response.

Related: Use Docker Compose with Health Checks for n8n and PostgreSQL · Use Path Parameters in Webhook URLs for Dynamic Routing