SOURCE-BASED ANALYSIS · NO HANDS-ON RATING
Start with the endpoint contract
A working editor demonstration is only the first checkpoint. n8n provides separate test and production webhook URLs. The test endpoint is registered when listening for an event or executing the workflow; the production endpoint is registered when the workflow is published. Production execution data is available through Executions rather than appearing directly on the canvas. The Webhook node supports selecting the HTTP method and requiring authentication, including header authentication.
Before changing anything, record the exact destination configured in the sending application, its HTTP method and the authentication it sends. Compare these with the node settings. Do not regenerate a path while another application still points at the old endpoint. Use a disposable workflow and synthetic payload while investigating.
A lead-capture acceptance example
Assume a fictional agency accepts enquiries with an event ID, email and requested service. Its proposed contract is POST with JSON containing event_id, email and service. These field names are our design choice, not an n8n convention. Send a synthetic record such as event_id demo-101, email reader@example.com and service website. Define success as one stored enquiry and one assigned follow-up, rather than merely an HTTP response.
- Listen on the test URL and send that synthetic record with the chosen method and credentials.
- Inspect the incoming structure and map the actual fields into the destination action. Reject missing required fields before writing a record.
- Publish the workflow and replace the sender's destination with the displayed production URL.
- Send a second, uniquely identified synthetic event. Find its production execution and its destination record.
- Repeat the same event ID and observe whether it creates another record. Add destination-side uniqueness or an equivalent durable duplicate check if needed.
Diagnose one layer at a time
| Observation | Next check |
|---|---|
| No execution appears | Check URL type, publication state, method and sender delivery log. |
| Sender reports an authentication rejection | Compare the configured credential scheme and actual headers; do not remove authentication as a permanent fix. |
| Execution exists, destination is empty | Inspect mapping and destination action output. |
| Record exists twice | Compare event IDs and sender redelivery history before replaying anything. |
These observations narrow the investigation; they do not prove a single cause. A proxy, external service or application-specific validation rule can introduce another failure. Capture response status and a redacted response body alongside the event ID so that the next investigation has evidence.
Choose what the response promises
Write down whether the caller is being told that an event was received or that every business action completed. Treat these as different contracts. If the caller times out after a destination write, blindly sending the same request can repeat the write. Choose a recovery procedure that looks up the event's existing outcome before creating a new one.
Our recommended launch gate is one normal event, one invalid payload, one repeat delivery and one destination failure. Record the expected result before each trial. Do not run these checks against real customers without an isolated destination. This is a proposed acceptance procedure, not a tested integration or a guarantee of delivery.
Sources and verification
Official documentation checked on 2026-10-28. Worked examples are hypothetical planning exercises, not measured product benchmarks.