Build vs Buy Webhook Infrastructure

Building your own webhook infrastructure looks cheap because the first version is: an HTTP endpoint that returns 200 OK. Most of the cost arrives later, in verification, retries, idempotency, replay and compliance. The build vs buy decision for webhook infrastructure depends on your scale, your team and how central webhooks are to your product. Below is a breakdown of both sides, plus a cost model you can copy.

The “it’s just an endpoint” trap

Almost every webhook project starts the same way. A provider needs somewhere to POST events, you add a route, parse the JSON, write a row to your database, and return 200. It works on the first try, and after the demo it looks done.

That naive receiver is fine for a while. If you get a handful of low-stakes events a day and it does not matter much when one goes missing, you may never need anything more, and that alone can settle the decision. Not every webhook needs a gateway, and not every integration needs webhooks rather than a polling job.

The trap is assuming the afternoon version scales with your business. The gap between “returns 200” and “never loses a payment event, even when a downstream service is down for twenty minutes” is where most of the engineering lives, and none of it shows in the demo. It shows up later, when a downstream service fails on a Saturday and nobody can say which events made it through.

What you actually have to build

Once webhooks carry something that matters, the checklist grows fast. A production receiver needs the following.

Signature verification. Providers sign payloads so you can prove the request came from them and was not tampered with. Most use HMAC-SHA256, some still use SHA1, and the exact scheme differs per provider: which headers to read, what to concatenate (compare Stripe’s signed payload with GitHub’s), and how to handle timestamps to block replay attacks. You verify before you trust, and you keep every scheme current. The full security model is one article on its own; multiply it by every provider you integrate.

Async ingest. If you do the processing inside the request handler, you tie the provider’s timeout to your slowest dependency. When your database is slow, the provider sees failures and starts retrying, which makes your slow system slower. The fix is to accept the event in milliseconds, persist it, and process it out of band.

A durable queue. “Persist it” means a store that survives a crash and lets multiple workers pull jobs without handing the same event to two of them at once. On Postgres that is SELECT ... FOR UPDATE SKIP LOCKED. Straightforward to write, less straightforward to keep fast under load.

Retries with backoff. Destinations fail. When they do, you retry, but not immediately and not forever. You want exponential backoff with jitter, and you want it conditional on the response: a 429 or 503 deserves another attempt, a 400 never will, so retrying it just wastes work. Retrying at all means accepting duplicates, so your consumers need idempotency keys too.

A circuit breaker. When a destination is fully down, hammering it with retries helps no one. A per-destination breaker notices the failures, stops sending for a cool-off window, and lets traffic back gradually; the circuit breaker pattern describes the closed, open and half-open states in detail.

A dead letter queue and replay. Some events exhaust their retries, and they cannot just disappear. They go to a DLQ, and you need to replay them, one at a time or in bulk, once the downstream is healthy again.

Delivery history. When someone asks “did event X arrive, and what did the destination say?”, you need a per-attempt record: timestamp, status, response body. Without it you are debugging blind.

A fixed egress address. The moment one destination is inside a corporate network, their security team asks which IPs you deliver from. Answering that means pinning static outbound IPs, which most serverless platforms cannot give you and which rules out the cheapest hosting option.

Alerts, metrics and rate limiting. You want to know before your customer does. That means email or paging alerts on failure spikes, Prometheus-style metrics for queue depth and delivery latency, and per-source rate limiting so one noisy provider cannot swamp everything else.

None of these are exotic, and each has a known solution. The cost comes from having ten of them that interact with each other and all have to work at 3 a.m. A managed gateway covers the same list; the Webhooker overview shows how it is split into ingest, verification and delivery.

The hidden operational cost

Writing the code is the piece you can estimate. What happens after it ships is harder to predict.

You now own an on-call rotation for delivery outages. When a downstream integration goes down at the weekend and events pile up, someone has to notice, drain the backlog and confirm nothing was lost. Workers need scaling as volume grows, which means capacity planning and load testing for a subsystem that is not your product.

Then there is retention and compliance. You are storing payloads that may contain personal data, so you inherit retention policies, deletion, region guarantees and possibly a DPA. And providers change their signature schemes and event formats; keeping current across several of them is a small but permanent tax on someone’s week.

None of this appears in the build estimate, because the estimate covers a one-time build and this is a system you maintain for as long as it runs.

When building is the right call

Buying is not always the answer. Building your own makes sense in several situations.

At extreme scale, a per-event price that is comfortable at a million events a month can dominate your bill at a few billion, and a dedicated team amortises nicely against that. If your routing is unusual (fan-out to internal buses, complex conditional logic, tight coupling to proprietary systems), an off-the-shelf gateway may not bend the way you need. If you already run a platform team with mature queue and on-call infrastructure, webhooks are a smaller addition than they would be for most. And if a per-event plan hits a cost floor that your own hardware clears, the math can favour building.

As a rule, build when webhook infrastructure is close to your core competency, or when your scale or requirements sit far enough from the mainstream that a general tool cannot serve them well.

When buying wins

For most teams, most of the time, the numbers point the other way.

If you are a small team, every hour spent on delivery plumbing is an hour not spent on the product only you can build. If your webhooks carry payments or billing events, at-least-once delivery and a replayable DLQ become requirements, because a lost event leaves a ledger that does not reconcile. If you integrate with several providers, you multiply the verification-and-quirks work by the number of providers, and a gateway that normalises all of them pays for itself quickly. And if you have compliance needs, region-locked storage and a DPA, buying a service that already provides them is far cheaper than building and auditing your own.

Flip the same rule around and you get the buy case: reach for a gateway when webhook infrastructure is necessary plumbing rather than a differentiator, which for most products it is. If you land there, Webhooker, Svix and Hookdeck compared is the next decision, and the three do not solve the same problem.

A cost model you can copy

General arguments only go so far. The model below takes your own rates and hours.

Cost to build (one-time):

build_hours       = verification + async ingest + queue + retries
                    + circuit breaker + DLQ + replay + history
                    + alerts + metrics + rate limiting + tests
build_cost        = build_hours * your_blended_hourly_rate

A production build takes engineer-weeks. Use your own team’s velocity, and count the operational pieces as well as the happy path.

Cost to run (recurring, monthly):

run_cost_monthly  = maintenance_hours_per_month * hourly_rate
                    + on_call_load
                    + infra (compute, storage, backups)

Cost to buy (recurring, monthly):

buy_cost_monthly  = plan_price_for_your_event_volume

Then compare:

For most teams, opportunity cost is the row that decides it. For reference, Webhooker’s plans run Free at €0 (10k events/month), Pro at €29 (100k events), and Team at €99 (1M events); pricing lists what each plan includes. Set your build hours beside twelve months of the plan that fits your volume, and remember to add the monthly run cost to the build side.

A middle path: buy the gateway, keep your logic

Build-versus-buy is rarely all or nothing. For many teams the practical option is to buy the generic infrastructure and keep the logic that is specific to your product.

A gateway handles ingest, verification, the durable queue, retries, the circuit breaker, the DLQ, replay and delivery history. Your code keeps the business logic that runs when a verified event arrives. Delivery from a gateway is still at-least-once, so that logic still needs its idempotency keys.

Webhooker takes the verification, retry, circuit breaker, DLQ and replay work off the build list and runs in the EU with a DPA on paid plans, which covers the compliance row of the table (the Free plan is enough to point a provider at it and watch deliveries). Before comparing products, what a webhook gateway is walks through each of those layers and the cases where a plain receiver is still enough.

Frequently asked questions