← All posts

Outbound-Only Webhook Delivery: How to Reach Private Services Without Inbound Firewall Holes

Webhooks push to public endpoints, but your services are private. Here is how outbound-only delivery works and what it means for security, reliability, and evidence.

Every webhook you have ever integrated follows the same model: the provider sends an HTTP POST to your public endpoint. Stripe, GitHub, Twilio, Shopify — all of them push to a URL they can reach over the public internet.

This model breaks the moment your service lives on a private network.

There is no way for a webhook provider to push data to a machine that has no public address. The usual fixes — opening firewall ports, running a DMZ reverse proxy, layering a VPN or mesh network — all introduce their own trade-offs. This article explains the outbound-only delivery model, how it solves the fundamental addressing problem, and what you still need to verify before trusting it for critical workloads.

The Problem: Webhooks Are a Push Protocol

The core assumption of every webhook provider is that the receiver has a reachable HTTP endpoint. That assumption is so deeply embedded that most webhook tooling — delivery infrastructure, SDKs, monitoring — treats public reachability as given.

When your service runs inside a private network — behind NAT, a corporate firewall, or inside a VPC without a public load balancer — it does not have a reachable endpoint. The provider’s push mechanism has nowhere to go.

Every workaround tries to bridge this gap. Port forwarding creates a permanent inbound rule. A reverse proxy in a DMZ creates another service to maintain. A mesh network like Tailscale requires every node to join the tailnet and accept UDP. None of these fix the deeper architectural mismatch: they all still expect something inbound to reach the private service.

How Outbound-Only Delivery Works

Outbound-only delivery inverts the connection model. Instead of the provider pushing through to your network, a lightweight agent inside your network establishes a persistent outbound connection to the delivery infrastructure.

The flow looks like this:

Provider (Stripe, GitHub, etc.)
    → Public webhook endpoint (zen-ingester)
    → mTLS-protected data-plane path (ingester ↔ egress)
    → Outbound tunnel to your network (zen-agent)
    → Your private service

Every hop after the public endpoint uses connections initiated from inside your network. No inbound firewall rules are required. No VPN tunnel needs to be maintained. The agent dials out — and stays connected — so the delivery infrastructure can forward events through that pre-established path.

This is the model documented in the architecture overview: a three-plane separation where the data plane (the infrastructure that moves payloads) is isolated from the control plane (the SaaS that manages configuration). The agent inside your network never accepts an inbound connection; it only dials out on a dedicated, authenticated path.

Why Inbound Firewall Holes Are Risky

A firewall rule that allows inbound traffic from a webhook provider is a standing permission for an external system to reach an internal service. Even with IP allowlisting, the risk surface includes:

  • Provider IP ranges are broad and shared. Stripe and GitHub use wide CIDR ranges shared across all customers. Whitelisting them means allowing traffic from any Stripe or GitHub customer — not just your account — to attempt connections to your internal service.
  • Provider IP ranges change. Maintaining an accurate allowlist requires tracking provider IP announcements and updating firewall rules when they change. Miss an update and delivery breaks; keep stale rules and you leave openings.
  • Every new integration repeats the conversation. Each webhook source needs its own security review, its own rule, its own audit trail. For organizations with many integrations, this does not scale.

The outbound-only model eliminates this class of risk entirely. No inbound rule, no exposure. The private service never needs to be reachable from the internet.

What the Control Plane Should and Should Not See

One of the less obvious design questions in outbound-only delivery is what the SaaS control plane observes. In many webhook delivery services, the control plane — the dashboard, the API, the configuration layer — is in the same trust domain as the payload path. This means routing decisions, retry state, and in some cases payload metadata all travel through the same infrastructure as the configuration interface.

A separated architecture draws a boundary: the control plane manages configuration, credentials, and monitoring, but it is never in the data path. Delivery payloads move through a dedicated data plane that does not share infrastructure with the SaaS dashboard or API. Events are routed through the data plane directly to the edge agent tunnel. The control plane sees configuration state, not payload content.

For teams evaluating outbound-only delivery, this distinction matters. It determines what data the SaaS operator has access to and what attack surface exists if the control plane is compromised. The security docs document which hops have which protections and where the boundaries are.

Control-plane isolation is designed into the architecture — the data-plane path from ingester to egress does not depend on the SaaS. A SaaS outage does not interrupt in-flight delivery configuration that has already been applied at the edge, because the edge plane caches its configuration locally.

Delivery Reliability: Retries, Replay, DLQ, and Idempotency

Outbound-only delivery adds an intermediary hop between the provider and your service. This intermediary introduces its own failure modes — connection loss, edge-plane health, certificate rotation — and must maintain delivery state across network boundaries.

The building blocks of reliable delivery apply here as they do for direct delivery:

Retry policy. Transient failures — a temporarily unreachable target, a network blip on the outbound path — should retry with backoff. Permanent failures should not. The intermediary must classify failures correctly and respect the target’s recovery window. Retries are bounded; infinite retries turn a transient blip into an operational incident.

Dead-letter queue. Events that exhaust their retry budget should go to a holding area with diagnostic metadata: what failed and why, how many attempts were made, what the last error was. Operators inspect, replay, or discard. Without a DLQ, failed events are silently dropped. The DLQ design documents one approach.

Replay. Re-delivery of previously received events is distinct from retry. Retry is automatic within the delivery window; replay is on-demand after the event has settled. Every replay attempt should carry its own evidence trail so operators can distinguish first-attempt delivery from re-delivery after investigation. See the replay documentation for operational patterns.

Idempotency. Webhook providers deliver at least once. The intermediary must provide a stable, unique event ID for every delivery attempt, and consumers must use that ID as an idempotency key. No infrastructure tool can make a non-idempotent consumer safe from duplicates, but the delivery system can preserve the record of which events were accepted, rejected, or re-delivered. The idempotency design details the approach.

For private delivery, these guarantees must span the full path — not just the provider-to-intermediary segment, but the intermediary-to-target segment as well. Evidence must cover both. Production-live validation of these properties across the full chain is tracked separately in the evidence system.

Delivery reliability for private networks is covered in more detail in Webhook Delivery Reliability, including a practical checklist for evaluating any delivery system.

Evidence and Non-Claims: What Is Actually Proven

A delivery log can answer “we tried.” It cannot answer whether the payload was intact, whether the target actually processed it, whether a duplicate was silently accepted, or what infrastructure touched the payload in transit. These questions matter for compliance audits, incident response, and AI-triggered workflows.

Evidence in delivery infrastructure means structured, verifiable artifacts — not log entries. The AI overview explains how proof status is organized, and the verification guide walks through validating an artifact end-to-end.

Transparency about what is not claimed is as important as what is claimed. The non-claims registry documents capabilities that are explicitly out of scope or not yet validated. The claim maturity manifest shows which claims are fully proven, partially proven, or planned. Current evidence is local/sandbox validation unless an artifact explicitly states otherwise.

For a deeper discussion of how delivery logs differ from verifiable proof, see Your Webhook Tool Can’t Tell You What Actually Happened. The rationale for publishing non-claims alongside claims is explained in Why We Publish What Our Product Doesn’t Do.

When to Use the Outbound-Only Pattern

Outbound-only delivery is the right choice when:

  • Your service runs behind a NAT or firewall and cannot accept inbound connections.
  • Your security team will not open inbound ports for webhook providers — a position that is increasingly common and well-justified.
  • You operate in a regulated environment where every inbound rule requires documentation and audit.
  • You want to avoid VPN or mesh network dependencies for webhook traffic — outbound-only eliminates the need for every node to join a tailnet or accept UDP hole-punching.
  • You want control-plane isolation — the SaaS that manages configuration should not be in the path of live payloads.

Outbound-only delivery is not a replacement for every connectivity pattern. It is designed for the specific case where an external HTTP sender needs to reach a private HTTP receiver. For real-time streaming, bidirectional gRPC, or large-volume data transfer, other patterns may be more appropriate.

The private webhook delivery use case walks through the runtime path step by step — registry, template, blueprint, endpoint, flow, target, and evidence — for a concrete view of how the outbound-only model operates in practice.