What this prompt does
This prompt turns the AI into a senior backend engineer that designs a complete outbound webhook system and returns working code rather than pseudocode. You feed it your [stack], your [volume], and your [consumers], and it produces six concrete deliverables: versioned event payload schemas, an HMAC signature header with timestamp and replay protection, an exponential-backoff retry policy with a max-attempts cap, a dead-letter queue with alerting, a customer-facing delivery dashboard, and local signature-verification tooling for consumers.
The structure works because it forces the model to address the failure path, not just the happy path. By naming [consumers] as external endpoints with variable uptime, you push the AI toward the parts that actually break in production - a consumer that was down for ten minutes and silently missed events. [volume] shapes the retry and queue design (bursty traffic needs different backpressure than steady traffic), and [stack] decides which signing and queue libraries appear in the reference implementation.
When to use it
- You are building outbound webhooks for a SaaS platform and need delivery guarantees, not fire-and-forget HTTP calls.
- You need HMAC signatures with replay protection so consumers can trust that events came from you.
- Your consumers have unreliable uptime and you must not lose events when they are briefly down.
- You want a dead-letter queue and alerting before failures turn into silent data loss.
- You need to give external integrators a self-serve dashboard and local verification tooling to cut support tickets.
Example output
You get a reference implementation in your chosen stack: a versioned payload schema, the complete signing code (HMAC header plus timestamp and a replay-protection window), retry middleware with exponential backoff and a max-attempts cap, a dead-letter queue with the alert that fires when it fills, a delivery-dashboard sketch showing attempts and status per event, and a copy-ready signature-verification snippet consumers can run locally.
Pro tips
- Set
[consumers]honestly - if your endpoints have variable uptime, say so, because that is what justifies the dead-letter queue and replay window. - Tune
[volume]to your real burst pattern; "~50k events/day, bursty" produces different backpressure handling than a steady stream. - Match
[stack]to what you actually deploy so the signing and queue code uses libraries you already run. - Ask for the consumer-facing verification snippet first and ship it on day one; it removes most integration support tickets.
- If the first pass skips the replay-protection window, push back explicitly - the timestamp plus window is what stops replayed events.
- Iterate on the retry cap separately; too many attempts can hammer a recovering consumer, too few drops events that would have succeeded.
- Version the payload schema from the very first event type, because adding a version field after consumers depend on the old shape is far harder than starting with one.
- Wire the dead-letter-queue alert to a channel a human actually watches; a queue that fills silently is no better than dropping the events outright.
