Hookproofwebhook reliability testing
Sample runFixed sample target — this field is not editable. Runs against your own endpoint are scoped per engagement: get in touch.
Press Run suite to replay a recorded run — seven attacks, against two receivers built to prove the engine works.
What Hookproof is
Hookproof is a webhook reliability testing tool. It sends deliberately adversarial requests to a webhook receiver — replays, duplicate delivery IDs, concurrent duplicates, out-of-order delivery, stalled deliveries, malformed payloads and invalid signatures — and reports which ones the receiver handled incorrectly.
There are seven checks. Each one has a single predetermined correct behaviour:
replay— an already-processed delivery, resent verbatim, must be applied exactly once.duplicate-delivery-id— two different payloads sharing one delivery ID must be applied once.concurrent-duplicate— two byte-identical deliveries sent in parallel must be applied once, not twice.out-of-order-delivery— events arriving as [3,1,2] must be applied as [1,2,3].delay-mid-delivery— a request stalled mid-body must be cut off, not held open past the timeout you enforce.malformed-payload— a truncated JSON body must be rejected with 400, not 500.bad-signature— an invalid signature must be refused and never applied.
We sign requests the way your sender does — GitHub, Stripe, Svix and Shopify signature formats are supported out of the box, or tell us your own scheme.
Webhook receivers fail in specific, documented ways
These are not exotic edge cases. Published integration guides describe them as non-negotiable requirements rather than features to add later — and they keep reaching production anyway.
Signatures go unverified
A request with an invalid or missing signature gets processed anyway.
Retries get applied twice
A replayed delivery is applied again instead of being recognised as a duplicate — the double-charge bug.
Order isn't guaranteed
Events arriving out of sequence get applied out of sequence, instead of buffered and reassembled.
Stalls aren't enforced
A deliberately slow, half-sent request is patiently completed instead of timed out.
Malformed bodies 500
A truncated payload produces a generic server error instead of a clean rejection.
Deduplication isn't atomic
Two copies of the same delivery arrive at once, both pass the "have I seen this?" check before either is recorded, and both get applied.
How it works
-
You nominate an endpoint
One URL, plus a shared signing secret so legitimate requests can be signed correctly, and which signature format your sender uses. No access to your code, your data, or anything inside your systems.
-
The suite runs against it
All seven attacks, each compared against its one predetermined correct behaviour. Every response is recorded — status code, timing, body. If the endpoint can't be reached, or refuses a correctly signed test delivery, the run stops and tells you why rather than reporting verdicts about an endpoint it never reached.
-
You get a report in two parts
How much we can settle ourselves depends on what you can tell us. In the common case — no state endpoint, and you haven't told us the request timeout your endpoint enforces — one check is settled and six come back as questions. Give us your declared timeout at intake and that becomes two settled, five asked. Expose the optional staging endpoint as well and all seven are settled. The questions are never guesses: for each one the report states exactly what we sent, and asks you to confirm from your own records what your system did with it. A question is not a failure.
-
Or skip the questions entirely
Expose a small read-only endpoint in staging that reports how many times a given test run was applied, and all seven checks are settled automatically — one round trip instead of two. It's a few lines, it's optional, and it never touches production. Read the spec.
Questions
What is webhook reliability testing?
Webhook reliability testing sends deliberately hostile traffic to a webhook receiver to find out how it behaves under conditions it will eventually meet in production — retries, duplicates, events arriving out of order, stalled connections, and forged signatures.
What does Hookproof actually check?
Seven things: replayed requests, two requests sharing one delivery ID, two identical deliveries sent in parallel, events delivered out of sequence, a delivery stalled mid-request, a malformed payload, and an invalid signature. Each check has one predetermined correct behaviour, and the report names every mismatch.
Don't we already test this?
Most teams test the happy path. These specific failures are documented repeatedly as reaching production anyway — double-charged retries, wrong balances after a failed rollback, duplicate credits. The report either finds them in your receiver or it doesn't.
Is this a load test?
No. Load testing asks whether your receiver survives volume. Hookproof asks whether it stays correct when the same event arrives twice, late, out of order, or signed wrong — a correctness problem, not a capacity one.
Do you need access to our code or data?
No. Hookproof needs one URL you nominate for testing, an agreed signing secret, and the signature format your sender uses. It reads no customer data and touches nothing inside your systems. That boundary is also why most of the seven checks end in a question rather than a verdict by default: whether a duplicate was actually applied is only visible from inside, so we tell you exactly what we sent and you confirm it. Two things shrink that list — telling us the request timeout your endpoint enforces, and optionally exposing a small read-only endpoint in staging. With both, we settle all seven ourselves.
What do we get at the end?
A report in two parts. Some checks are settled from what your endpoint returned — each with the behaviour expected, the behaviour observed, and whether they matched. The rest list exactly what we sent and ask you to confirm from your own records what your system did with it, because that is not visible from outside. How the seven split depends on what you give us at intake: tell us nothing beyond a URL and a secret and one is settled with six asked; add the request timeout your endpoint enforces and it is two settled, five asked; add the optional staging endpoint as well and all seven are settled with nothing to answer. Answer whatever questions remain and the report is complete, and can be handed to a partner or auditor as evidence.
How much does it cost?
A one-time fee for the audit, priced per engagement rather than published, because scope varies with how many endpoints are involved and what each one handles. After you've shipped fixes, re-runs are available on an optional monthly retainer — most people take the audit first and decide later. Get in touch and you'll have a price back quickly; it's a short conversation, not a sales process.
Get in touch
Tell me what your receiver does and how many endpoints are involved. I'll reply with scope and a price.