Stop the duplicate order where it can do damage.

If two Shopify orders/create events reach n8n seconds apart, the question is not only whether the payloads look identical. The real question is whether both executions can reach the action that sends, creates, fulfills, or charges.

Shopify documents that duplicate webhook deliveries can happen after a retry or network timeout. It sends a unique webhook delivery ID in X-Shopify-Webhook-Id and an event ID in X-Shopify-Event-Id that can correlate deliveries from the same merchant action. That gives you the raw material for deduplication, but the workflow still needs to use it before anything irreversible happens.

First, prove where the duplicate comes from

Do not assume Shopify is the only source. Compare the two n8n executions and record:

• the Shopify shop domain and webhook topic;
• the order ID in the payload;
• the webhook delivery ID and event ID when the trigger exposes them;
• the start times and the first node where the executions diverge; and
• the exact action that happened twice.

If the delivery IDs differ but the event ID and order ID match, multiple deliveries or subscriptions may represent the same merchant action. If every identifier differs, investigate whether another trigger, manual retry, or second active workflow is creating the duplicate.

Layer 1: remove repeated inputs early

Place n8n’s Remove Duplicates node immediately after the trigger. For cross-execution protection, choose Remove Items Processed in Previous Executions, keep items where the value is new, and dedupe on the strongest stable identifier available.

n8n stores 10,000 items by default for the cross-execution operation, and the history can be scoped to the node or workflow. That is useful operational protection, but it should not be the only control around a payment, customer message, fulfillment, or public write.

Layer 2: guard the side effect atomically

Two executions that arrive nearly together can both pass a normal “look up, then create” check before either one writes the result. That race is why the action needs a persistent claim that only one execution can win.

Create a deterministic key immediately before the action:

Claim that key with a database unique constraint, an atomic insert or upsert, or the destination’s native idempotency-key feature. The first execution continues. The second receives “already exists,” records a duplicate-skipped status, and ends successfully.

Acknowledge Shopify quickly

Shopify expects a successful response quickly and documents a five-second limit for the complete request. Slow or failed acknowledgements can cause retries. Keep the webhook receiver light: verify the delivery, persist or queue the work, return success, and process slower actions after acknowledgement when your architecture supports it.

Shopify’s current documentation says failed HTTPS deliveries are retried up to eight times over four hours. The delivery logs can show response code, response time, retry attempt, webhook ID, shop, and headers. Use those logs to distinguish a Shopify retry from a second n8n workflow or a manual replay.

Test the race, not only the happy path

A single manual execution does not prove the guard works. Test these cases in a controlled environment:

1. one normal delivery;
2. the identical payload twice in sequence;
3. two identical deliveries started as close together as possible;
4. a failure after the idempotency key is claimed but before the side effect finishes; and
5. a legitimate later update that should still be allowed.

Log only what you need: shop, topic, order ID, delivery or event ID, idempotency key, decision, and final status. Avoid customer names, addresses, and payment data in diagnostic logs.

What a successful fix looks like

The first execution produces the intended result once. A repeated delivery is acknowledged without repeating that result. The log explains why it was skipped. A failed action can be retried deliberately without clearing the guard blindly or recreating the original race.