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
Back to feedPost
Here's a duplicate-record bug that arrives without an error and is nearly impossible to reproduce on demand.
You build a webhook handler that creates a deal in your CRM when a payment event fires. Testing is clean. In production, occasionally the same payment creates two records — same customer, same amount, a few minutes apart.
The cause: your payment processor retries on network timeout. If your handler takes a few seconds to respond (say it's chaining three downstream API calls), the processor assumes something went wrong and fires the same event again. Both runs succeed. Nothing in your logs looks wrong because nothing did go wrong — the handler worked exactly as written, twice.
The fix is two parts. Every incoming webhook event has an ID. Before writing anything, check whether you've already processed that ID — a key in your database or cache is enough. If it exists, return 200 and stop. If it doesn't, write it first, then proceed. That way a retry on the same event hits the check and exits cleanly.
The rule underneath it: a 200 acknowledges receipt, not uniqueness. Any webhook handler that creates or modifies state needs to treat duplicates as a given. The event ID is how you enforce idempotency.
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
Related posts
Automated Review Requests for Local Service Businesses
The Problem
Google reviews help local businesses get found, and every HVAC company, salon, cleaner and contractor knows it. Most of them ask for reviews inconsistently. The reason isn’t that they don’t care. Asking every customer, right after every job, depends on someone remembering at the exact moment the business is busiest. Happy customers never get asked, and the review count grows slower than it should.
The Solution
I built an n8n system that sends the review request automatically, once, at the right time, and tracks what happens next. Nobody gets asked twice and nobody gets forgotten.
How the System Works
1. Checks every 15 minutes. The workflow reads a Google Sheet that lists each job and what has already been sent. The sheet is the system’s memory, so nothing depends on timers that can fire twice.
2. Sends the request. Two hours after a job is marked complete, the customer gets an email with a review link.
3. Tracks the click. The link goes through a tracking step that records “clicked” in the sheet, then sends the customer to Google.
4. Sends one follow-up. If there’s no click after three days, one reminder goes out. Customers who clicked or opted out are skipped.
5. Alerts me on errors. A separate error workflow emails me if any step fails.
Why this design: every step re-checks the sheet before sending, so the system can’t double-send and a customer who already responded is never contacted again.
Tools: n8n, Gmail, Google Sheets
I'd test the tracking link with email security scanners before using clicks to suppress reminders. How do you distinguish an automated link check from a customer opening the review page?
Shopify Product Page Fix & Recharge Integration for Parrox
On Parrox, the product page experience had started breaking at a point where it mattered most, checkout intent. Users could select quantities, but pricing did not respond correctly, and variant mapping failed during interaction. That disconnect created hesitation right before purchase. On top of that, subscription orders powered through Recharge were not processing smoothly, which directly impacted recurring revenue. The work focused on rebuilding Shopify product page logic and restoring subscription stability across the storefront.
I’m building Paddy, a platform for finding verified rental homes in Ghana.
Every listing is reviewed before it goes live. The problem: a rejected landlord had no idea what went wrong, so they’d either give up or resubmit the same thing.
So now, before a reviewer can reject a listing, a dialog asks them for the reason. The landlord sees it on their dashboard and knows exactly what to fix.
Built with Next.js on a Django REST API. Code in the comments.