The idea is:
Introduce an “Error Detection Expression” feature for the HTTP Request node. Currently, HTTP Request nodes only refresh credentials automatically for 401 or 403 HTTP status codes. Many APIs, however, return 200 even when credentials are invalid, using custom business error codes in the response body. This prevents automatic credential refresh in such cases.
With this feature, users could define a custom expression to detect errors beyond standard HTTP status codes. When the expression evaluates to true, the node would automatically trigger credential refresh. If left empty, it would fallback to the default behavior of refreshing on 401/403.
My use case:
Most n8n built-in and community nodes are designed around a limited set of popular APIs. For less common APIs, users rely on the HTTP Request node combined with reusable credentials.
However, in scenarios where the API always returns 200 with a custom error code, the current HTTP Request node cannot refresh credentials automatically. This leads to expired credentials and failed workflows.
My current workarounds are:
Create a custom community node with a submodule similar to HTTP Request for custom requests.
Mix HTTP Request nodes and custom community nodes, using the custom node to handle automatic credential updates.
Both solutions work in practice but are technically inelegant and add complexity to workflow maintenance.
I think it would be beneficial to add this because:
Implementing this feature would allow the HTTP Request node to cover a much wider range of APIs and real-world scenarios, making credential handling more robust and workflows more reliable.
Any resources to support this?
Related discussion on n8n issues: #23410 comment
Are you willing to work on this?
Yes, I am willing to collaborate on testing or providing input based on practical use cases.