I’m tired of duplicate webhook events causing double processing

That’s a common problem. The usual fix is to make your webhook handler idempotent so duplicate deliveries don’t create duplicate side effects.

Practical approaches:

1. Store processed event IDs

   • Most webhook providers include a unique event ID.
   • Keep a table like processed_webhook_events(event_id, processed_at).
   • Before handling, check if the ID already exists.
   • If yes, return 200 OK and do nothing.

2. Use a unique constraint

   • Put a UNIQUE index on the event ID in your database.
   • Insert first, process only if insert succeeds.
   • This is often safer under concurrency than “check then insert”.

3. Make downstream operations idempotent too

   • If the webhook creates/updates orders, invoices, subscriptions, etc., ensure those writes are also deduped by business key.
   • Example: “create invoice for payment_intent X” should be unique on payment_intent_id.

4. Handle retries safely

   • Webhook providers often retry on timeouts or 5xx responses.
   • Return 2xx only after you’ve safely recorded the event.
   • If processing is slow, consider:
     • quickly acknowledge the webhook
     • enqueue the event
     • process async with dedupe

5. Lock or transaction around the dedupe step

   • If multiple workers may receive the same event, use a transaction or atomic insert to avoid race conditions.

A simple pattern:

• Receive webhook
• Verify signature
• Extract event.id
• INSERT event ID into processed_webhook_events
• If insert conflicts, stop
• Process event
• Mark complete

If you want, I can show you:

• a Node.js / Express
• Python / FastAPI
• Ruby on Rails
• or database schema example for safe webhook deduping.