Webhook Error Handling

Questions
1

Hi all

New guy here…

We’ll be using n8n as an integration platform across multiple systems. Typically, the flows would follow the general pattern

  • Triggered from a webhook
  • Incoming info is validated
  • A series of nodes that do work in one or more systems via HTTP Requests or similar.
  • provide http response code and return payload to caller

Any one of the actions from validation onwards could ‘fail’, meaning the flow needs to terminate, and a suitable response sent to the caller.

I’m trying to work out the best way of handling this, but struggling to come up with an good option.

My first thought – which was to tell the webhook to return the ‘last executed’ node output, and use an expression to define the webhook return HTTP code, doesn’t fly – as described at How do I change or status code of a webhook - #4 by RicardoE105 we can’t currently do this.

My next thought was to use the Respond to Webhook node, and add an error trigger to the flow. When fired, the error trigger can then be used as the entry point for defining an error return. However:

  • Although the Error trigger is triggered if a node within the flow throws an error (e.g. if I have a function item that throws an error or an http call returns a 400), and the execution record indicates that the webhook response was executed, , the actual return to the caller is code 200 with {“message”:“Workflow did error.”}

For example

Error 1 - http request returns 400
Error 1 - http request returns 4001011×504 29.9 KB

At present, it seems the only way I can reliably manage the error handling is to

  • On each HTTP request, set Ignore Return Code Retrieve full return
  • Put an if…then or switch after each call

This is obvious achievable, but with more complex flows where we have a longer sequence of nodes

  • Complicates the flow
  • Makes it harder to use sub-flows to capture common mini-sequences

I’m sure that this is mainly lack of knowledge/experience on my part, and I’m missing some key piece, but if you have any advice, I’d be grateful.

Example flows.

There are two flows here

  • Sub-Flow - simply mimicks a 3rd party system – returning a success or failure code depending on the input.
  • Main Flow uses a GET webhook, and calls the sub-flow. It expects a parameter “code” as an integer e.g from curl
    successful call- curl http://localhost:5678/webhook/tester1?code=200

Error processing call 1 - curl http://localhost:5678/webhook/tester1?code=400

Error processing call 2 – curl http://localhost:5678/webhook/tester1

Sub-Flow

Main Flow

2

Hi Nick,
I suggest to use “Continue On Fail” on the settings of the “HTTP Request” node. Then, use a “IF” node to check if the content of the output of “HTTP Request” node is compliant, if not go to a dedicated node “Respond to Webhook” to response.

3

Hi @NickW, welcome to the community! The Error Trigger would typically live in a separate workflow, running whenever another workflow hits an error. It starts a separate execution without the data from the previous (Webhook-triggered) execution.

So when your error-triggered workflow execution hits the Respond to Webhook node it would behave as described in the respective documentation:

If a Respond to Webhook node is executed but there was no webhook, the Respond to Webhook node is ignored.

You can also find a more in-depth explanation on error workflows in our blog post Creating error workflows in n8n – n8n Blog.

  • On each HTTP request, set Ignore Return Code Retrieve full return
  • Put an if…then or switch after each call

Yes, if you want to handle each error individually this would be the way to go.

If you only want to return a custom error message/code in case anything at all went wrong during the execution, you could also consider executing your HTTP Requests in a sub workflow (which you can call from the main workflow through the Execute Workflow node with the Continue On Fail setting enabled).

Then you’d only need a single IF node after your Execute Workflow node to check whether success or error data has been returned. For example like so:

image
image829×407 21.2 KB

Example Workflow
4

Many thanks @MutedJam for the detailed response.

I think the use of the sub-flow provides the best option for now. I’ll experiment further and raise questions separately. I’m wondering if there’ll be a performance hit from instantiating another flow, so I’ll need to run some checks.

Point taken on the comment that " The Error Trigger would typically live in a separate workflow…" - I was going by the documentation statement that “If a workflow is using the Error Trigger node, by default, the workflow will use itself as the Error Workflow”. So it was worth trying to see if adding one of these allowed a single point to catch errors and return the webhook response. Alas… :slight_smile:

Many thanks for the info!

Cheers,
Nick

5

Glad to hear this is a suitable option for now and thanks so much for your feedback on this :slight_smile: