Free tool - no signup - no workflow connection

n8n webhook duplicate checker

Could one webhook event act twice?

Check the production path for the conditions that turn a redelivery, partial failure, or manual retry into a duplicate email, record, update, charge, or downstream call.

Six questionsBrowser onlyNo workflow uploadNo credentials
Check the replay path

Six-question self-check

Trace the replay path before it acts twice.

Answer from the production path you actually publish. The checker runs locally in this browser; it does not connect to n8n, upload a workflow, or store your answers.

01Can the production webhook be called without authentication?

Count this as yes when the endpoint has no Basic, Header, or JWT authentication and no equivalent caller control.

02Can the sender retry or redeliver the same event?

Payment providers, form systems, queues, and custom clients may retry after a timeout or unclear response.

03Does the path create a real side effect?

Examples include sending a message, creating a record, charging money, updating inventory, or calling another webhook.

04Is there no stable event key checked across executions?

A timestamp generated inside the workflow is not the same as a stable source event, order, message, or request ID.

05Could a failed execution be retried after an earlier step already acted?

A partial failure can leave the external action complete even though the overall execution is marked failed.

06Is there no error workflow or equivalent failure alert?

Without an alert, a failed run may be replayed later without enough context to know what already happened.

Self-check result

11of 17 risk points

Moderate duplicate risk

Some controls may exist, but at least one meaningful replay path still deserves a direct test.

Next controls to verify
  1. Require an appropriate webhook authentication method and restrict callers where practical.
  2. Document the sender's retry behavior and preserve a stable event identifier from the first node.
  3. Place a duplicate gate immediately before the first external side effect, not only near the trigger.
  4. Choose a source-controlled idempotency key and check it against previously processed events before acting.
This is a risk screen, not a production audit.

It cannot inspect node settings, credentials, upstream retry rules, stored execution history, or the behavior of connected systems. Do not enter secrets, customer data, or workflow JSON.

The safe unit is the external action

Receive, identify, gate, then act.

A duplicate-safe design carries a stable source event key to the final side effect, records the completed action, and treats a replay as an expected test case.

  1. 01

    Authenticate the caller

    Publish the intended URL and control who can invoke it.

  2. 02

    Preserve the event key

    Use a source-controlled ID that survives every retry.

  3. 03

    Check before the side effect

    Reject or safely return events already processed.

  4. 04

    Test the replay

    Send the same synthetic event twice and verify one action.

Current n8n documentation

The checker maps to documented platform behavior.

These official references explain production webhook controls, cross-execution duplicate removal, manual retries, and error workflows. They do not claim that every workflow needs the same configuration.

01

Webhook controls

n8n documents separate test and production webhook URLs plus Basic, Header, and JWT authentication options.

Read official Webhook docs

Need the actual workflow checked?

Get five prioritized risks for $25.

Send one sanitized export and two or three sanitized run examples. Receive a manually checked, node-level reliability report within 24 hours after complete intake. No live account access or production changes.

Boundaries before conclusions

What this self-check can and cannot tell you.

Does this checker connect to my n8n instance?

No. It runs in the browser and uses only the answers you select. It does not request credentials, workflow JSON, execution data, or customer data.

Can a webhook run twice even if n8n is working correctly?

A sender may retry or redeliver a request after a timeout or unclear acknowledgement. A person can also retry a failed n8n execution. Duplicate protection should therefore be designed around a stable event key and the external side effect, not an assumption that every event arrives once.

Does the Remove Duplicates node solve every replay problem?

No. n8n can compare current items with items processed in earlier executions, but the selected fields, retained history, workflow path, and connected system behavior still matter. The real external action should also have a tested idempotency boundary where possible.

What happens after the $25 review checkout?

A protected intake page asks for one sanitized workflow export, two or three sanitized run examples, and the expected outcome. The deliverable is a manually checked written report; it does not include live account access or production changes.