Relay: Bufferwebhook receipt + retry
Know which webhooks never arrived — and get them back.
Relay sits in front of your endpoint, counts every webhook the moment it lands, and re-sends the ones that fail — so a restart, a crash or a busy spell is never a silent loss.
Free while we're onboarding the first teams — no card, nothing charged. Fixing n8n webhook reliability specifically is priced at $19/mo flat, no metering (checkout is in Stripe test mode today — a real card won't be charged). What Founding Access doesn't include yet is written down further down this page. Rather ask a question before you connect anything? Email us.
Without Relay
$ POST /webhooks/stripe # the lead your endpoint never saw
… no error, no queue, no trace. The event is gone and nothing on your side ever knew it existed.
With Relay
$ POST /webhooks/stripe # the lead your endpoint never saw
200 {"status":"queued","requestId":"req_8f3e"}
- attempt 1 → 503 · retry queued
- attempt 2 → 503 · retry queued
- attempt 3 → 200 ✓ · delivered
$ curl -X POST https://relay.example/in/acme/orders/{ingest-token} -d @event.json
200 {"status":"queued","requestId":"…"}A replayed example of the request/retry shape, not a live feed.
Proof of receipt
The receipt Stripe's timeout never gives you.
This is the receipt Stripe's timeout never gives you. Sign up, fire one request, and this row is yours in under a minute.
Delivery log — one row, the shape of the data
req_8f3e29c4 · 2026-08-10T11:42:07Z · POST /in/acme/orders · attempt 1→503 · 2→503 · 3→200 ✓ deliveredWhat it does
The part of the pipeline that exists today.
One route is built, tested and running against a real queue. It accepts at the edge, retries with backoff, and records every attempt — so a silent stop on your side is never mistaken for a webhook that never arrived.
Answers fast, always
BuiltRelay accepts the payload at the edge, returns a 200 as soon as it is safe, and only then involves the queue. Your endpoint never adds to the sender’s wait.
Retries until it lands
BuiltWhen your endpoint answers 5xx or times out, Relay tries again with backoff instead of treating the event as dead. It only stops when the retry budget runs out.
Nothing vanishes silently
BuiltEvery attempt is written to a delivery log. When the retries run out the payload moves to the dead letter queue, with its failure reason, so you can read it — or retry it by hand.
For n8n users
n8n's Webhook trigger has documented, current reliability bugs.
If you're running Stripe, Shopify, or anything else through n8n, you've probably hit one of these. Relay sits in front of n8n's Production Webhook URL — here's what that actually changes, and what it honestly can't, stated the same way the setup guide states it.
Webhooks randomly stop firing
Relay fixes thisThe Webhook trigger can silently stop listening until you manually toggle the workflow off and on. Anything sent during that window is gone.
community.n8n.io — "Not Sustainable" ↗API-activated workflows can go live dead
Relay can't fix this — makes it visible insteadActivating a workflow through n8n's REST API doesn't always register the webhook path — a CI/CD-deployed workflow can be "active" with nothing listening until someone re-saves it in the UI.
GitHub n8n-io/n8n #21614 ↗n8n Cloud's 100-second timeout
Relay fixes the sender-facing partA hard Cloudflare timeout fails any workflow that takes longer to finish, regardless of what it was doing.
n8n docs — common webhook issues ↗Production webhook can return 200 with nothing behind it
Relay can't fix this — makes it visible insteadA still-open report: the Production Webhook answers 200 OK on both n8n Cloud and fresh self-hosted workflows with nothing actually registered.
GitHub n8n-io/n8n #16339 ↗A single flat n8n tier — $19/month, no metering.
Point a route at your n8n Production Webhook URL and get retry with backoff, a delivery log, and a DLQ with header-replay for anything n8n doesn't answer for. Read the full setup guide.
Security
Built to hold your client's credentials, not just your traffic.
This is what's checked and true in the codebase today — not the roadmap. Nothing below is a compliance certification; it's what a code reviewer would find.
Destination credentials, encrypted at rest
BuiltA CRM bearer token, a signing secret, an n8n webhook key — anything you configure for a route is AES-256-GCM encrypted with a random IV per value before it touches the database. A database dump does not yield a usable credential.
Every destination checked before it is queued
BuiltA route pointing at cloud metadata, localhost, or an internal RFC-1918 address is rejected at ingest, before the payload is ever queued for delivery — not a promise, a check that runs on every request.
CI gates on every commit
BuiltGitleaks for secrets, Semgrep for static analysis, and Trivy for dependency vulnerabilities all run on every push and pull request, and each fails the build on a CRITICAL or HIGH finding.
Public vulnerability disclosure
BuiltA published policy with stated response SLAs — 24 hours for anything that could touch another team’s data. Report to info@coreframe-labs.dev; safe-harbor terms apply to good-faith testing.
Founding Access
Founding Access — free while we're onboarding the first teams.
No card, nothing charged. Buffer is built and running; pricing arrives once usage-based billing ships. This is the honest state of the product, not an introductory discount.
Free during Founding Access
no card · nothing charged
Founding Access runs on the real pipeline, not a sandbox.
- Real webhook receipt, retry with backoff, and a delivery log — the same pipeline every tier will run on
- DLQ replay by hand for anything that permanently fails
- Destination auth headers encrypted at rest (AES-256-GCM)
- Unlimited routes — nothing meters or caps a path today (see below)
General usage-based pricing for the rest of the Buffer ladder hasn't shipped, so there's no honest number to give you for it yet. If you're here for n8n webhook reliability specifically, that tier is real and live today: $19/mo flat, no metering, no trial clock. See pricing and pay with Stripe.
Why it's free right now
- Event metering, tier caps, log retention tiers and a trial timer are not built. None of the four exist as code yet, so nothing here can be honestly metered or billed.
- Charging for a promise the software can’t yet keep is worse than not charging. Founding Access removes the promise instead of faking the enforcement.
- Support is one person, best effort, no stated hours.
What Founding Access doesn't include yet →
- Delivery is at-least-once. "at-least-once delivery — your handler has to make it exactly-once". A sender that retries will deliver the same event again, and Relay will faithfully pass it on both times; deduplication stays in your handler. Every attempt rides one requestId, so a duplicate is visible, never hidden.
- Your endpoint's own bugs. Relay will deliver a webhook your handler mishandles, log the 4xx, and land it in the dead letter queue. It cannot make the handler correct.
- A payload over 1 MiB. Over-cap bodies are refused with a 413 before they are buffered — counted as they stream, never silently truncated. DLQ retry replays the original request headers, so a vendor signature (Stripe-Signature, X-Hub-Signature-256, X-Shopify-Hmac-SHA256) is replayed byte-identically on rows written after this shipped. DLQ rows written before it has no headers to replay — that's the one remaining edge case, and the confirm dialog says so per-row.
- A payload between 64KB and 1 MiB, if it lands in the DLQ. Delivery and retry work exactly like any smaller payload up to that point. But the DLQ only retains a payload's body for manual replay up to 64KB — a bigger one that ends up in the DLQ is still logged (requestId, status, timestamps, headers) with nothing hidden, it just has no body to re-send. The Retry button is disabled on that row and says why, rather than offering a retry that would silently fail.
- No billing, no metering, no caps. Founding Access is free, full stop, until usage-based billing ships — there is no trial clock counting down underneath it.
Free, no card, nothing charged. What's not built yet is above.
Not ready to connect anything yet? Read the three things to get right →
- Answer senders fast, then finish the work. Stripe and most vendors time out in a few seconds. Acknowledge with a 2xx the moment the event is durably queued — before your own slow pipeline runs — or the sender treats the event as failed.
- Make handlers idempotent. Senders retry. Key your writes on the event id so a retried webhook is a no-op, not a duplicate charge or a duplicate CRM lead.
- Keep a record you can grep, with a replay path. Every inbound event needs a durable receipt the moment it lands — and a way to send it again after a restart — or the first sign of a loss is a human asking where the lead went.
A deeper technical write-up of all three is in progress.
Sign in if you already have an account.