Building an entire workflow and then discovering that the webhook payload format is wrong wastes significant time.
Building an entire workflow and then discovering that the webhook payload format is wrong wastes significant time. Test the webhook node in isolation first: create a Webhook trigger, activate it in test mode, send a request with curl, and examine the exact data n8n receives. This confirms the payload structure before you build any downstream logic.
Real-world example: You are building a workflow triggered by a GitHub webhook for pull request events. Before building the processing logic, verify what GitHub actually sends.
# Use the test webhook URL shown in the Webhook node
# (click "Listen for test event" first)
curl -X POST \
'https://n8n.example.com/webhook-test/github-pr-handler' \
-H 'Content-Type: application/json' \
-H 'X-GitHub-Event: pull_request' \
-d '{
"action": "opened",
"number": 42,
"pull_request": {
"title": "Fix login bug",
"user": {
"login": "developer123"
},
"base": {
"ref": "main"
},
"head": {
"ref": "fix/login-bug"
},
"html_url": "https://github.com/myorg/myrepo/pull/42"
}
}'
```text
```text title="Step 2: Examine the webhook output in n8n"
The Webhook node output panel now shows exactly how n8n
received and parsed your request:
- headers: all HTTP headers including X-GitHub-Event
- params: URL path parameters
- query: URL query string parameters
- body: the parsed JSON payload
Use this output to write accurate expressions like:
{{ $json.body.pull_request.title }}
{{ $json.headers['x-github-event'] }}
```text
> **Tip: Save the curl Command**
>
> Keep your test curl commands in a shell script alongside the workflow. This gives you a repeatable test you can run anytime, even months later when you need to modify the workflow.
Testing webhooks first eliminates guesswork about payload structure and header names, saving you from the cycle of "change expression, re-trigger webhook, check if it works."
**Related:** [Always Set an Error Workflow on Every Production Workflow](../error-handling-and-reliability/01-always-set-an-error-workflow-on-every-production-workflow.md) | [Break Large Workflows into Sub-Workflows](../workflow-architecture/01-break-large-workflows-into-sub-workflows.md)
I build production n8n and Cloudflare automation for teams — the same engineering behind HarperFlow. Fixed-price, escrow-protected, US-based.