All packsWebhook Durability & ReplaySolve
webhook idempotency two different dedupe keys delivery vs effect
One idempotency key isn't enough. It's two, and they fail in opposite directions.
A delivery key answers 'have I seen this HTTP request'; an effect key answers 'has this business fact already changed my data' -- collapsing them into one breaks in opposite directions (D1-D2).
This is one of the things Webhook Durability & Replay already handles. Receive webhooks without losing, duplicating or misordering them when the sender retries.
Is this you?
Using a resource id as the delivery key silently collapses distinct events into one -- Resend's data.email_id is shared across a message's delivered, bounced, and complained events, so deduping on it drops real signal. Using the delivery key as the effect key breaks the other way: a Shopify order recovered by reconciliation has no X-Shopify-Webhook-Id at all, so a delivery-keyed effect check can't stop that second path from double-applying the payment.
Why this one is easy to get wrong
"Make this idempotent" reads like one problem with one key, and Resend's and Shopify's payloads both name a field that invites exactly the wrong choice -- data.email_id sounds like an identifier, and X-Shopify-Event-Id has the word "event" right in it, while the actually-correct per-delivery key (svix-id, X-Shopify-Webhook-Id) sits in a header most handlers never inspect that closely.
What you get instead
The delivery key is checked at ingest, before any work, and must be the provider's own per-delivery identity; the effect key is checked inside the transaction that performs the change, and must be derivable from fields every ingestion path -- webhook push, API backfill, dead-letter replay -- can compute identically. resend:{email_id}:{type} is the same field that's wrong as a delivery key and right as an effect key component -- one field, correct in one slot, a bug in the other.
Source: ARCHITECTURE.md D1-D2 — checkable in the pack you receive
How you actually use this
You don’t install a library or wire up an SDK. Your own coding agent builds the code in your project, and you keep it — no runtime dependency on us.
Step 1
Download and unzip
You get a folder: the docs that tell an agent what to build, a starting skeleton, and the test suite that decides when it's done.
Step 2
Open it in Claude Code or Cursor
Point your coding agent at the folder. Nothing to install, no account with us, no API key.
Step 3
Paste one prompt
The pack contains the exact prompt. Paste it as your first message and leave it alone — it works through the build itself, choosing a cheaper or stronger model per task.
Step 4
Run ./verify.sh
One command. It prints a pass or fail for every check. Green means the build is done — the same script we ran to produce the receipt on this page.
Typical build: about 40 minutes of your agent working, mostly unattended. Then you integrate the working module into your app the way you would any code you’d written yourself.
Why you can believe this
3 of 3 runs passedWe ran this pack from an empty folder 3 times and published exactly what happened — every check, the model, the token cost, the wall time. Not a testimonial, and not our opinion: the same verify.sh you run yourself. Read the full receipt →