What this prompt does
This prompt makes the AI a backend systems engineer building a webhook delivery system for a [platform_type] platform delivering [events_per_day] events daily to [subscriber_count] subscribers. It covers the registration API, the dispatch pipeline, the delivery worker, the retry strategy, a subscriber dashboard, and health monitoring. Events are signed with an HMAC-[hash_algorithm] signature and enqueued in [queue_system], and the worker treats 2xx as success, 410 as permanent failure, and everything else as retryable.
The structure works because reliable webhook delivery is mostly about handling failure well. The [retry_strategy] backoff schedules [max_retries] attempts over 24 hours at widening intervals, after which events move to a dead letter queue for inspection rather than being silently lost. Signature verification lets subscribers trust the payload came from you and wasn't tampered with, and URL validation that rejects private IP ranges and non-HTTPS targets blocks a common SSRF vector at registration time. The status-based handling treats 410 as a permanent failure that auto-disables the subscription, while the health-monitoring step auto-pauses any subscriber whose success rate over [health_window] falls below [disable_threshold], which keeps failing endpoints from clogging the queue for everyone else.
When to use it
- You're building outbound webhooks for a platform and want a proven blueprint
- You need signed payloads subscribers can verify
- You want retries with backoff and a dead letter queue for exhausted events
- You need to auto-pause endpoints that keep failing
- You want a subscriber dashboard showing delivery history and a replay feature
- You need URL validation that blocks private IPs and requires HTTPS
- You're fanning out
[events_per_day]events to many subscribers and need it to stay reliable
Example output
Expect an implementation walkthrough: a registration API storing subscriptions in [database] with URL validation and a status field, a dispatch pipeline that signs payloads with HMAC-[hash_algorithm] and enqueues to [queue_system], a delivery worker sending POSTs with signature headers, [connect_timeout]/[read_timeout] limits, and status-based handling, a [retry_strategy] schedule of [max_retries] attempts feeding a dead letter queue with per-attempt logging, a subscriber dashboard with delivery history, a test endpoint, and event replay, and health monitoring that auto-pauses below [disable_threshold] and notifies via [notification_method]. It's structured as labeled steps.
Pro tips
- Validate registered URLs hard — reject private IP ranges and require HTTPS, or your webhook sender becomes an SSRF tool
- Sign every payload with HMAC-
[hash_algorithm]so subscribers can verify authenticity; document the signing string exactly - Treat 410 as permanent and auto-disable; retrying a gone endpoint just wastes queue capacity
- Tune the
[retry_strategy]so[max_retries]spans enough time for a subscriber to recover from a real outage - Auto-pause below
[disable_threshold]and notify the subscriber; a dead endpoint shouldn't drag down delivery for everyone - Keep a replay feature — subscribers will eventually need to re-deliver events from a window they missed
