Testing n8n Webhooks Locally
with curl Before Production

Personal note: This article reflects my experience and is for educational purposes only—not official vendor guidance. Always verify procedures against current vendor documentation.

1. Objective and scope

The goal is to prove that an n8n Webhook node can receive an HTTP POST request and parse its JSON body before the workflow is connected to any production system. The workflow can be tested with curl from the n8n host or another machine that can reach it over the network.

In the lab setup documented in the conversation, n8n is already running on port 5678 and the chosen test path is n8n-test. The private host address is intentionally left as a variable in this public article. The conversation did not record a completed curl response or a successful n8n execution, so successful delivery is a validation step—not a claimed result.

2. Configure the Webhook node

1. Create or open the workflow in n8n and add a Webhook trigger node.
2. Set HTTP Method to POST.
3. Set Path to n8n-test, matching the path you plan to call. If you use a different path, update the curl URL to match it exactly.
4. For a restricted local smoke test, choose the authentication setting appropriate for your lab. Do not expose a webhook with authentication disabled to untrusted networks.
5. Select Listen for test event (or the equivalent test execution action in your n8n version) so the test URL is registered before sending the request.

n8n generates a separate test URL and production URL for each Webhook node. The test URL is used while building and debugging the workflow; the production URL is registered when the workflow is published. See the official Webhook node documentation.

3. Send a test request with curl

Run the following from the same host as n8n by using localhost, or replace the base URL with the address reachable from the machine running curl. For example, in a shell:

# Use localhost when curl runs on the n8n host.
# For a remote test client, use the n8n host's reachable LAN address.
N8N_BASE_URL="http://localhost:5678"

curl -i --max-time 10 -X POST \
  "${N8N_BASE_URL}/webhook-test/n8n-test" \
  -H "Content-Type: application/json" \
  -d '{
    "message": "n8n webhook connectivity test",
    "source": "curl",
    "test": true
  }'

-i prints the HTTP response headers as well as the response body, and --max-time 10 prevents the client from waiting indefinitely. The request body is deliberately small and contains synthetic test values. Replace the URL path if the Webhook node uses a different path.

4. Validate the execution

Confirm both sides of the request rather than relying only on an HTTP status:

• In curl: inspect the HTTP status and response body. A response proves that an HTTP endpoint replied, but its exact meaning depends on the Webhook node's response mode.
• In n8n: inspect the waiting test execution and confirm the incoming request appears in the node's output. Check that the body contains the expected message, source, and test values.
• For multi-node workflows: verify that downstream nodes ran and inspect their outputs separately. A Webhook node configured to respond immediately may return before the rest of the workflow finishes.

If you want curl to receive a final workflow result, configure the Webhook node to respond when the last node finishes, or use a Respond to Webhook node. Choose a response mode that matches the workflow's actual behavior.

5. Known issues and troubleshooting

Connection refused or timeout

• Verify that the n8n process/container is running and listening on port 5678.
• If curl runs on another machine, use the n8n host's reachable IP address or DNS name rather than localhost.
• Check host firewall rules and, for Docker deployments, verify that the port is published as intended.

Webhook not registered or not found

• Make sure the editor is listening for the test event before calling /webhook-test/n8n-test.
• Confirm the HTTP method is POST and the path matches exactly.
• Use the Test URL while debugging. A production URL uses /webhook/, not /webhook-test/.

The request arrives, but the workflow output is not what I expected

• Send valid JSON with the Content-Type: application/json header.
• Inspect the Webhook node's execution input before investigating downstream nodes.
• Check the Webhook node's response mode. An immediate 200 response does not guarantee that every downstream step completed successfully.

For further diagnostics, the official Webhook common-issues guide includes curl examples and advice for test versus production URLs.

6. Checklist before production

1. Confirm the request body and workflow execution are correct using the test URL.
2. Save and publish the workflow, then switch the caller to the production URL shown by the Webhook node, usually /webhook/n8n-test.
3. Use appropriate webhook authentication (Basic, Header, or JWT where suitable), restrict network access, and use HTTPS for production traffic.
4. Review the production workflow's response mode and error paths so the caller receives a truthful HTTP status and response body.
5. After switching URLs, run a controlled production-path check and review the workflow's Executions view. Production executions do not appear in the editor's test canvas in the same way as test events.

7. Official references

• n8n Webhook node
• Webhook workflow development: testing and production
• Webhook common issues, including curl tests
• Webhook authentication credentials
• Respond to Webhook node

This article documents the planned local validation process, not a verified successful test. Record the actual curl status and n8n execution output before describing the webhook as working in your environment. Validate these steps against the documentation for your installed n8n version.