n8n webhook works in test mode but fails from your WordPress form

If your WordPress form reaches n8n while you are listening for a test event but stops working later, begin with the destination saved in the form integration. A successful editor test does not prove that the website is using a registered production endpoint.

This guide provides a diagnostic worksheet, not a report of a customer installation. The example identifiers are synthetic. Check the controls available in your installed n8n and form-plugin versions before making changes.

Separate the test listener from the production workflow

n8n supplies separate test and production webhook URLs. The test listener is temporary; production requires the workflow to be saved and published. Current documentation uses “Publish”; older interfaces may use an activation control. Production requests are investigated through execution history rather than expecting their data to appear in the editor canvas. See n8n’s workflow-development documentation.

Copy the production URL shown by the actual node. Do not construct it from memory or simply remove a word from the test URL. A custom path, reverse proxy or instance address can make an assumed URL wrong.

Write down the request contract before testing

Use this worksheet for one form and one workflow. Keep credentials and full private endpoint addresses out of shared notes.

• Form and page: a named test form on an isolated page.
• Destination: the production URL copied from the intended node.
• Method: the method the form integration actually sends.
• Body: expected field names, content type and required values.
• Authentication: the configured scheme and where the sender provides it.
• Expected result: one accepted execution and one synthetic destination record.

For the worked example, use submission ID demo-20261023-01, name Example Tester and address tester@example.com. Route any notifications to a controlled test destination. A recognisable marker lets you distinguish this request from old runs and unrelated traffic.

Follow the request across three boundaries

1. The form sends. Submit the test form once. Inspect the integration’s available request log. A browser network panel alone may not show a webhook sent by the WordPress server.
2. n8n receives. Look for the marker in the correct workflow’s executions. If saved-execution settings omit the relevant runs, record that evidence gap instead of treating an empty list as proof that nothing arrived.
3. The destination saves. Find the marker in the test destination and retain its record ID. An HTTP success response is evidence of acknowledgement, not necessarily completion of every later action.

The first missing boundary narrows the investigation. No sender evidence means you first inspect the form action and plugin logs. Sender evidence without a matching execution points toward the endpoint, workflow state, method, access control or network route. A received execution without the expected record points toward the workflow’s later nodes.

Use the response as a clue, not a complete diagnosis

• 404: compare the saved endpoint with the node’s production URL and verify the workflow is published. A proxy can also produce a 404, so identify which layer returned it.
• 401 or 403: compare the sender’s authentication with the node and any upstream access rules. Do not remove protection to make the status turn green.
• Method mismatch: opening a URL in a browser usually sends GET, which does not reproduce a form integration sending POST.
• Timeout: inspect execution and destination evidence before retrying. The business action may already have happened.
• Success with no destination record: inspect filters, field mapping and failed downstream nodes.

n8n documents webhook method handling, path conflicts and other failure cases. Use the section matching the observed symptom rather than changing every setting together. Webhook common issues.

Change one variable and repeat the same small test

Suppose the saved form action points to the test URL and the listener is no longer running. Replace that destination with the copied production URL, save the form configuration and verify the workflow’s published state. Submit a new marker, demo-20261023-02. This is an illustrative recovery sequence, not a measured result from our infrastructure.

Record what changed and compare the two markers. If the second request still fails, keep the corrected URL and investigate the next missing boundary. Repeatedly turning unrelated settings on and off destroys the evidence needed to explain the failure.

Keep a short handover note

Record the form, workflow owner, method, field contract, authentication requirement and destination used for verification. Include where execution evidence is retained and who handles failures. Repeat the test after a form-plugin update or workflow change that affects this contract.

For recovery after uncertain writes, read our guide to retries and duplicate records. That is a separate problem: a request can reach the correct endpoint and still create duplicate effects if recovery is poorly designed.

For a site-specific implementation, describe the form, tools and required outcome when enquiring about custom development. Compatibility and scope need to be checked for the actual installation.

Sources and preparation

• n8n: Webhook node
• n8n: test and production webhooks
• n8n: webhook common issues

Prepared with AI assistance using official documentation consulted on 23 October 2026. Examples are illustrative; no customer test or human approval is claimed. For corrections, use the author’s profile.

Illustrative cover photograph: Scott Rodgerson / Unsplash.

About the author

Martin Iliev

Martin builds Set It Once to help people spend less time on repeated work. His guides explain what you can try, how to check the result and where the limits are.

More about Martin

All articles