RPC Error Handling in HTTP Node

It be awesome if

The HTTP Node had more customization for error handling RPC calls, whose error codes occur in the JSON response body, and not in the HTTP response status codes.

My use case

I make a LOT of HTTP requests to Fibery (because it doesn’t have/I haven’t built an n8n node for it yet). Fibery’s API uses an RPC-like syntax and schema, so it only returns HTTP errors for things like server errors, or rate limiting. For errors dealing with permissions or query syntax, a 200 HTTP code is returned (because the request is handled fine), but the JSON body itself lets you know an error has occurred (via { success: false, data: {…} })

So, in the error handling section of the HTTP Request node, it would be cool if you could say “under the condition where: response=JSON, key exists, and key=value, throw an error, or route through the error output”.

Right now, this can be accomplished through many, MANY if/then nodes, which is a pain.

Any resources to support this?

Are you willing to work on this?

Yup! Problem is, I am starting from zero. I mean, I have lots of development experience, but nothing regarding building n8n nodes, and with Fibery’s API being a bit different than most I’ve dealth with, I’m not sure what the best practices would be for turning it into a n8n node.

If anyone knows of an existing n8n service that uses a similar API, I’d love to browse the code for that node and see what I can learn.

Turns out, the Slack v2 API uses RPC-type calls, which is great. However, one of the things that makes Fibery’s API trickier is that requests can be batched, AND that requests and queries support recursive queries, so I’ll need to learn how to do that in n8n’s node syntax.