Designing Idempotent Webhook Processing for Conversion TrackingDesigning Idempotent Webhook Processing for Conversion Tracking
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
The Webhook Arrived Twice. The Sale Happened Once.
A conversion notification arrives twice. Should your report show two sales?
Imagine an integration saves the first notification, but its acknowledgement never reaches the sender. The sender retries. Both deliveries describe the same event.
Counting every arrival as a new conversion would inflate the report. In another workflow, the same mistake could create a second task or send the customer another confirmation.
I built duplicate checks into my Internal Campaign Tracker, a private working proof of concept for a business partner. Incoming conversions are matched to the original visit. Outgoing callbacks have a persistent queue, retry history and a way to inspect and replay failed deliveries.
That separates two questions: did the business event happen, and did its notification reach the next system?
Before accepting an integration, agree what identifies a repeat. An email address is usually too broad: the same customer can make two legitimate purchases. The identity needs to match the action you are protecting.
Then test three cases:
• Deliver the same event twice, including two attempts arriving close together. • Retry after a timeout where the receiving system may already have saved the first attempt. • Send a genuinely new event for the same customer and confirm it is still processed.
The expected result should be written down for each case. A repeated notification should not repeat the protected action; a new purchase should not disappear because its customer is already known.
The operator also needs to see what happened: completed, waiting to retry, or needing attention. For outgoing callbacks, retries and manual replay should keep the same event identity, and the receiving system must handle repeat deliveries safely.
Project details and screenshots on NikoCodes: https://nikocodes.com/software/internal-campaign-tracker/
Post image
Milan's avatar
Great breakdown. A pattern that holds up even when two deliveries race each other: save the event ID under a unique constraint in the same transaction as the side effect. Then the database decides which one wins, instead of a check-then-insert in app code.
Niko's avatar
Exactly, for database changes, that closes the race between two deliveries. Outgoing callbacks still need the original event ID preserved across retries and replay, so the receiver can recognize duplicates too.
Back to feed
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started