Outbound webhooks: sign, retry, dead-letter, replay

live.webhooks.outbound(['demos:outbound:orders'], ...) POSTs a signed body to a sink endpoint on every publish - no +server.js on the sending side, no client code. Place an order and watch the receipt arrive with its verified HMAC signature and idempotency-key; place a failing order and watch the retries exhaust into the cluster-shared dead-letter queue, then replay it.

Ordering as Crispy Turnip (8a9ef018)

Place an order

Both buttons just ctx.publish a placed event - the webhook declaration does the rest. A failing order asks the sink to answer 500, so the delivery retries (300 / 600 / 1200ms, jittered) and then dead-letters.

Sink receipts (0)

No deliveries yet. Place an order.

Newest first, polled every 3s while visible. The sink is a plain HTTP route with no live ctx - it verifies the signature, logs the receipt to Redis, and answers; honest polling instead of a pretend push. Retried deliveries repeat the same idempotency key - that repetition is the at-least-once contract made visible.

Dead-letter queue (0)

Empty. Place a failing order to fill it.

Replay re-fires the ORIGINAL payload through the complete delivery path (SSRF gate re-applied, signature and idempotency key recomputed) - that is the point. So replaying a fail order fails again and returns here, exactly like a receiver that is still down; in a real incident you fix the endpoint, then replay.

Server: orderEvents = live.webhooks.outbound(['demos:outbound:orders'], { url, secret, urlMode: 'off', validateUrl, retry, timeoutMs, idempotencyKey }). The sink is same-host loopback - exactly what the default SSRF guard blocks - so the config uses the documented self-target recipe: urlMode: 'off' relaxes the range check (scheme gate and DNS pinning stay on) and validateUrl narrows delivery back down to exactly /api/demos/webhook-sink on every hop. See outbound-webhooks.js.

The body is signed with HMAC-SHA256 (x-webhook-signature: sha256=<hex>, verified timing-safe by the sink, rotation-ready via comma-separated entries). Delivery is at-least-once with a stable idempotency-key; the retry budget, endpoint breaker, and dead-letter store are Redis-backed and fleet-shared via configureWebhooks, and configureCron({ leader }) gates firing to one replica. The DLQ counts also appear on /demos/ops and behind the admin plane at GET /__realtime/dlq.