new sample for webhook delivery resilience

[lovyjain]

This sample provides realistic webhook delivery scenarios that frequently break production integrations. You can use it to validate idempotency handling, event sequencing checks, signature verification, and retry behavior.

[waldekmastykarz]

Thanks for submitting this sample, @lovyjain! The config is well-structured and the scenarios you've picked (duplicates, out-of-order, signature failures, transient errors) are practical and relevant.

One thing I'd suggest revisiting is the framing. Right now the README describes this as testing your webhook receiver, but since Dev Proxy intercepts outgoing requests, what this actually tests is how your sender/delivery code reacts when the receiving endpoint responds with errors like 409, 401, or 503.

For example, the "Typical use case" section says "your payment provider sends webhook events" — which implies you're the receiver. But in this setup, your app is the one calling webhooks.contoso.com, and Dev Proxy stands in for that remote endpoint.

Could you reframe the narrative so it's about testing webhook delivery resilience from the sender's perspective? Something like: "Test how your app handles it when the webhook endpoint you're calling rejects duplicates, returns auth errors, or is temporarily unavailable." The config and mock responses wouldn't need to change — just the README and descriptions.

A couple of smaller things I noticed:

• The for /L %i in (1,1,10) do ... loop in the README is Windows cmd.exe syntax — should be for i in {1..10}; do ... ; done for bash
• Schema version is v2.3.0 but the latest stable is v2.3.4 — worth bumping

Nice work overall — with the reframing this would be a solid addition!

[lovyjain]

Thanks for inputs, i have incorporated those. Makes sense.