Public Beta: Direct engineering support available. Join Discord →

Webhook ETL

Webhook ETL is extract-transform-load applied to webhook streams: receive events from any source, transform and validate them against one schema, and deliver to every destination that needs them — with retries, replay, and delivery observability handled once at the gateway instead of per handler.

What Webhook ETL Means

Classic ETL moves records from source systems into a warehouse: extract from N sources, transform into a canonical shape, load into one target. Webhook ETL applies the same three stages to event streams:

  • Extract — receive webhooks from any source: Stripe, Shopify, Square, GitHub, a partner API, an internal service.
  • Transform — reshape and validate the payload against a single canonical schema (a Golden Model). Cast currency safely, flatten envelopes, reject payloads that don't match.
  • Load — deliver to every destination that needs the event: a Postgres consumer, a queue, a data warehouse, a third-party API — each with its own filters, retries, and delivery guarantees.

The output of a webhook ETL pipeline is the same shape on the destination side no matter which vendor sent the event. Downstream code reads one schema.

Why It Beats Point-to-Point Handlers

The default architecture is one handler per source: one endpoint for Stripe, one for Shopify, one for each partner. Each handler owns its own parsing, its own retries, its own dead-letter behavior, its own observability. That's N codebases doing the same six things, drifting out of sync as new sources are added.

Webhook ETL collapses that:

  • One schema, N sources. Every vendor's payload is transformed into the same canonical shape at the gateway. Consumers don't care that Stripe wraps events in data.object.* and Shopify sends 500 flat fields.
  • M destinations, one delivery. Fan-out routes each transformed event to every destination that needs it, without your service acting as the middleman. A downed destination doesn't back-pressure the others.
  • Retries and replay once, not per handler. Backoff, DLQ, and manual replay live in the gateway. Removing them from every handler cuts most of the code you were writing anyway.
  • Delivery observability at the boundary. Every payload, transform result, and delivery attempt is stored where you can see it — not scattered across handler-specific dashboards.

The pattern isn't new; ETL has run this way for decades in the batch world. Applying it to webhooks reflects that events, not files, are how systems now talk to each other.

The Slashbin Pieces