MINI-COURSE · LESSON 2 OF 3
- n8n Webhooks: Test vs Production URLs
- What is an n8n webhook?
- Test URL vs production URL
- Why does an n8n webhook need a public URL?
- Address
- Route
- Permission
- A reachable webhook should still have an access plan
- Before giving a webhook URL to another service
- A webhook URL is both an address and an entry point.
n8n Webhooks: Test vs Production URLs
Learn why an external service needs a reachable webhook address, how n8n’s test and production URLs differ, and which access settings to review.
The short answer: a webhook is an endpoint that lets another service send an event to n8n and start a workflow. Use the test URL while developing; the production URL is registered when you publish the workflow. If the sender is outside your network, it must be able to reach the URL you give it.
What is an n8n webhook?
A webhook is a URL that can receive an HTTP request when an event happens in another service. In n8n, the Webhook node can act as a trigger: it receives the request and starts the workflow with the incoming data. Depending on the node’s response settings, the workflow can also return a response to the caller.
For example, an external form service could send a submission to a webhook. The workflow might then check the fields and create a record in another app. The webhook is the entry point; the nodes after it decide what happens next.
The n8n Webhook node documentation describes it as a trigger for receiving data from apps and services.
Test URL vs production URL
n8n displays both URLs in the Webhook node. They are not interchangeable: the test URL is for developing a workflow, while the production URL is for an active, published workflow.
| Question | Test URL | Production URL |
|---|---|---|
| When does it work? | When you select “Listen for Test Event” or execute the workflow for testing. | When the workflow is published and its production webhook is registered. |
| What is it for? | Trying a request and checking the incoming data in the editor. | Receiving real requests for the published workflow. |
| Where do you inspect a run? | The test data appears in the workflow editor. | Open the workflow’s Executions tab to inspect a production run. |
| What should you share? | Use it only with the sender you need for the current test. | Give the external service the production URL after checking access and response settings. |
Why does an n8n webhook need a public URL?
If the service sending the event runs outside your private network, it needs a network route to the webhook URL. A URL that works only on your laptop or inside a private network may not be reachable by an external provider.
“Public” means reachable from the relevant sender; it does not mean that every person should be allowed to use the endpoint. Reachability and authorization are separate decisions. The network path lets a request arrive. Authentication and other checks help decide whether the request should be accepted.
Address
The URL must point to the correct n8n endpoint and use the address that the external service can reach.
Route
A domain, reverse proxy, firewall, and n8n configuration can all affect whether a request reaches the workflow.
Permission
Decide who may invoke the webhook and what data the workflow should accept or return.
When n8n runs behind a reverse proxy, its internal address may differ from the public webhook address. The n8n guide explains how to configure the URL and proxy settings so the editor displays the correct endpoint: webhook URLs with a reverse proxy.
A reachable webhook should still have an access plan
The Webhook node supports Basic auth, Header auth, JWT auth, or no authentication. It also offers an IP allowlist option. Which choices make sense depends on the calling service and its capabilities. If a provider cannot send the type of authentication your workflow expects, the request may fail until the integration is configured to match.
- Choose an authentication method. Avoid leaving a sensitive action open without considering who can call it.
- Check the sender’s capabilities. Confirm it can send the required authentication headers or token.
- Use an IP allowlist only when it fits. It can restrict callers by IP, but the allowed addresses must match the sender’s actual network behavior.
- Review the request fields. Pass only the information the next workflow steps need.
- Choose the response deliberately. A webhook can return immediately, wait for the last node, or use a Respond to Webhook node.
Before giving a webhook URL to another service
- Confirm the workflow state. Decide whether you are testing or using the published production endpoint.
- Check the exact URL. Make sure you copied the matching test or production URL from the Webhook node.
- Confirm external reachability. Consider the domain, proxy, TLS, firewall, and n8n URL configuration.
- Set an access method. Match the authentication and allowlist settings to the sender.
- Limit the information handled. Review incoming fields, node mappings, stored execution data, and the response body.
- Inspect a production run. n8n shows production execution data in the workflow’s Executions tab rather than in the editor canvas.
A webhook URL is both an address and an entry point.
The test URL helps you develop and inspect incoming data. The production URL belongs to the published workflow. For an external service to call it, the URL must be reachable from that service; access controls determine which requests the workflow should accept.
Before using a webhook, check three things: the right URL, a working network route, and an access method the sender can use.
