About

Built because we needed it. Kept because you might.

WebhookVault grew out of running webhook infrastructure for a regulated fintech, an environment where "did the webhook arrive?" is a compliance question and "we don't keep those" is not an acceptable answer.

The story

From compliance question to product

Webhooks treated as records, not traffic. That conviction predates the product.

The internal version captured payment-gateway callbacks: stored in full, replayable when a downstream fix landed, auditable when a bank asked. It worked so well that the interesting question became, why does everyone else treat webhooks as traffic to be piped and dropped?

So we rebuilt it from a clean sheet as a product. Same convictions, production-grade bones: durable capture (an acknowledged webhook is a stored webhook, the 200 and the write are the same transaction), honest limits (soft caps, visible degradation, no surprise bills), mandatory two-factor on every account, and the retention window as a first-class part of the product rather than fine print.

The convictions, in one place

  • The vault never lies. Stored means stored. Truncated says truncated. Throttled is counted where you can see it.
  • Absence is the interesting failure. Watchdogs exist because the most expensive webhook problems produce no error anywhere.
  • Small and sharp beats big and vague. Published limits, published prices, a contact page a human answers.

Contact

Reach us through the contact page: product questions, abuse reports, data requests, or just to tell us what the vault should keep next.

Point a webhook at the vault.

Free tier, no card, a capture URL in under a minute.