← All Use Cases

Regulated Evidence for Webhook Delivery

Tamper-evident delivery receipts with hash-chain integrity — each delivery produces verifiable evidence of when it arrived, what it contained, and whether the payload was intact.

The Problem

In regulated environments, you need to prove that a webhook was delivered — not just that it was sent. Standard webhook infrastructure gives you delivery status callbacks (200 OK, 4xx/5xx) but no tamper-evident proof. If an auditor asks whether a payment webhook reached your billing system intact, or whether a compliance event was delivered without modification, most infrastructure can't provide an answer beyond a log line.

Why This Is Hard

Traditional webhook delivery is fire-and-forget. The sender gets a response code and maybe a retry log. There's no chain of custody — no way to verify that the payload received is the payload that was sent, at the time it was sent, through the path it took. Adding evidence requires infrastructure that signs, chains, and stores delivery receipts in a tamper-evident format — which most webhook platforms don't provide.

How Zen Mesh Helps

Zen Mesh produces a tamper-evident delivery receipt for every webhook delivery. Each receipt includes a hash of the payload, delivery metadata, and a link to the previous receipt — forming a hash chain. The chain provides integrity verification: any modification to past receipts breaks the chain, making tampering detectable.

What Each Receipt Contains

1
Payload Hash

Cryptographic hash of the delivered webhook payload — verifies content integrity.

2
Delivery Metadata

Timestamp, endpoint, target, flow ID, delivery path, HTTP status code.

3
Chain Link

Hash of the previous receipt — creates an auditable sequence of deliveries.

4
Hash-Chain Receipt

The full receipt is itself hashed, linking it into the chain. Tampering with any past receipt breaks continuity.

Runtime Path

Evidence flows through the same delivery chain as every webhook, with an additional evidence layer built in:

1
Registry

Select a provider template — each template defines the evidence schema for validated deliveries.

2
Template

Apply provider defaults including signature verification method for evidence trust chain.

3
Blueprint

Define delivery rules — event routing, retry policy, and evidence retention.

4
Flow

Bind the endpoint, blueprint, and target. Each delivery produces an evidence receipt.

5
Target

Deliver to your private service through the outbound-only Edge Plane.

6
Evidence

Each delivery generates a tamper-evident receipt with payload hash, metadata, and chain link.

Future Capabilities

As the product matures, evidence features will be documented when they are available and validated.

Security & Evidence

Hash-chain receipts provide tamper-evidence — not authentication, identity, encryption, or replay prevention. They work alongside mTLS, SPIFFE/SPIRE, and HMAC on the data plane. See the Security and Evidence pages for scope, maturity, and non-claims.

Current Status

Hash-chain receipts are available as part of the V1 delivery pipeline. Individual capabilities carry per-item status documented in the Current Status page. Additional evidence capabilities will be documented when they are available and validated.

Ready to try verifiable delivery?

Free Forever tier includes evidence receipts. No credit card required.