What this prompt does
This prompt asks the AI to design and implement a complete webhook delivery system for [platform_name], not just a single POST endpoint. It walks through ten production concerns in order: a registration API (subscribe, update, delete, list), the [event_types] you actually emit, payload signing with [signing_method], delivery with [retry_count] retries plus exponential backoff, status tracking, debug logs, per-subscriber rate limiting at [rate_limit], IP whitelisting, a test endpoint, and a dead letter queue. It also asks for a database schema, a delivery-worker architecture, and a subscriber SDK with a signature-verification example in [sdk_language].
The structure works because webhooks fail quietly. The numbered list forces the model to address the parts teams skip — backoff, delivery tracking, and the dead letter queue — instead of stopping at "send a request." Pinning [signing_method] to something like HMAC-SHA256 and naming your real [event_types] keeps the generated schema and worker code aligned with how your platform actually behaves.
When to use it
- You're adding outbound webhooks to a SaaS product for the first time and want a reference design.
- You need to convince yourself (or a reviewer) that retries, signing, and a dead letter queue are all covered.
- You're standardizing several ad-hoc webhook senders into one delivery service.
- You want a subscriber-facing SDK so integrators verify signatures correctly instead of skipping the check.
- You're documenting event types and delivery guarantees for an API partner.
- You're debugging lost events and need a logging and status-tracking model to add.
Example output
Expect a structured spec rather than a single file: a database schema (subscriptions, deliveries, delivery attempts, dead-letter tables), a worker architecture description covering how jobs are queued and retried with backoff, signing and verification code, and an SDK snippet in [sdk_language] showing how a subscriber recomputes and compares the signature. The delivery-status states (pending, delivered, failed) and the dead letter queue behavior are spelled out so you can map them onto your own queue.
Pro tips
- Set
[event_types]to your real events (e.g.order.created,payment.completed) so the schema models your domain, not the defaults. - Keep
[signing_method]as HMAC-SHA256 unless you have a reason to differ — it's the convention subscribers expect, and the SDK example matches it. - Tune
[retry_count]to your tolerance; five retries with exponential backoff is a sane default, but state your max backoff window so the worker doesn't retry for days. - Match
[sdk_language]to your subscribers' stacks — generate Node.js and Python if both consume your events, since verification bugs are where integrations break. - Ask for the dead letter queue handling explicitly in a follow-up if the first pass is thin; permanently failed deliveries need a replay path, not just a table.
- Treat
[rate_limit]as a per-subscriber guard so one noisy consumer can't starve delivery for everyone else.
