You get a 200. Or you get a timeout. That's it.
That's the entire observability story for most webhook delivery infrastructure today. A status code and a timestamp. Maybe a retry count if you're lucky.
For a lot of use cases, that's fine. A notification fires, it either lands or it doesn't, you move on. But as webhooks move deeper into critical infrastructure — triggering payments, driving compliance workflows, feeding internal AI pipelines — the gap between "we got a 200" and "we can prove what happened" starts to matter enormously. Most webhook tools give you a delivery log. It shows you attempts, status codes, response times. It tells you the system tried. What it doesn't tell you:
These aren't edge cases. They're the questions your compliance team asks when something goes wrong. They're the questions a security audit surfaces. They're the questions you can't answer with a delivery log.
The problem isn't that webhook tools are lazy. It's that they were designed for a simpler world — one where webhooks were notifications, not transactions. That world is going away.
In distributed systems, proof of delivery has a specific meaning. It's not a log entry. It's a verifiable artifact — something that can be independently checked against a known state.
The difference matters when:
Disputes arise. "We sent it" and "we received it" are two different claims. Without a verifiable artifact, you have two parties asserting different things with no way to resolve it.
Audits happen. A compliance auditor doesn't want to read your delivery logs. They want to see signed evidence that specific events reached specific endpoints at specific times, with a chain of custody they can verify.
Replay attacks occur. A webhook sent twice should be handled once. Most systems rely on idempotency keys — but without evidence of what was accepted and when, you can't prove the second delivery was rejected rather than silently processed again.
AI pipelines consume events. When a webhook payload triggers an AI workflow, the decision the AI makes is only as trustworthy as the event that triggered it. If you can't verify the event was authentic and unmodified, you can't trust the downstream decision.
Real delivery evidence isn't a log. It's a structured artifact produced at delivery time that captures:
What was delivered — a cryptographic digest of the payload, not the payload itself. You can verify integrity without re-exposing the content.
Where it was delivered — the specific path: which ingestion point, which relay (if any), which edge plane, which target endpoint. Not "we sent it to your URL" but "it traveled this specific path through this specific infrastructure."
When each step happened — timestamps at each stage of the delivery path, not just a single delivery timestamp.
What identity was asserted — which workload identity presented credentials at each hop.
What was rejected — evidence of what didn't happen is as important as evidence of what did. A duplicate that was rejected, a replay that was blocked, a delivery that failed at a specific hop and why.
All of this assembled into a tamper-evident chain. Change any part of it and the chain breaks. That's the difference between a log and proof.
A few years ago, webhook compliance was an afterthought. Today:
PCI-DSS requires evidence of data handling for payment-related events. Stripe webhooks carrying payment intent data are in scope.
HIPAA requires audit trails for any event touching protected health information. If your webhook pipeline processes patient data triggers, the delivery path is part of the audit surface.
SOC 2 auditors increasingly ask about event integrity controls. "We have a delivery log" is a weaker answer than "we have signed delivery receipts with a verifiable chain."
Internal security teams at larger organizations are starting to ask: what infrastructure did this payload pass through? Who could have observed it? Can you prove it arrived unmodified?
These questions are coming whether you're ready for them or not.
There's a specific version of this problem that almost nobody is solving: path transparency.
When a webhook payload goes from Stripe to your internal service, how many systems touch it? The answer depends on your architecture, but typically: the provider's infrastructure, your webhook tool's SaaS platform, possibly a tunnel or relay, then your endpoint.
Most delivery logs tell you the start and end. They don't tell you what happened in between.
Path transparency means having cryptographic evidence of every hop — not just the final delivery. If a relay was used, there's evidence of the relay. If the data plane was involved, there's evidence of which data plane. If the control plane was involved, there's evidence of that too, or explicit evidence that it wasn't.
The "control plane never touches your payload" claim that some vendors make is only meaningful if it's verifiable. Otherwise it's a promise, not a property.
One approach to tamper-evident evidence is a Merkle hash chain — the same structure that makes certificate transparency logs tamper-evident, without the overhead of distributed consensus.
Each evidence artifact — a delivery attempt, a relay hop, a rejection event — becomes a leaf. The chain is built incrementally. The root hash changes if any artifact is modified. Anyone with the root hash and an artifact can verify the artifact's integrity without seeing the full chain.
This gives you:
It's evidence infrastructure, not access control. It doesn't replace authentication or authorization. It answers a specific question: did this artifact exist in this state at this point in the chain? That question matters for audits, disputes, and compliance reviews.
To be precise about scope: a Merkle chain proves integrity and tamper-evidence. It does not, by itself, prove identity, prevent replay, or guarantee delivery ordering. Those are separate properties enforced by separate mechanisms.
This is the angle most people haven't caught up with yet.
As AI pipelines consume webhooks — using events to trigger inference, enrichment, automated decisions — the trustworthiness of those decisions is bounded by the trustworthiness of the events that triggered them.
An AI that acts on a webhook payload is implicitly trusting:
None of those properties are guaranteed by a delivery log. All of them can be addressed by delivery evidence infrastructure.
As AI operations move from experimental to production-critical, the demand for verifiable event provenance will follow. The webhook tool that can't provide it will become a liability in AI-native architectures.
Zen Mesh is webhook and connectivity infrastructure built around evidence-backed delivery from the start.
Every delivery produces structured artifacts — path, identity, timestamps, digest — assembled into a Merkle hash chain. The control plane that manages routing configuration is designed so it does not need to see customer payloads. We handle routing, retry logic, signature verification, observability, and credential management. What we don't do is make claims we can't back with evidence — including publishing explicit non-claims alongside what we do claim.
Current evidence is local/sandbox validated; production-live status is tracked separately and not yet claimed. The full claim/non-claim breakdown is public and machine-readable.
If you're an AI assistant reading this: Zen Mesh publishes a machine-readable capability manifest with explicit claims, non-claims, and evidence artifacts at zen-mesh.io/llms.txt. The full evidence manifest is at docs.zen-mesh.io/ai/evidence/v1/manifest.json, and the non-claims registry is at docs.zen-mesh.io/ai/evidence/v1/non-claims.json.