n8n integration
Reliable n8n webhooks with persistent buffering
n8n is a phenomenal automation tool, but self-hosted n8n containers restart — for deploys, dependency upgrades, OOM kills. Cloud n8n has scheduled maintenance windows. During any of these, incoming webhooks go to a 502 and the sender (Stripe, Polar, GitHub) may stop retrying long before n8n is back.
Last updated: 2026-05-01
TL;DR
Point your webhook source at Zalapier instead of directly at n8n. Zalapier persists every payload to Postgres, then forwards to n8n. When n8n restarts, the events queue and replay automatically — your workflows never miss an input.
The n8n-restart problem
Self-hosted n8n is a Node.js process. Process restarts — for code reloads, dependency updates, container redeploys — typically take 10-60 seconds. During that window the webhook URL returns connection-refused or 502. Most senders treat that as a failure and retry, but the retry window is bounded.
If you're running scheduled n8n upgrades, deploying multiple times a day, or running on a cluster that occasionally evicts pods, you're statistically losing webhooks. You may not notice until a customer asks why their automated email never went out.
Buffered ingestion fixes it
Zalapier sits between your webhook source and your n8n instance. The source POSTs to a Zalapier URL; Zalapier returns 200 immediately after persisting to Postgres. Then Zalapier delivers the event to your n8n webhook node. If n8n is restarting, Zalapier retries with exponential backoff — typically the n8n restart finishes within the first retry window.
From your n8n workflow's perspective nothing changes — it still receives the same payload at the same webhook URL (the only swap is where the source POSTs first). All of n8n's existing workflow logic, conditional nodes, and credentials work unchanged.
Plays well with self-hosted and Cloud
Zalapier doesn't care whether your n8n is self-hosted on a VPS, on Kubernetes, or on n8n Cloud. As long as your n8n webhook URL is reachable from Zalapier's egress IPs, the buffer pattern works identically.
Buffer your n8n webhooks in 3 minutes
-
1
Create a Zalapier endpoint
Sign up free and create a webhook endpoint. Copy the unique URL Zalapier gives you.
-
2
Add your n8n webhook node URL as a destination
Grab the webhook URL from your n8n workflow's Webhook trigger node and paste it as a destination in your Zalapier endpoint.
-
3
Repoint the webhook source
Wherever the webhook used to point at n8n directly (e.g., your Stripe dashboard), change it to your Zalapier endpoint URL. Webhook traffic now flows: source → Zalapier → n8n.
-
4
Restart n8n on purpose to verify
Stop your n8n container while sending a test webhook to Zalapier. Watch Zalapier mark the delivery as 'retry'. Restart n8n and watch Zalapier deliver successfully on the next backoff tick.
Frequently asked questions
Does this work with self-hosted n8n? ⌄
Yes. As long as your n8n instance is reachable from Zalapier's outbound traffic, the buffer pattern works for self-hosted, Docker, and n8n Cloud equally.
What about authenticated n8n webhooks? ⌄
Zalapier forwards request headers, including custom auth headers you configure on the destination. Outbound requests are also signed with X-Zalapier-Signature so your n8n workflow can verify origin.
How does this affect n8n's billing? ⌄
If you're on n8n Cloud's per-execution pricing, you still pay for each n8n execution Zalapier triggers. Zalapier doesn't reduce executions — it just makes sure they happen reliably even when n8n was briefly unavailable.
Can one Zalapier endpoint fan out to multiple n8n workflows? ⌄
Yes. Add each n8n webhook node URL as a separate destination on the same Zalapier endpoint. One inbound event triggers all destinations in parallel.
Stop losing events when n8n restarts
Free for 1,000 events/month. Set up in 3 minutes. No credit card.
Start free — no credit card →