How It Works

Webhooks to Private Networks
Without Opening Firewall Ports

Choose your delivery mode based on your network setup. Your services always connect outbound.

Security

Security boundaries (by hop)

The primary data-plane path zen-ingester ↔ zen-egress is protected with mTLS, SPIFFE/SPIRE workload identity, and HMAC and is non-negotiable. Other hops use the controls in the table below.

Boundary Protection
Webhook source → Ingester HTTPS + provider HMAC/signature verification where supported/configured.
Ingester ↔ Egress mTLS + SPIFFE/SPIRE + HMAC on the data-plane delivery path — mandatory, non-negotiable.
Agent / Lock / SaaS mTLS + HMAC per the security matrix.
Egress → customer target Secure-by-default, customer-configurable; target mTLS only when you enable and operate it.
Delivery Modes

Pick Your Path

Zen Mesh supports two delivery modes (webhook dispatch and proxy mode) across three deployment variants. Choose the one that matches your infrastructure.

Direct Public Target

Your target is publicly reachable. No egress needed.

Stripe → zen-ingester → Your Target
  • Free public endpoint
  • Simplest setup
  • Lowest latency
  • No agent required
Setup

Egress Direct

Your egress has a public IP. Ingester ↔ egress uses mandatory mTLS/SPIFFE/HMAC on the data-plane path.

Stripe → zen-ingester → zen-egress → Your Service
  • Free public endpoint
  • Direct delivery
  • Good for DMZ
  • Direct mTLS
Setup

Egress Relay

Your egress behind firewall. No inbound connections needed.

Stripe → zen-ingester → firewall → zen-egress ↔ Your Service
  • Free public endpoint
  • No firewall config
  • Works behind NAT
  • No VPN needed
Setup

Direct Public Target

When your target is publicly reachable from the internet. Replaces Svix, Hook0, and old-generation webhook relays.

1

Create Endpoint

Contact us at zen@zen-mesh.io to start and create a new webhook endpoint. Copy your endpoint URL.

Your endpoint:

https://ingest.zen-mesh.io/your-tenant/stripe
2

Configure Provider

Update your webhook provider (Stripe, GitHub, etc.) to send events to your Zen Mesh endpoint.

3

Start Receiving

Webhooks flow directly from zen-ingester to your public target. Done.

Stripe → zen-ingester → Your Public Target

Egress (Direct or Relay)

When you need to deliver to your private infrastructure. Install zen-agent and adapters in your cluster.

1

Install zen-agent

Get an enrollment bundle from the dashboard and install zen-agent in your cluster:

helm install zen-agent oci://charts.zen-mesh.io/zen-agent \\
  --create-namespace \\
  --set enrollmentBundle="$(cat bundle.yaml)"
2

Install Adapters

Deploy zen-egress (delivery) in your cluster via Helm or the dashboard. zen-ingester runs in the Zen Mesh data plane and is managed for you.

3

Configure Provider

Point your webhook provider to your Zen Mesh endpoint.

4

Start Receiving

zen-egress maintains an outbound tunnel to zen-ingester. No firewall ports needed. NAT is not a problem.

Stripe → zen-ingester → zen-egress ↔ Your Service
Architecture

Four-Plane Architecture

Zen Mesh separates concerns into four distinct planes. The control plane is never in the runtime event path.

1. Control Plane (SaaS)

Coordination, enrollment, policy, and identity. Never in the runtime event path.

  • zen-front — Web UI
  • zen-bff — Backend for frontend
  • zen-back — API server
  • Database — Tenants, clusters, policies

2. Data Plane

Public webhook intake and routing. Runs in the Zen Mesh SaaS.

  • zen-ingester — Event intake and provider verification

3. Edge Plane

Customer-boundary delivery. Deployed in your infrastructure.

  • zen-egress — Delivery to customer endpoints

4. Identity Plane

Cross-cutting identity and access control.

  • zen-lock — Encrypted secret custody and distribution
  • SPIFFE/SPIRE — Workload identity for mTLS
  • zen-agent — Substrate registration and enrollment

Key principle: External traffic never traverses the control plane. The SaaS provides coordination; data and edge planes handle all runtime delivery.

Integrations

Built-In Provider Template Packs

Starting with Stripe, GitHub, Shopify, Twilio, and custom signed webhooks. Pre-configured packages provide structured defaults for endpoint setup, provider verification, and event classification.

Stripe

  • Signature verification
  • Event deduplication
  • Pass-through delivery
  • Correlation ID tracking

GitHub

  • HMAC verification
  • Event filtering
  • Webhook secrets
  • Multi-event support

More Coming Soon

Slack, Linear, Intercom, and more.

Reliability

Webhook Delivery Reliability

Operational controls for reliable event delivery — from recovery workflows to duplicate handling.

Dead Letter Queue

Failed delivery attempts are preserved for inspection and recovery with configurable retention and retry policies.

Replay

Replay events from dead-letter queues or delivery history for recovery, testing, and reprocessing workflows.

Deduplication

Identify and handle duplicate webhook events with configurable dedup key and time-window matching.

Idempotency

Idempotency controls help consumers safely process retries with at-least-once delivery semantics.

Fan-Out

Deliver webhook events to multiple targets from a single source with per-target policies.

Filtering

Route or suppress events according to configured conditions for targeted delivery.

Security

Webhook Security Controls

Security controls for webhook delivery — from source verification to cryptographic identity establishment.

IP Allowlisting

Restrict accepted delivery sources with identity-based deny-by-default enforcement.

Header Validation

Verify webhook event source authenticity through configurable header validation and signature verification.

Cryptographic Enrollment

Establish trust between components using HMAC-based enrollment with X.509 SVID and enrollment bundles.

Ready to try it?

Get started with the Free tier. Reach out for fit evaluation and onboarding.

Contact us Email us