Forwarding & replay

Delivery you can audit, replay you can trust.

Capture is only half the job, the webhook usually needs to reach your system too. WebhookVault relays every capture through a durable outbox: the delivery obligation commits in the same transaction as the capture, so an acknowledged webhook can never lose its way to you.

Start free Delivery states explained

The outbox, plainly

When a webhook lands, its delivery job is written inside the capture transaction, then a worker picks it up the moment it commits. No polling interval to wait out. Failures retry with exponential backoff; exhausted deliveries park in a dead-letter state you can see and restart. Kill the process mid-burst and every obligation survives.

  • Every attempt recorded: status, duration, error, retries and replays alike
  • Rate-smoothed per destination, a 500-request replay won't stampede your server
  • SSRF-guarded targets: private and internal ranges refused at connect time
sender capture + job one transaction 200 = stored wake dispatcher you retry · 1m · 4m · 16m … → dead-letter (replay restarts)

Replay: the vault's second act

Anything the vault holds can be delivered again, to the original destination after you fix the bug, or pointed at staging to reproduce it. Replay one request inline and watch the outcome, or queue hundreds in bulk through the same audited pipeline.

  • Replays appear in the same attempt ledger as automatic retries
  • Truncated-body requests refuse to replay rather than lie to your server
  • Bulk replay from the explorer or one API call
Replay via API →
The delivery panel of a captured request showing payload and the recorded delivery attempts.

the attempt ledger, nothing to reconstruct, it's all written down

Relay with receipts.

Forwarding is on every plan, point an endpoint at your URL and watch the ledger fill.

Start free Read the docs