integrations
Route Webhook Events to Redis for a Real-Time Read Cache
September 7, 2026
Plenty of systems fire a webhook every time something changes: a feature flag flips, a session heartbeat lands, an inventory count updates. The event itself is cheap to receive. The problem shows up on the read side. If your application needs to answer "is this flag on right now" or "what's the current count for this SKU" on every page load or API call, and the only source of truth is the system that sent the webhook, you're stuck making a network round trip (or a database query under load) for a value that already flew past you seconds ago as an event.
The fix is to keep a copy. Every webhook is a state update, so route it somewhere built for fast reads instead of re-deriving the current state from scratch each time. Redis is that place: an in-memory store built for exactly this kind of low-latency lookup.
How to Wire a Webhook Source to Redis in ProxyHook
1. Create a Webhook Source
In your ProxyHook dashboard, create a new Source and select Webhook. You'll get a unique endpoint:
https://go.proxyhook.com/A817GH
Point whatever system emits your state changes at that URL. If it's a single event per change, send plain JSON:
curl -X POST https://go.proxyhook.com/A817GH \
-H "Content-Type: application/json" \
-d '{
"event_type": "inventory.updated",
"sku": "SKU-2201",
"count": 42
}'
Every request gets a 200 response immediately, regardless of what happens downstream, so a slow moment on the Redis side never causes the emitting system to back off or retry unnecessarily.
2. Create a Redis Destination
Add a new Destination, select Redis, and enter your connection credentials. Redis is a documented ProxyHook destination built for exactly this: session and state management, real-time caching, and event stream aggregation, the same shape of problem as "give me the current value for this key, fast."
3. Build the Automation
From the Automations tab, create a new Automation, pick your Webhook Source, and add the Redis Destination. Save it, and every event posted to the endpoint starts flowing to Redis immediately.
Filter Out the Events You Don't Need to Cache
A system that emits state-change events often emits more than just the changes. If your inventory system also fires inventory.viewed every time someone looks at a product page, caching every one of those is wasted write volume for data that hasn't changed.
Add a Payload Contents filter step between the Source and the Redis Destination in the Automation builder:
- Key:
event_type - Condition: not equals
- Value:
inventory.viewed
Only inventory.updated (and anything else that isn't a view) reaches Redis. If you're also emitting a distinct event type for a different concern, like inventory.low_stock, and you want that routed to a second destination (say, Slack, for an alert) without touching the cache pipeline, add a second Payload Contents filter with event_type equals inventory.low_stock ahead of that destination. One Source, two Automations, two different jobs, no shared code to maintain.
Debugging When the Cache Goes Stale
If a value in Redis stops updating, the Automation's Logs view is the first place to look. It captures every event that flowed through the Automation, including the exact payload sent to the Redis Destination and the response Redis returned. A spike in non-2XX responses there means events are arriving and getting filtered through correctly, but the write itself is failing, usually a connection issue or an auth problem on the Redis side.
If Logs shows nothing at all for the time window, the issue is upstream of the Automation. Check the Source's own Logs view next: it records the raw request and response for every hit to the endpoint, independent of any Automation built on top of it. No entries there means the emitting system never sent the event, which is a different fix (a misconfigured webhook on their end) than a destination failing to accept writes.
Once you've found the cause and fixed it, whether that's a corrected filter condition or restored Redis credentials, you don't have to wait for the real event to happen again. Replay the logged event from the Source's Logs view and it runs back through the Automation, filters included, so you can confirm the fix worked without waiting for the next inventory change or session heartbeat to occur naturally.
Get Started
Create a Webhook Source in ProxyHook, point your state-emitting system at its endpoint, add a Redis Destination with your connection credentials, and connect the two with an Automation. Filter out the noise events that don't represent an actual state change, and your application gets a fast, current-value cache updating in real time instead of a round trip back to the system that emitted the change in the first place.