Manage adaptive API rate limiting with a webhook proxy and Redis

Description

Quick overview
This workflow exposes a webhook that proxies calls to approved upstream APIs and enforces per-service rate limits in Redis, dynamically adjusting limits based on 429/Retry-After and X-RateLimit-* headers while optionally delaying over-budget requests.

How it works
Receives a POST webhook request with { service, path, method, payload } to be executed against an upstream API.
Validates the requested service and path against an allowlisted service registry and returns a 404 for unknown services or unsafe paths.
Loads the service’s current limiter state from Redis, computes the effective request limit, and immediately returns a 429 with Retry-After if an upstream backoff period is still active.
Atomically increments a per-window request counter in Redis and either allows the request, delays it until the next window if it can wait, or returns a 429 when it is over budget.
Calls the target upstream API with an HTTP request and inspects the response status and rate-limit headers.
Updates the adaptive limiter state in Redis using AIMD rules and returns the upstream result (or an upstream 429) with rate-limit and throttle metadata.

Setup
Add a Redis credential and select it on all Redis nodes used for reading/writing limiter state and window counters.
Update the service registry values (base URLs, limits, window seconds, optional headers, and max wait) in the configuration step to match the APIs you want to proxy.
Send callers to the workflow’s POST webhook URL (/webhook/rate-limit-manager) and include { service, path, method, payload } in the request body.