Your build starts here
Replace bracketed details with your own goal, context, and checks. Keep the first build small enough to inspect.
Design a webhook inbox for [provider and harmless development event]. Inspect the provider's current official signature and delivery contract and use its maintained verification library. Verify signatures against the required original request bytes before trusting parsed fields. Store a stable event identifier with a uniqueness constraint and distinguish received, pending, completed, and failed work. Define when an acknowledgement is safe and how pending work resumes after a crash. Use signed test fixtures for normal delivery, duplicate delivery, invalid signature, malformed payload, delayed delivery, and events received out of order. Interrupt processing after durable receipt and before completion, then confirm the pending operation still runs under the intended idempotency policy. Do not treat arrival order or a coarse timestamp as a unique event identity. Report the state transitions and limits of any cross-service exactly-once claim.Make this prompt yours
Use for provider webhooks in an authorized test environment. Delivery deduplication and idempotent business effects require distinct contracts.
You might also hear
- webhook inbox
- duplicate event
- signature raw body
- event ordering
- idempotent consumer
The docs behind it
These references explain the underlying concepts and APIs. The prompt templates and project plans are original examples to adapt to your own setup.
Research sources reviewed .
Editorial review · October 28, 2026
Limited: Original instructional template; not executed. Stripe confirms raw-body signature verification, possible duplicate/out-of-order delivery, and event-ID tracking; inbox completion and idempotent effects remain original application design requirements.