n8n Webhook Test URL vs Production URL: What's the Difference?

An n8n workflow can work perfectly while you're watching the editor, then appear to stop the moment you try to use it from your website or another service. The culprit is often not your nodes or credentials. It's the difference between test and production webhook URLs.

Let's walk through how each URL works, how to switch to a live webhook, and what to inspect when your request never arrives.

The short answer

Every n8n Webhook node provides two URLs:

	Test webhook	Production webhook
Typical path	/webhook-test/...	/webhook/...
Intended use	Development and debugging	Live integrations
Listening	When you explicitly listen for a test event	When the workflow is published
Where to inspect data	Editor while listening	Workflow executions

The exact hostname and path depend on your installation. Don't hard-code the examples below into a production integration; copy the actual URLs from your Webhook node.

1. How the test URL works

During development, add a Webhook trigger and choose the request method that matches your sender, such as POST.

Then choose Test URL and select Listen for test event. Send a request while the node is listening. The request data appears directly in the editor, which makes it convenient to inspect incoming JSON, headers and query parameters.

According to n8n's webhook documentation, the test listener is temporary (currently described as 120 seconds). If you send another request after it stops, you may see a 404 or another error because no test listener is registered.

Here is a sample request shape using a placeholder domain:

curl -X POST 'https://automation.example/webhook-test/lead' \
  -H 'Content-Type: application/json' \
  -d '{"name":"Taylor","source":"contact-form"}'

In n8n, the payload typically appears in the Webhook node's output once the test event arrives. Confirm that the field names match what your downstream nodes expect.

2. How the production URL works

Once your workflow is ready:

1. Save the workflow.
2. Publish it so its production trigger is registered.
3. Copy the node's Production URL.
4. Update the sending service to use the production URL instead of the test URL.
5. Send a controlled request, then inspect the workflow's Executions history.

A production webhook typically looks similar to this:

curl -X POST 'https://automation.example/webhook/lead' \
  -H 'Content-Type: application/json' \
  -d '{"name":"Taylor","source":"contact-form"}'

Unlike test events, live production webhook activity is not necessarily shown as an interactive event on the editor canvas. The Executions view is the place to verify that a workflow ran and to investigate failures.

3. Troubleshoot a webhook that stopped working

Use this checklist in order, so you don't spend time debugging downstream logic before confirming the request is reaching n8n.

Check the exact URL

It's easy to paste a /webhook-test/ URL into a form integration and forget to change it later. Open your n8n Webhook node, copy its Production URL, and compare it character by character with the destination configured in the external service.

Check the workflow's published state

Saving edits is not the same as making the production trigger live. Confirm the current workflow is published. If you've made changes that affect the webhook path or request method, publish the correct version and update the client.

Match the HTTP method

A GET webhook won't automatically behave like a POST webhook. Confirm that the sender is using the same method configured in the Webhook node.

Inspect the Executions tab

If you see an execution but it fails after the trigger, the webhook is working and your error is in another node or data mapping. If no execution appears, investigate the sender, destination URL, network and reverse proxy first.

Check public access on self-hosted n8n

A browser on your laptop can access localhost, but an external CRM or payment service cannot. Self-hosted deployments need a reachable hostname, HTTPS, and correctly configured reverse-proxy routing. Set n8n's external webhook URL configuration when your proxy changes the public address.

4. Secure the production endpoint

A public webhook is effectively an internet-facing entry point. Before using it to create customer records, send emails or initiate payments, implement suitable safeguards:

• Choose an authentication mechanism supported by the sender and n8n (such as header authentication).
• Validate the incoming payload's type, required fields and size.
• Where supported, verify the sender's message signature, not just a shared URL.
• Add rate limits, retries and idempotency so duplicate requests don't create duplicate records.
• Never embed API keys or personal information in public documentation or screenshots.

The Webhook node supports authentication options, but that does not mean every external service supports every option. Check the sending service's documentation before choosing a method.

5. A reliable go-live checklist

Before handing a workflow to a customer, send one controlled production request from the actual external system, verify that an execution was created, check the final action and test a realistic failure case. Document the webhook's owner and the process for rotating secrets.

Useful references

• n8n: Webhook workflow development
• n8n: Webhook node reference

The takeaway

Test URL for development; production URL for published workflows. When something stops firing, first determine whether the request reached the trigger at all. That single distinction usually cuts debugging time dramatically.