Webhook Lead Intake & Deduplication with n8n Data Table

Stop duplicate leads at the source—intake once, store uniquely in an n8n Data Table

This n8n workflow receives lead submissions through a webhook, validates and normalizes the incoming data, then saves only unique leads into an n8n Data Table using idempotency keys and payload hashing to prevent duplicates and catch conflicting replays.

What this workflow does

• Receives POST webhook requests containing lead details plus an Idempotency-Key header (or X-Idempotency-Key).
• Validates required fields, including checking email format and ensuring an idempotency key is present. Invalid requests are rejected with a 400 response.
• Normalizes the lead payload and generates a payload fingerprint (hash) for replay detection.
• Creates or reuses an n8n Data Table named lead_intake_template and looks up existing rows by the idempotency key.
• Handles duplicates and conflicts:
  • If the idempotency key exists with a different payload hash, it returns 409 Conflict (same key, different data).
  • If the idempotency key exists with the same payload hash, it returns 200 and indicates the submission is a duplicate, including the existing lead ID.
  • If no match exists, it inserts a new row with status pending and returns 202 with the new lead ID.

Use cases

• Form submissions that may be retried by a frontend or third-party service (deduplicate safely).
• SaaS lead intake where replays can occur during network retries—detect and respond with 409 on conflicting data.
• Backend systems that post leads multiple times—ensure your CRM pipeline only processes truly new leads.

Technical details

• Webhook trigger to receive lead submissions.
• if logic for required-field and idempotency decisions.
• code node for payload normalization and response routing.
• crypto to hash the normalized payload for replay detection.
• data table node to store and look up leads in lead_intake_template.
• Includes sticky note guidance for setup and webhook usage.