Webhook reliability is a tax on every integration

If you process payments — crypto or otherwise — your most-stressed code path is “notify the customer that something happened.” Webhooks are how you do that, and most webhooks are subtly broken. Three patterns we see often:

1. Best-effort delivery

The platform sends the webhook once. If your endpoint is down, you don't get it. Your reconciliation cron the next morning catches it, but for the duration of the gap your customer's state is stale. SwyDex retries with exponential backoff (1m, 5m, 15m, 1h, 6h, 24h) and stops only after we've tried for ~30h.

2. Signing without raw-body verification

Some platforms HMAC-sign the parsed JSON. The receiver re-stringifies and gets a different signature. SwyDex signs the exact bytes we send and recommends our customers verify against the raw body. Express middleware reorder is a common foot-gun here.

3. No idempotency

Retries happen. If your webhook side-effect creates a database row each time, you'll have duplicates. We send a stable event_id on every payload; we recommend customers store the most-recent set and skip duplicates server-side.

None of this is novel. We just bake it in by default so you don't have to debug it.