Skip to main content
Usage is measured in one unit: the event. There’s no per-step, per-feature, or per-seat metering — one dimension, counted the same way everywhere. This page is the whole model of what counts and, just as important, what never does.

​
An event is one capture, or one delivery

Exactly two things count as an event:
  • A capture — a request reaches one of your endpoints and is stored.
  • A delivery — a stored event is forwarded to one destination. Each destination is its own event.
So a webhook captured and forwarded to a single destination is two events; forwarded to three destinations, four (one capture, three deliveries). Deliveries count because delivering does real work on your behalf — reaching out, retrying, signing.

​
What is never counted

The nastiest surprises in usage-based products come from the things you didn’t think you were paying for. webhook.co counts none of the following.
  • Retries. A delivery counts once, when it’s first dispatched — however many attempts the fixed exponential schedule takes to land it. A receiver’s downtime is never your cost.
  • Duplicates that dedup collapses. When deduplication folds a retry into the event you already have, it never becomes a second capture.
  • Verification handshakes. A provider’s GET or echo challenge is a control message — never stored, never counted.
  • Reading your own data. Listing events, inspecting payloads, tailing, and replaying to localhost cost nothing on any surface. (A replay that forwards to a destination is a delivery, and that delivery counts.)
  • Forwarding to your own machine. wbhk listen --forward and wbhk replay POST from your CLI, on your machine — we make no outbound request, so there’s no delivery to count. Only the capture does.
  • A delivery we refuse to send. If a destination’s URL resolves to a private or internal address, we block the request before it leaves our network. Nothing was dispatched, so nothing is billed — however many times a misconfigured URL trips it.
The single lever that most changes your event count is deduplication. With it off, every retry a sender sends is a distinct capture and each one counts — that’s the trade for seeing every raw request. Turn on a dedup mode once a sender’s retries stop being interesting.
Deleting an event does not reduce your usage. You can delete an individual captured event at any time (via the API, the CLI, or an MCP agent) — its content is redacted immediately and its stored payload body is purged shortly after, so it can no longer be read or replayed. But the event was already counted when it was captured, so deleting it never lowers what you were billed. This is deliberate: a metered unit you can un-count by deleting after the fact isn’t an honest counter.

​
The metering model

Two principles fall out of the single unit above:
  • One dimension, disclosed up front. You’re metered on events and nothing else, and the unit is stated where you create an endpoint — there’s never a hidden counter running behind a feature you didn’t know you’d triggered.
  • A soft cap that pauses, not a surprise bill. The design is to alert you as you approach a limit and then pause capture rather than run up an overage. Your captured data stays exactly where it is; you resume by raising the limit.

​
Check your usage

Your current usage is available on every surface (the whk_ key needs billing:read):
The dashboard shows the same figure at app.webhook.co/usage.