n8n Automation Hub
Why a specific past execution needed a closer look
A workflow had published content with garbled text, and the live, current version of that workflow already looked correct — meaning whatever had actually run that day was different from what was sitting in the editor now. The only way to see what genuinely executed is n8n's own execution history, which stores a snapshot of the workflow exactly as it was at run time, not the current state.
A tool that looked general-purpose
An available assistant tool advertised itself as a generic HTTP request tool for the n8n API — pass it a method, a URL, query parameters, whatever endpoint you need. That's exactly the shape needed to fetch one specific execution by ID with its full data attached.
The test that gave it away
Instead of trusting the first response, three deliberately different requests went through it: a GET for one specific workflow, a GET against a completely unrelated Google Sheets API URL, and a GET for the workflow list with different query parameters. All three came back identical — the same roughly 1.1-million-character response, a paginated dump of every workflow's full node bodies. Not similar. Byte-for-byte the same string, three times, for three requests that had nothing in common with each other.
What was actually happening
The tool's parameter schema accepted anything — no real validation, `additionalProperties: true` — but whatever was passed through it never actually reached wherever the real request logic lived. It always executed the same fixed call and returned the same cached-shaped result, regardless of input. Nothing about calling it threw an error or returned a failure status; it looked exactly like a successful, correct response every single time.
The actual fix: skip the wrapper
The box running this n8n instance is reachable directly, and n8n's REST API takes a plain API key in a header — no tool wrapper needed. `curl` with `X-N8N-API-KEY` against the instance's own `/api/v1` endpoint reached the real specific execution, with `includeData=true` pulling the full node-by-node data for that run, including a `workflowData` snapshot showing exactly what code executed at that moment in time — not what's live in the editor now. That snapshot is what actually solved the original bug; the broken tool would never have gotten there no matter how the request was phrased.
The generalizable lesson
A tool that wraps an API and claims to take real parameters is worth testing with more than one call before trusting its output, especially in an AI-assisted workflow where a wrong-but-confident answer looks identical to a right one. Three intentionally different inputs producing one identical output is a fast, cheap way to catch this — and going straight to the underlying API with a plain HTTP client is always the fallback that can't have this particular failure mode.