n8n Automation HubAn error that looked like an expired credential
"Token not found" reads like an API key problem — check the credential, maybe it rotated, maybe it expired. That instinct was wrong here in an unusual way: there was no API key involved at all. The node making the request used authentication: none. The "token" in the error message wasn't a credential; it was the random identifier baked directly into the URL path of a webhook.site link: https://webhook.site/c6225739-8808-….
Webhook.site is a genuinely useful tool for a completely different purpose than what this URL was doing in a production workflow: it hands out a temporary, unique inbox URL so a developer can see exactly what an HTTP request looks like while building an integration, before the real endpoint exists or is reachable for testing. Every request to that inbox URL is logged and viewable in a browser. It is explicitly not meant to be a permanent target — inboxes are session-scoped and expire.
The URL that was never swapped out
At some point, this node was built the ordinary way anyone builds an HTTP integration: point it at a webhook.site URL first, inspect what the real supplier API was expected to return, confirm the request shape looked right, then replace the placeholder with the actual production endpoint before shipping. That last step never happened. The workflow was activated with the testing URL still in the url field, and every scheduled run since then has been dutifully firing a GET request at an inbox that either never received a real response in the first place, or expired not long after.
Nothing about this fails loudly. There's no red banner, no alert distinct from any other transient HTTP error — just the same "Token not found" response, forever, indistinguishable at a glance from a rate limit or a flaky upstream service. The workflow's execution log shows a clean, specific failure message every single run, which paradoxically makes it easy to skim past: a specific-looking error reads as "this particular request had a problem," not "this node has never once pointed at anything real."
Why this one has no tidy before/after fix
Most bugs on this site end with a corrected expression, a retry setting, or a reconnected credential, confirmed by a clean re-run. This one is different for two compounding reasons. First, nobody currently has the real supplier API endpoint or credentials this node was originally meant to call — that context left with whoever built it, and a webhook.site placeholder is a dead end for reconstructing it after the fact. Second, and more decisively: the system this workflow was meant to update on the other end had itself been decommissioned separately, well before this specific fetch failure was even investigated. Even a perfectly working data source at the front of this workflow would have nothing live to write to at the back of it.
That makes the honest fix not a code change but a decision: either someone supplies the real API details and the downstream target gets rebuilt or restored, or the workflow gets deactivated so it stops consuming a schedule slot and cluttering the error log with a failure that was never going to resolve itself. Leaving an active schedule trigger pointed at a known-dead placeholder is worse than deactivating it and leaving a note — a workflow that's off is honestly off; a workflow that's on and silently failing every cycle looks, from the outside, like something that might still be working.
The generalizable check
Any node whose target URL contains webhook.site, requestbin, ngrok-free, or a similarly named testing/tunneling service is worth treating as a red flag the moment a workflow using it gets activated on a schedule, not just at build time. These tools are designed to be temporary by nature — expiring URLs are the intended behavior, not a bug in the tool. A quick audit worth running periodically on any n8n instance: grep every workflow's HTTP Request and Webhook node URLs for known testing-tool domains, and confirm none of them are sitting inside something still marked active.