DEV Community

ReceiveHQ
ReceiveHQ

Posted on

Retries, resend, and the same message to different endpoints

I'm Sebastian, CTO at ReceiveHQ (Cortena B.V.). Use-case #5: after fan-out, recipient filters, and anti-spam, what happens when your webhook hiccups — or when you need that stored message somewhere else.

The problem

Topics 2–4 got one inbound domain onto several least-privilege webhooks, with junk stopped before HTTPS. That still leaves the operational reality: handlers go down, deploys wedge, and a single message sometimes needs to land on a second endpoint after the fact (new staging sink, rebuilt worker, audit copy).

US-first inbound relays often bury retry policy in a black box, or leave you fishing for raw mail in a support ticket when you need a clean resend. We wanted delivery evidence you can open yourself — on German baremetal.

Retry at the relay, not in every handler

ReceiveHQ's spine stays the same: MIME parsed once on German baremetal, then per-endpoint delivery. Retries are per endpoint, so a flaky staging sink does not stall production:

Control What it does
Automatic backoff 1m → 5m → 30m → 1h → 2h after non-success
Per-endpoint max attempts Cap how hard each webhook is pushed
HTTP 406 Permanently drop that delivery (no more retries)
2xx Success — stop the schedule

At-least-once delivery still means handlers should be idempotent. What you get back is request/response attempt logs plus the retained raw .eml (14-day evidence window) — not a shrug and a ticket.

Resend when you need a second shot

From the activity console or MCP you can:

  • Search messages and inspect each delivery attempt
  • Open the raw .eml
  • Resend with optional To / OriginalRecipient overrides
  • Point a resend at a different webhook endpoint when you need the same stored message on another sink

That pairs with multi-endpoint fan-out: live traffic can already hit prod + staging; resend covers the "we added a sink later" and "replay after the outage" cases without a second MX or a mailbox dump.

Why this cut of the story matters

We built ReceiveHQ after years on Postmark inbound — great product, wrong continent — and after deciding finance-critical mail shouldn't share infrastructure with the spammers next door. Retries and resend are part of that posture: residency in Germany, short EU-heavy subprocessor list, and delivery evidence you can show when a customer asks what happened to invoice mail at 02:17.

Anti-spam decides whether a message deserves a webhook. Retries and resend decide how it survives your stack's bad day.

Setup sketch

  1. https://receivehq.com — magic-link sign-in
  2. Domain + MX → mx.receivehq.com, verify
  3. Keep existing webhook endpoints (and filters / anti-spam from prior posts)
  4. Confirm per-endpoint attempt limits fit your SLOs
  5. On a failure: console or MCP → inspect attempts → resend (optionally to another endpoint)

Docs: https://receivehq.com/mcp.md · Trust: hosting · DPA · sub-processors

Next

European / German baremetal hosting details — what stays in the EU.

Try: https://receivehq.com · €10/mo or €100/yr · 100k inbound · first 10 free

Disclosure: I work on ReceiveHQ as CTO & Co-founder of Cortena B.V.

Top comments (0)