n8n Automation HubA contradiction that shouldn't have been possible
Every attempt to use a set of n8n workflow-management tools — reading a workflow, listing workflows, anything — came back with the same flat rejection: an authentication error, reporting that the API key couldn't be validated. That alone wouldn't be unusual; API keys expire. What made it worth digging into further was that the very same toolset's own connection-diagnostic call, run right alongside the failing ones, reported the connection as healthy: configured, and connected. Two calls into the same nominal integration, giving directly contradictory answers about whether the credential worked.
Ruling out the obvious suspect first
The first, most likely explanation was simply that the API key itself had actually expired or been revoked, and the health-check call was just wrong or checking something shallower than real authentication. Testing that directly settled it: hitting n8n's own REST API with plain curl, using the same key value pulled from its source configuration file, worked without any error at all — a normal, authenticated response. The key itself was fine. Whatever was failing was specific to how one particular tool was using it, not the credential's real validity.
Two different copies of "the same" key
That left one real possibility: the tool wasn't actually using the current key at all, despite believing it was. Decoding the JWT baked into that tool's own stored configuration confirmed it — its exp claim pointed to a date a full week earlier than the day this was investigated. A separate configuration file elsewhere on the system, the one used successfully for the direct curl test, held a key that had been rotated more recently and carried no expiry claim at all. Two files, both nominally holding "the n8n API key" for the same account, had quietly drifted out of sync with each other.
Why the health check didn't catch it
The diagnostic call reporting connected: true wasn't lying so much as checking something less strict than the tools that actually needed to authenticate a real request — enough to confirm the process could reach the n8n instance at all, without necessarily exercising the exact same authentication path that a real create/list/update call requires. That gap between "the health check passed" and "the actual operation works" is exactly what made the contradiction possible, and exactly why it's worth treating a passing health check as necessary, not sufficient, evidence that a tool is genuinely usable.
Why updating the config alone didn't immediately fix it
Updating the stale configuration file to point at the current key was the correct long-term fix, but it didn't retroactively repair the tool process already running — that process had read the old key once, at its own startup, and had no mechanism to notice the file underneath it had changed. Only a session or process started after the fix actually picked up the corrected key. Any session that had already been running when the update happened would keep failing the same way until it, too, was restarted.
The generalizable habit
Two lessons carried forward from this: first, when a tool's own health check disagrees with the tool's actual operations failing, trust the operations, not the health check — and verify the underlying credential independently (a raw curl call, in this case) before assuming either the tool or the credential itself is definitively broken. Second, when two separate configuration locations are both supposed to hold "the same" rotating secret, a routine key rotation that only updates one of them is a silent, delayed-fuse failure — worth diffing both locations whenever a credential gets rotated, not just updating the one file that happened to be open at the time.