The short answer: know which ID you are comparing
Shopify's X-Shopify-Webhook-Id is the delivery identifier the official docs tell you to use for detecting and skipping a repeated delivery in a persistent store. X-Shopify-Event-Id correlates deliveries generated by the same merchant action; several subscriptions can produce different delivery IDs for one action. Neither is automatically the Shopify order ID. The safest path is to verify the signed message, reason about the correct idempotency scope, and confirm downstream results separately.
A three-row example that changes the decision
Imagine a fictional store with a subscription that handles orders/create. Your delivery log excerpt is:
delivery_id,event_id,topic DELIVERY-A,EVENT-1,orders/create DELIVERY-A,EVENT-1,orders/create DELIVERY-B,EVENT-1,orders/create
Rows 1 and 2: identical delivery and event IDs appear twice in the supplied log. They merit a retry/export-duplication investigation, but you cannot tell which merely from these columns. Row 3: the same event ID arrives under another delivery ID. That might be an independently subscribed delivery for the same merchant action, not a repeat of delivery A. A rule that blindly drops every matching event ID risks suppressing valid processing for another subscription.
Open the browser-local duplicate checker, select the fictional example to analyze it immediately, and inspect the separate counts and row numbers. For this example, the checker points to CSV rows 2 and 3 as an identical observation, and rows 2–4 as related by event ID. The numbers describe supplied CSV records, not verified Shopify delivery history. It does not ingest live platform exports, verify timing, or decide whether an order was double-created.
What should the actual processing pipeline do?
- Verify authenticity first. For Shopify HTTPS deliveries, check the
X-Shopify-Hmac-SHA256signature against the raw request body using your app's secret, following Shopify's official documentation. Do not process an unverified payload just because it includes an ID. - Choose your processing scope. Use the delivery ID for per-delivery deduplication. Persist that key in a reliable store and decide when you mark processing complete. A process-local variable is not a durable deduplication strategy across restarts.
- Handle concurrent arrivals atomically. Two workers can otherwise both see an unseen key and both perform side effects. Your database transaction, uniqueness constraint or equivalent coordination should guard the actual business operation.
- Keep source and business identities separate. The merchant event key correlates notifications. The order/resource identifier is the business object you may need to look up to determine current state. Do not assume they are interchangeable.
- Record the downstream acknowledgment independently. Successful receipt of a webhook is not proof that your CRM, shipping provider or database now contains the intended result.
Where retries and out-of-order deliveries matter
Shopify documents retry behavior and warns that webhook deliveries are not a guarantee of complete, ordered business history. A prompt successful HTTP acknowledgment and a separately durable processing queue may be appropriate. However, one fixed retry assumption should not be copied across every transport, subscription type or platform API version. Confirm the current policy for your actual integration. If you missed an event while the endpoint was down, use authorized source-of-truth reconciliation rather than assuming a retry will eventually repair every gap.
Three different tools answer three different questions
Duplicate delivery investigation: this Webhook Delivery ID Audit identifies repeated observations, conflicting IDs and correlated merchant events in an authorized, pseudonymous snapshot. Missing execution or receipt: the Outcome Reconciler compares expected events, workflow executions and downstream receipts. Order missing from n8n: the Shopify-to-n8n troubleshooting guide maps source → trigger → receipt checks and gives a fictional three-file example.
This relationship matters: a repeated delivery can still leave no valid business receipt, and a seemingly successful workflow can still have missed a different source event. A single green checkbox is not enough evidence for both questions.
When this free checker is the wrong tool
For a live app with native Shopify delivery logs, a database uniqueness constraint and good observability, use your existing stack first. Our static browser tool cannot inspect HMAC, establish causal retry order, read real store data, persist deduplication keys, recover dropped events or prove final business outcomes. A simple spreadsheet pivot on these three columns may be sufficient. The benefit here is a narrowly explained, immediately exportable and identifier-redacted investigation snapshot.
A responsible next step
Try the synthetic example before preparing your own permitted snapshot. Keep identifiers pseudonymous and columns aligned to one time window. If the result shows conflicting delivery IDs, investigate the export method before designing a new idempotency rule. If it shows a correlated merchant action, consult subscription/topic context. If the event arrived but business output is absent, move to the outcome checker instead of adding another retry without evidence.
Need to hand off the investigation?
After checking delivery IDs and downstream outcomes, you can assemble a redacted workflow investigation handoff using the reports from the related free tools. It does not cross-match identifiers or certify the order state.
Primary sources
- Shopify: Verify webhook deliveries — signatures, distinct delivery/event identifiers, duplicate-handling examples.
- Shopify: Webhook delivery structure — documented header definitions.
- Shopify: Troubleshoot webhooks — diagnosis, retries and recovery guidance.
- n8n: All executions — reviewing workflow execution records and retries.
Source review: 28 October 2026. Original illustrative data; no assertion of indexed rankings, customer usage or recovered sales.