Means for debugging web requests and responses

Feedback
1

Been getting acquainted with the n8n for a little while and it’s great all around. But there is one thing that is giving me trouble, that there is not a way to see what actual requests are being made by the nodes, or the responses that are being returned. It is hard for me as a newcomer to comprehend why, in a system that relies on web requests to function, there wouldn’t be a tool to inspect and debug them.

It’d be undeniably nice if we could apply nodes without ever turning to the API details, but in practice as you build or change the workflows or experiment with services something is always broken or appears to be vaguely broken, and I find having no means to determine what or why or how is extremely frusrating and time consuming.

Other people had asked before and the Team seem to have a go-to workaround - it is to redirect the requests to the webhook.site . Which is clearly inconvenient at best, as that, on top of having to change the credentials back and forth, also exposes authorization secrets, and sometimes downright inapplicable when, like in my case, the site just doesn’t load.
I ended up using the HTTP Toolkit, which works locally, does not require any changes to the configuration, and still allows me to inspect all network exchange of the n8ns Docker container in a literal one click. I wish I had that recommended to me sooner.

(The Google AI overview also keeps picking on the idea to use N8N_LOG_LEVEL=debug, which of course does nothing for the request debugging as they are never logged. Hopefully this topic will help it provide a more coherent advice once it’s indexed.)

If there is a feature request or a bug report where the absense of this feature in the n8n itself, and the reluctance to introduce it, is discussed and explained, please share a link. I have attempted but given up on finding one myself - the keywords are too generic so the search comes up with a bunch of unrelated results.

Topics for reference:
https://community.n8n.io/t/log-http-request/2201
https://community.n8n.io/t/general-http-request-debugging/2755
https://community.n8n.io/t/how-to-log-request-in-http-request-node-for-multiple-items/12325
https://community.n8n.io/t/is-there-a-way-to-inspect-the-actual-http-requests-in-n8n/20573
https://community.n8n.io/t/log-http-requests/198716

1 Like
2

@Rpahut Really well-put feedback, and I completely agree with the frustration. This is something that comes up constantly for anyone building non-trivial integrations.

HTTP Toolkit is a great find - it’s genuinely underused in the n8n community. A few more approaches worth knowing about:

1. requestbin.com / pipedream’s Request Bin - Gives you a public HTTPS URL that captures and displays every request with full headers, body, query params. Faster to spin up than webhook.site and no auth exposure issues since you control the URL.

2. ngrok Inspect UI - If you’re already using ngrok for webhook development, it has a built-in request inspector at http://127.0.0.1:4040 that shows every request in real time with full payloads. Zero config needed.

3. n8n’s own output panel - This is actually underutilized. When you click a node after execution, the INPUT and OUTPUT tabs show the full JSON that went in and came out. For HTTP Request nodes specifically, enabling “Always Output Data” and checking the response object gives you status code, headers, and body all in one place. No proxy needed.

4. Code node as a logger - A quick console.log(JSON.stringify($input.all(), null, 2)) in a Code node after any HTTP node prints everything to your n8n logs. When running self-hosted Docker, you see it in real time with docker logs -f your-n8n-container.

That said, I do think the team could make the HTTP Request node’s request/response introspection more native. Upvoted.

3

I feel it is better that I correct the praise I gave n8n above, so as not to mislead those who might choose to trust my judgement. It is true that it’s more mature, compared to other low-code automation platforms I tried before it, but it is still unreasonably hard to get the flow to do what you need, even the simple things. What I initially thought to be an unfortunate odd obstacle to get over, now I realise is likely a part of the experience, unfortunately.