Webhook Pricing Models: Per-Event, Per-Seat, Self-Hosted

Webhook gateway infrastructure is usually priced one of four ways: per inbound event, per delivery, per seat, or self-hosted with no vendor invoice at all. Each model is predictable in one regime and painful in another. Per-delivery billing charges you for fan-out, per-seat billing charges you for hiring, and self-hosting charges you in engineer-hours nobody put on a purchase order. The unit being metered matters more than the headline price.

Teams discover that late. Two services can advertise similar monthly prices and differ by an order of magnitude on the same workload, because one counts the webhooks that arrive and the other counts the requests that leave. Only one of those tracks your business volume.

Why webhook pricing is hard to compare

The category has no shared unit. Vendors meter inbound events, outbound deliveries, active destinations, workspace seats, or some combination, and the pricing page rarely says which one moves when your traffic moves.

Take a concrete workload. You receive 50,000 Stripe events a month, and each has to reach three internal services: a billing worker, an analytics pipeline, a Slack notifier. Under an inbound meter that is 50,000 billable units. Under a delivery meter the same traffic is 150,000. Nothing about your business changed; the arithmetic did, because the second model counts fan-out you would have done anyway.

Now add a bad afternoon. One destination returns 503s and the gateway retries each delivery six times before giving up. If retries are billable, someone else’s outage lands on your invoice. For a product-by-product view rather than the models behind them, we keep a separate piece on how the main webhook gateways compare.

Table: the four common pricing models, the unit each one meters, and the workload shape that makes each one expensive.

Model 1: per-event, metered inbound

The meter runs when a webhook arrives at your ingest URL. One POST from Stripe, one billable event. It maps cleanly onto how a business grows: more orders means more order.created webhooks means a bigger bill, in roughly linear proportion, and you can forecast it from your own dashboards.

One question decides whether the model holds. If the vendor charges per inbound event and per outbound delivery, you are on a hybrid and the inbound price is half the story. Ask directly: if this event has to reach four destinations, do I pay once or four times? That answer moves the effective price by 4x and is not always on the pricing page.

Model 2: per-delivery

The meter runs on the way out: each attempted request to a destination is a billable unit, so one event delivered to four services costs four units.

The problem is not the price. It is what the price does to your architecture. Once fan-out is metered, every new consumer carries a line-item cost, and engineers respond rationally: they stop adding destinations. Instead of routing payment.succeeded to three small, independently deployable services, someone builds one fat endpoint that receives everything and re-dispatches internally — a message bus rebuilt inside your application, badly, to avoid a billing line. The coupling that costs you is invisible on the invoice; the deliveries you avoided are visible.

Per-delivery billing also transfers other people’s reliability problems onto your bill. Retries are deliveries, and a sane gateway makes a lot of them — exponential backoff is designed to keep trying long after a destination stops answering. A destination down for two hours produces the same events, more attempts, and a larger invoice, at the moment you are least interested in your gateway’s pricing. Find out whether retries are billed before anything else — some vendors bill only the first attempt, which removes most of the sting.

Model 3: per-seat

Seat-based pricing decouples cost from traffic entirely. You pay for people with dashboard access, not for the webhooks they watch. For a small team with heavy volume that can be the cheapest arrangement available, and the bill moves only when headcount does.

It also punishes exactly the behavior you want. Support wants to check whether a customer’s order actually fired, and an ops engineer wants the delivery log during an incident. When each of those is a purchasing decision, teams share one login and lose the audit trail that made the dashboard worth having. Check whether read-only access costs the same as full access.

Model 4: self-hosted

Run the queue yourself and there is no per-event fee at all. For teams already operating Postgres, a job runner and an on-call rotation, this is a legitimate answer — the marginal cost of one more consumer of existing infrastructure can be near zero, and a Postgres job queue on SKIP LOCKED is a smaller lift than a broker.

The bill still exists; it is denominated in engineer-hours. Signature verification per source, exponential backoff with jitter, per-destination circuit breakers, a dead-letter queue with replay, per-attempt history you can search. None of these is hard in isolation. Together they are a product, and the maintenance never finishes: someone owns it during the incident, someone answers “did this webhook arrive?” at 23:00. We worked through that in detail in a separate article on the real cost of running it yourself.

The trap is not that self-hosting is the wrong answer. It is that its cost rarely enters the comparison, so it always appears to win.

The overage trap

Every metered model needs a rule for what happens at the quota line, and this is where a reasonable price becomes unpredictable.

Usage-based overage means the meter keeps running past your plan limit at a per-unit rate. For gradual growth that is fair. The failure mode is that webhook traffic is not always yours to control. A provider replays a backlog after their own incident. A misconfigured source starts sending every state change instead of the three you subscribed to. A system you do not own decides what your invoice says, and you find out at the end of the month.

Three designs are common:

• Hard cap. Traffic above quota is rejected. Predictable cost, at the price of dropped events — usually the wrong trade, since the provider will not hold them for you forever.
• Soft buffer. A defined allowance above quota is served at no charge, and sustained overuse becomes a conversation about moving up a plan rather than a line on the invoice.
• Metered overage with a spend alert. The overage is billed, but you are told as it accrues. Better than silence, still reactive.

Ask the operational question rather than the pricing one: at 101% of quota, does my event get delivered, and does anyone tell me?

What to check before you sign

• Is fan-out billed? One event to four destinations: one unit, or four.
• Are retries billed? Specifically, retries against a destination that is failing.
• What counts as an event? Health checks, test pings from a provider’s dashboard and payloads that fail signature verification are all arriving HTTP requests.
• What is the retention window? Retention is a cost lever dressed as a feature — and a 24-hour window makes a bug reported Monday about Friday’s webhook unresolvable. It is also a compliance lever, because stored payloads are usually personal data.
• Does replay cost extra? Replaying a thousand dead-letter events is a thousand deliveries under some meters.
• What does an annual commitment buy? A yearly cycle is normally a discount for paying up front, not a different product. Check what is actually fixed for the year — the price, or the quotas as well — and what happens if you upgrade in month three, or need to move back down in month nine.
• Which limit binds first? Sources, destinations, seats and events all have ceilings. The one you hit first is your real plan, whichever the pricing page leads with.

A worksheet you fill with your own numbers

Reduce every candidate to one comparable figure:

effective cost per inbound event = monthly bill / events received in your busiest month

Use the busiest month, not the average — averages hide the spike that overage billing charges for.

Table: fill the middle column from your own traffic, then run each vendor’s model against it.

Two rows do most of the work. If destinations-per-event is above one, per-delivery pricing costs a multiple you can calculate exactly. If your worst month sits well above average, the overage rule matters more than the base price.

How Webhooker prices it

We chose the inbound meter for the reason the worksheet points at: it is the only unit that tracks your business rather than your architecture.

One event is one inbound webhook received on your ingest URL. Fanning it out costs nothing extra — you can fan out to many destinations without paying per delivery, so routing order.created to five services is an architectural decision, not a budget one. Delivery retries are not new events either; the meter runs once, at the door.

On quota, there is no overage billing. Usage up to 120% of your monthly quota is allowed at no charge on every plan. If you pass that buffer regularly, the next plan up is simply cheaper, and we would rather say so than bill the difference. Paid plans are billed in euros with a VAT invoice, monthly or yearly.

The yearly cycle is twelve months at the price of ten: Pro €290 a year instead of €348, Team €990 instead of €1,188, with the same quotas, retention and features either way. You pick the cycle at checkout, and Free has no yearly option. Event quotas stay monthly on a yearly subscription, so the cycle changes what you pay, not how the meter runs.

Retention is a cost lever for us as for everyone, so we will name ours: 14 days on Free, 30 on Pro, 90 on Team, deleted automatically at the end of the window. Ordered delivery and a static outbound IP are Team-plan features. Quotas, sources, destinations and seats are laid out on the per-event plans with no overage billing page.

To test the arithmetic against real traffic, start on the free plan — 10,000 events a month, no card, the same ingest path as the paid tiers. Point one live source at it for a week and read the numbers off your own dashboard.

Frequently asked questions