n8n Webhook Proxy for Adaptive API Rate Limiting with Redis

Adaptive n8n Webhook Proxy with Redis Rate Limiting (Auto-Backoff + Throttling)

This n8n workflow exposes a webhook that safely proxies approved API calls to upstream services while enforcing per-service rate limits stored in Redis—dynamically adjusting limits using upstream 429/Retry-After and X-RateLimit-* headers, and optionally delaying requests when callers run over budget.

What this workflow does

• Receives requests via webhook: Accepts a POST payload containing { service, path, method, payload } to execute against an upstream API.
• Validates safety and allowlists: Checks the requested service and path against an allowlisted service registry; returns 404 for unknown services or unsafe paths.
• Enforces Redis-backed rate limits: Loads the service limiter state from Redis and computes the effective request limit.
• Handles upstream backoff correctly: If a backoff window is still active, returns a 429 with a Retry-After header.
• Atomically counts requests per window: Increments a per-window counter in Redis and either allows the call, delays it until the next window (when it can wait), or returns a 429 when over budget.
• Proxies to the upstream API and adapts: Makes the upstream HTTP request, inspects response status and rate-limit headers, then updates limiter state in Redis using AIMD rules.
• Returns results with throttle metadata: Responds with the upstream result (or upstream 429) and includes rate-limit/throttle information.

Use cases

• Protecting SaaS integrations from upstream throttling by centralizing rate-limit enforcement for multiple services.
• Building a resilient “API gateway” in n8n that adapts automatically to 429 and Retry-After.
• Throttling high-volume automation jobs without manual tuning by updating service registry configuration.

Technical details

• Nodes/logic: webhook, if, set, code, wait, redis
• State storage: Redis credentials configured on all Redis nodes that read/write limiter state and per-window counters.
• Configuration step: Update service registry values (base URLs, limits, window seconds, optional headers, and max wait) to match your upstream APIs.