make.com webhook responses redirect the user or return an error
From our system, which is called using an http module, how can I return errors to make so that they shows up in one of the available error handling data items.
What would need to be returned so that instead of showing a generic 400 error, I can for example, return (for example): “Error Logging in, please restart”
Currently I return this as body and it shows on a relatively empty webpage, which is fine for now.
When you make the HTTP call from Make, you can keep the default behavior, which consists of not throwing an error when the called endpoint returns 400, 500, etc… and in that case you can have a router after the HTTP module, and filter the HTTP code returned.
If it’s a 400, you can get the payload of the response from your server and pass the information using the Webhook response.
If you configure the HTTP module to capture errors, you can still use a error handler (with an Ignore module), and add a webhook response before the Ignore. But I’m not 100% sure you can get any payload from the HTTP call in that case; it has to be tested.
My question is if it’s possible, when using error handlers, to capture the error response payload.
Because right now, I end up taking most of what I build to postman which gives me real error feedback making it much easier to build. Then I have to spend more time fitting that to make. Which is often the much harder step, despite being a “low code”.
Frankly it’s silly that after nearly a decade of using make, this is still unclear.
(I hope that the silliness is on me for not having learned it, rather than it doesn’t exist.)
I end up doing a lot of extra work as a result of not making basic error messages available, which is kind of like developing 101.
So I’m holding out hope that someone, somewhere, understands the importance of error messages, and built that in already, and I just don’t know how to use it yet.
Otherwise, it’s mind blowing that this wouldn’t be the top of every product backlog and feature request list.
Because “How can I get debugging information” is the first question any dev is going to ask.
To build a product that doesn’t provide this, or to rely on a very janky dev plugin that runs slow as molasses, hasn’t been updated in years, and needs several reloads before it works, shouldn’t be enough for anyone building anything serious.
I’m sorry I see your reply only now.
I agree with you, error messages are really important and should be clearly displayed.
One way to do it is to use the « Integromat Dev Tool », this chrome extension gives more details about calls and responses; from here you can see the raw error response (payload, headers).
Besides, if every you use an Error Handler, you get a new data structure you can leverage in the error handling steps (error code and error message).
Because the actual error message I return does not map to the make.com error fields.
So then this is my original question, in what structure do I have to return errors for them to be output in this field?
This is a typical error response.
The 400 should be in the status, and the message, should be the one I returned via error.message, correct?
because the current one is the stock make message that does not provide useful info.
I’m aware of that plugin, it’s exactly the one I mentioned:
That plugin always requires I reload the editor, which already isn’t the fastest thing often, but then it becomes much slower, and works 1/3 to 1/4 of the times I load it, otherwise showing extercomm can't be loaded
For all the benefit of this feature, and all the pains not having it causes, I’m shocked that the has never prioritized something like this. Considering it works for other modules, it can’t be a 40 hour item can it?
Anyways. IMO, and in my experience with devs, as long as basic error messages don’t work from http modules, make.com is kind of shooting it’s own credibility, dev-wise, in the foot.
Also, every time I write to support about the extension, i get a series of stock boomerang responses every several days, meaning after a week, we are still at try reloading at which point I give up and consider other platforms for that project.
I almost always start with make.com but I have to say that due to these 2 reasons, I often end up bringing the project elsewhere.
And these are situations where make.com is well suited technically, but not as a dev environment.
Here, type and message can be used (I made SF Create a Record fail)
But it’s true we don’t always get everything, especially with the HTTP module.
You are the first person that tells me the Integromat Dev Tool is slow and fails to load unless you refresh your screen. Not that I don’t believe you, but it usually works fine in Chrome. Is it possible there’s another extension that interacts with it?
It’s just annoying that if fails on your side because it can be super helpful to understand what happened under the hood.
I suppose I will try it that way, though I can’t help but wonder, how much challenge could it be to simply add better error handling to the most generic and useful module you guys have (IMO)?
It really is one of the two key areas where I find make limits me compared to other tools, which translates to me wanting to work elsewhere.
This is definitely something that we’ll push internally. Thanks for your feedback! Don’t hesitate to DM me if you have other things Make could improve.
