Webhook Delivery System. @webhook-delivery-system

The Webhook Delivery System gives your product a webhook capability that partners can actually depend on. Naive webhook implementations — fire an HTTP POST and hope — lose events the first time a subscriber has an outage. This sprint builds delivery as a proper system: durable queuing, exponential-backoff retries, dead-letter handling, signed payloads, and idempotency keys so redelivery is always safe. The finish state is events flowing to real subscribers with delivery logs that prove what was sent, when, and what happened.

The system lands as part of your platform, in your stack, with an event catalog designed alongside your team — so adding the next event type is configuration plus a payload schema, not a new project.

Event Catalog & Payload Design

A defined catalog of event types with versioned payload schemas and consistent envelope conventions — designed for consumers who will build automation on top of them.

Delivery Engine with Retries

Durable, queue-backed delivery with exponential backoff, per-subscriber ordering where required, dead-letter queues, and manual replay for failed events.

Signing & Idempotency

HMAC-signed payloads with rotatable secrets, timestamp tolerance against replay attacks, and idempotency keys so subscribers can process duplicates safely.

Subscriber Management & Logs

Endpoint registration and verification, per-subscriber event filtering, delivery logs with response codes and latencies, and automatic disabling of chronically failing endpoints.

1. Scope — Define the event catalog, delivery guarantees, and subscriber model; fix the queue infrastructure choice.
2. Build — Build the delivery engine, signing, and subscriber management; verify behavior under subscriber outages and floods.
3. Handover — Production launch with first subscribers live, consumer documentation, and operational runbooks for replay and incidents.

The Webhook Delivery System is a menu item on the Scrums.com delivery catalog, available at every plan tier. Add it to your plan backlog and your delivery team schedules it like any other item — scoped, tracked, and reported through the SEOP. See Delivery Plan Tiers.

What delivery guarantee does the system make?

At-least-once, with signed idempotency keys so consumers can deduplicate. Exactly-once over public HTTP is a myth; the sprint builds the honest version and documents it for subscribers.

What infrastructure does it need?

A durable queue in your existing cloud — SQS, Pub/Sub, RabbitMQ, or a database-backed queue at lower volumes. The scope step picks the lightest option that meets your throughput.

Is this part of a public API offering?

It pairs naturally with one. If you are exposing APIs externally, the Public Developer API Launch item covers the rest of the developer-facing product around these events.