Centralizing Webhooks Across Products: Why and How

If several of your products send webhooks, running delivery through one shared system costs less to build, less to operate and less for your receivers. You build signing, retries, delivery logs, failure alerts and SSRF protection once and every product uses them, and your customers get the same format no matter which product sent the event.

This post covers what happens when each product builds its own, the reasons to centralize and public examples, when centralizing isn't worth it, the weak points of a shared system and how to handle them, choosing between an in-house platform and a service, and the migration steps. All sources were checked on 2026-09-30.

What happens when each product builds its own

In short, you end up with the same components built slightly differently once per product, and both receivers and on-call engineers have to learn every variation.

A typical picture: billing signs with HMAC in an X-Signature header and retries three times, accounts sends a static token and no signature, bookings doesn't retry at all. Each works on its own, but the differences add up.

Why centralize

There are six reasons, and they all come from building the same thing once and looking at it in one place.

One signature format

Signature formats differ from sender to sender today. Svix, which started Standard Webhooks, described the problem in its announcement: "the ecosystem is fragmented, with each webhook provider using different implementations and varying quality." Consumers relearn verification for every provider, and providers redo already-solved problems such as security and forward compatibility (Announcing Standard Webhooks, 2023-12-13).

The same thing happens inside one company. If each product signs differently, the same customer writes verification code more than once. Route delivery through one system and there is only one format. The Standard Webhooks technical steering committee includes people from Zapier, Twilio, Lob, Mux, ngrok, Supabase, Svix and Kong (Standard Webhooks), which makes it a reasonable default. The spec itself is covered in Standard Webhooks explained.

Consistent retries and deduplication

Receivers need an event ID that stays the same across retries to drop duplicates. The Standard Webhooks spec defines webhook-id as an identifier that "remains the same no matter how many times a webhook that has failed is retried," and recommends a retry schedule spanning multiple days with exponential backoff and some random jitter (spec).

When each product builds its own, some send no ID and some generate a new one per attempt. One system gives every event an ID under the same rule and retries on the same schedule. See webhook retry design for choosing intervals and handling duplicate webhooks for the receiver side.

One place for logs and monitoring

When a customer says "we didn't get the webhook," the first thing you check is the delivery log. If logs live in a different place per product, you start by working out which product sent it. With one system you search across every product by event ID or customer ID.

Alerts work the same way. You watch the same metrics, how long each endpoint has been failing and the total retry backlog, under the same conditions for every product, and on-call learns one dashboard and one runbook. The metrics are covered in monitoring outgoing webhooks.

Security built once

A webhook sender makes requests from its own servers to whatever URL a customer registers. Register an internal address or a cloud metadata address and you have an SSRF hole. The Standard Webhooks spec recommends sending through a proxy that filters internal IP addresses and putting webhook workers in a private subnet that can't reach internal services (spec).

That protection has to run both at registration and right before each send, and a single gap defeats it. Implement it per product and you have that many places to audit. Encrypted secret storage, secret rotation and static source IPs are the same: build them once and every product gets them. See SSRF protection for webhook senders and rotating signing secrets.

One webhook experience for customers

Customers don't think of these as "the billing webhooks" and "the bookings webhooks"; they're your company's webhooks. One signature format, one retry policy, one set of source IPs, one set of docs and one page for managing endpoints means less integration work and fewer support tickets. See what to put in your webhook documentation and customer-facing webhook portals.

No duplicate implementations

The expensive part of sending webhooks isn't the POST. It's retries, logging, auto-disabling, alerting, secret rotation and the customer portal (the full list is in build vs buy). Build those once per product and you multiply both the build and the maintenance.

The CNCF Platforms White Paper gives two reasons for shared platforms: to "reduce the cognitive load on product teams and thereby accelerate product development and delivery," and to accelerate delivery "by reusing and sharing platform tools and knowledge across many teams in an enterprise" (CNCF Platforms White Paper, "Why platforms?"). Webhook delivery fits that description closely.

Public examples

Large webhook senders deliver events from different products and event types through one system, in one format. Their internal architecture isn't public, but the consistency receivers see is documented.

From the receiver's side, these companies can add products without receivers writing new verification or deduplication code. That's the same outcome a multi-product company is after.

When centralizing isn't worth it

You don't need to centralize if any of these apply:

• Only one product sends webhooks and that isn't going to change
• You deliver to one or two internal endpoints, not to customers
• You have a few event types and customers don't need to see delivery logs
• The sending product is about to be sold or spun off, and a shared system would make the separation harder

In the first two cases, putting sends on your existing job queue is enough. Sign in the Standard Webhooks format from the start anyway, so a later move to a shared system doesn't require receivers to change anything.

Weak points of a shared system, and how to handle them

The risk is that one outage, or one customer's slow endpoint, affects every product. Design it out like this:

The outbox approach is in the transactional outbox pattern, and per-endpoint isolation in multi-tenant webhook delivery.

In-house platform or delivery service

Either one gives you a single system. The difference is how much you build and who operates it.

Delivery services include Svix, Hookdeck Outpost, Convoy and Webhook Admin. Pricing, retention and static IPs are compared in webhook delivery services compared, and building versus buying in build vs buy.

How to centralize

1. Inventory what you send today: which products send webhooks, their event types, signature formats, retry behavior, number of endpoints and receiver docs.
2. Write down shared rules: signature format (we recommend Standard Webhooks), event type naming, retry schedule, timeout, what counts as success, and when to auto-disable an endpoint.
3. Pick the system: build a platform or use a service, using the table above. Make per-product separation of logs and access a requirement.
4. Decide where alerts go: to each product's owners and to whoever watches the whole system.
5. Move one product at a time: start with new event types or the product with the fewest endpoints. Send both old and new signatures during the move, and drop the old one once receivers have switched.
6. Merge receiver docs and settings pages: one place for signature verification, retry policy, source IPs and endpoint registration.

See designing webhook event types for naming and migrating webhook providers for the migration steps.

Centralizing with Webhook Admin

In Webhook Admin, your company is an organization, each product is a project, and each project has a production and a test environment. API keys are issued per environment, so sending access is separated per product.

• A view across all projects: the organization overview shows sends, success rate and endpoints needing attention over the last 24 hours for every project, and you can search production delivery logs across all projects.
• The same signing and retries everywhere: every project signs in the Standard Webhooks format and by default makes up to 8 attempts, including the first, over about 28 hours. Endpoints failing for 5 days are disabled automatically.
• Failure alerts: to Slack, Teams, Chatwork, email or a webhook, per project or for the whole organization in one place.
• SSRF protection: endpoint URLs are checked at registration, and DNS results are checked again right before each send.
• Customer portal: from Starter, your customers can manage their own endpoints, event types, secrets, logs and retries in a portal you embed in your app.
• Audit log, API and MCP: organization actions are recorded, and you can register endpoints and retry failed deliveries through the public API and MCP.

Projects are limited to 1 on Free, 3 on Starter, 10 on Pro and unlimited on Business. Free includes 50,000 messages a month: https://app.webhookadmin.com/signup

FAQ

Is it worth centralizing with only two products?

Yes, if the same customers receive webhooks from both. They get one signature format and one retry policy, and write verification code once. If each product has different receivers and you don't expect more products, keeping them separate is fine.

Doesn't one shared system mean one outage stops every product's webhooks?

Not if you design for it. Persist a message before acknowledging it and deliver asynchronously through a queue. Limit concurrent deliveries per endpoint, pause failing endpoints, and rate-limit the API per product (project). If you use a service, check its published SLA and incident history.

Our products already sign webhooks in different formats. Can we move without breaking receivers?

Yes. Send both the old and the new signature for a while, confirm receivers have switched to verifying the new one, then drop the old one. The steps are in our post on migrating webhook providers.