The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →To prevent duplicate CRM records in n8n, make repeated processing of the same logical event safe: normalize and validate a stable identifier, then use a CRM upsert, an atomically enforced unique key, or another destination-supported safeguard for the final write. A lookup before create can help, but by itself it cannot prevent two concurrent executions from creating the same record.
Why retries create duplicates
A webhook sender may time out or lose its connection after the CRM has accepted a create request. Because the sender cannot tell whether the write succeeded, it may send the event again. If the workflow issues another ordinary create, the CRM may store a second record. n8n’s guide explains this retry problem and notes that retries are a normal part of automation: How To Build Reliable Workflows With API Idempotency.
As an Amazon Associate I earn from qualifying purchases.
The goal is not to promise exactly-once execution. It is to make processing the same event again produce a safe, predictable result. The CRM’s API and enforcement rules determine what can actually be guaranteed.
Build the workflow around a stable identifier
A practical pattern is:
- Trigger: Receive the webhook or other input.
- Normalize: Trim and standardize the fields used to identify the event or entity.
- Validate: Confirm that the chosen identifier exists and is usable.
- Deduplicate or upsert: Use the CRM’s native operation or another destination-enforced safeguard.
- Verify: Confirm the result using the CRM’s supported response or lookup behavior before triggering consequential downstream actions.
Choose a key for the right kind of duplicate
If the problem is the same webhook or event being processed again, prefer a stable event ID provided by its source. For matching CRM entities across different events, use a field the business treats as unique and the CRM can enforce or reliably match. A person’s name is generally not a safe unique key: different people can share it, and the same person’s name can be entered in different forms.
#1 Best Overall
An n8n execution ID identifies a particular run, not the underlying event. A manual re-trigger creates a new execution ID, so a key based only on the run will not reliably catch the same input processed again.
Normalize and handle missing keys deliberately
Apply the same trimming, case, and formatting rules before lookup, comparison, or key generation. Decide what to do with a missing, malformed, or ambiguous identifier: reject it, send it for review, or route it through an explicitly designed fallback. Do not generate a new random key on each attempt, because that makes a replay look like a new event. Confirm that your normalization rules agree with the CRM’s matching behavior.
Choose a safeguard for the final CRM write
The final write is where duplicates must be prevented. A preliminary lookup is useful for filtering, but the destination should ideally enforce the relevant behavior atomically.
Rank #2
- Pre-designed templates for both business and personal use
- 10,000 clipart images and 100 fonts
- Notes table for history and to-do items
- Sort, filter and index
- Calculation & totaling
| Approach | Useful when | Limitation to account for |
|---|---|---|
| CRM-native upsert | The connector or API supports upsert on a reliable match field. | Match fields and update semantics vary by CRM and record type; confirm what the operation matches and which fields it overwrites. n8n’s Zoho CRM documentation lists upsert operations for accounts, contacts, deals, leads, and other entities: Zoho CRM node. |
| Destination unique key or conditional write | The CRM or destination can atomically reject a repeated key or conditionally apply a write. | It requires the appropriate configuration or API support. The safeguard must apply to the actual write, not merely to an earlier lookup. |
| API idempotency key | The receiving API documents and honors idempotency keys. | A header has no protective effect if the server ignores it. Check the API’s key scope, retention period, and replay behavior, then reuse the same stable key for retries. |
| Durable event or deduplication ledger | You need explicit processing state, or the CRM lacks a suitable native feature. | The ledger needs atomic reservation, failure handling, and a retention policy. A separate “check, then insert” in the ledger can race too unless reservation is atomic or concurrent processing is controlled. |
| Read before create | You need best-effort filtering in a low-volume workflow where concurrent executions are controlled. | It does not enforce uniqueness at the final write and is vulnerable to simultaneous executions. |
When native upsert fits
Use upsert when the CRM’s operation matches on the identifier you intend and its update behavior is acceptable. The n8n Zoho CRM node is one documented example; its availability does not establish that other CRM connectors or every record type offer equivalent behavior. Check the selected CRM’s documentation for the target entity and match field before relying on it.
When using an HTTP Request node
For an API that explicitly supports idempotency keys, send a stable key derived from the input event and reuse it across retries. Do not use a fresh value for each attempt. Consult the target API documentation rather than assuming that an idempotency header is recognized.
HTTP method conventions are useful guidance, not a substitute for endpoint documentation: GET and PUT are intended to be idempotent, POST generally is not, and PATCH behavior depends on how the endpoint is designed. A CRM endpoint may not implement those semantics as expected, so verify the specific API operation.
Account for concurrent executions
A check-then-create flow has a race condition: two executions can both look for the key, both find no record, and both create one. This can happen even when each individual run appears correct. n8n’s guide describes unique constraints, optimistic locking, and conditional updates as ways to protect writes when identical requests arrive at the same time; these safeguards must be supported by the destination.
Recommended Free Tools
Prefer an atomic upsert, unique constraint, conditional write, or server-side idempotency record. If none is available, serialization can reduce the chance of a race, but it also limits throughput and must cover every path that can write the same key. A separate check table only helps when its reservation operation is atomic or concurrency is otherwise controlled.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Configure retries and recover from uncertain outcomes
n8n’s HTTP Request node provides retry controls, including Max Tries and Wait Between Tries. Enable automatic retries for a side-effecting CRM request only when the destination makes the operation safe to repeat through an upsert, unique enforcement, documented idempotency key, or equivalent mechanism. Retrying an unguarded create can turn a transient network problem into a duplicate.
If a request times out, treat the outcome as unknown rather than assuming it failed. Look up the stable key or repeat the same idempotent operation; do not issue an unguarded create simply because n8n did not receive a clear response. A successful workflow execution status alone does not establish that exactly one intended CRM record exists, so use the verification behavior supported by that CRM before running downstream actions that depend on the record.
Check the guarantee at the CRM boundary
- Confirm the event or entity key remains the same across webhook retries and manual re-triggers.
- Test how the CRM matches that key, including case, whitespace, missing values, and updates to an existing record.
- Test simultaneous requests if the workflow can receive concurrent events.
- Review how the API reports an existing record, a rejected duplicate, and an uncertain timeout.
- Verify the final record using the CRM’s API or connector behavior before treating downstream work as complete.
n8n’s Data Table API reference describes upsert as updating a matching row or inserting one when no match exists: Data Tables API reference. A Data Table can help maintain a workflow ledger, but its upsert semantics should not be assumed to make a separate CRM write atomic with the ledger. Protecting both actions across systems requires appropriate safeguards at each boundary.
n8n also lists a workflow template using an external AARI idempotency gate, whose description claims duplicate events are blocked within a 24-hour window and gives Stripe event IDs and Shopify order IDs as example keys: Prevent duplicate webhook executions with AARI idempotency gate. That window and service are specific to the template, not a general n8n or CRM guarantee.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
