hello
I do an API call to Stripe to check if a customer id exists (using Retrieve a Customer).
If there is an error “No customer found”, I must perform some actions to fix it. But with an error, the workflow stops.
How could we catch errors in the API Workflows ? how can I trigger another worflow only if an error occurs ?
If we can’t, @emmanuel do you plan to let us deal with Errors ? Once configured for an API, all the Errors responses are formatted the same way, whatever the call we make.
It would be great if there will be a possibility to check a checkbox that will not throw errors. In this case, we’ll be able to get the errors from the previous steps.
That means an action’s script should be wrapped into the following:
try { code }
catch (e) { return { error: e.message } }
That’s a good idea @emmanuel
For instance, if the “id”'s value is empty, obviously, there is an error.
Hi @nicolas_dap
At the moment our option is to install a ‘timeout’ (scheduled wf) in order to validate if the operation was successful. In other words, if the validation operation takes 10 seconds, a scheduler at 30 seconds is executed to check if the operation has written the data correctly.
I haven’t delved too deeply into error handling as yet, so I’m curious about this as well, for future reference. Does the An unhandled error occurs event not fire for API calls?
I have created a ticket last week for this reason. They tell me that actually there’s no way to handle error. You cannot also set another step to see if an empty (example ID) on further step of the workflow because the workflow stop on the error. No timeline on a fix for that.
The only workaround I found is like @JohnMark Say.
@JohnMark @Jici Thanks for the feedback.
That’s a pretty big, and not that reliable, workaround.
Anyway, hopefully that will come someday.
Can someone help me understand this issue a bit better? Is this referring specifically to SCHEDULED API workflows?
Ok, I think I understand the issue now. This thread from 2.5 years ago seems to be about the same thing.
While far from ideal, until the issue is officially addressed by Bubble, another approach might be to implement a “proxy relay” endpoint - i.e. a “middleman” endpoint which sits between Bubble and the “true” endpoint (Stripe in this case). For certain “critical” API workflows, it might be worth the effort.
I fiddled around and was able to implement a no-code solution to fetch a customer from Stripe with error handling using Integromat for the proxy endpoint…
It all works as intended. When the Bubble endpoint is hit, a new entry appears in the DB if a Stripe customer is found; and I get an email if Stripe returns a “No customer found” error.
Anyway, I can share more detail if interested, but I thought I’d pass it along.
This is the approach I currently use!
A quick follow-up… It’d probably be best to create a separate custom event for the “Send email” instead of just an action. That way, the error handling logic resides in its own workflow (for better app organization and SOC).
Don’t even know if Bubble read this. If they do, how could we know ? If they don’t, does it worth going on reporting our user cases ?
I know it’s been brought up (many times) before, but it would sure be nice to see an official “roadmap”, or at least a list of requested features, and better yet, to be able to influence priority by upvoting. Unfortunately, Bubble doesn’t seem transparent in that regard. 
(The forums are great for discussion, but I don’t even know how to formally submit a feature request - only bug reports.)
I’m not sure there is a formal way to request a feature besides the forum post topic of “idea”…they when implemented label it as so.
There is also a running list on the forum of feature requests
Although it is not “official” as Bubble didn’t start it.
Yeah, I inquired about this, specifically, just yesterday. Here’s a synopsis of the exchange with Bubble Support…
So, maybe if we inundate support, directly, with requests for a proper “feature/issue tracker”, they might take some action. 
I know in the past they offered the option for users to fund the feature and pay for it to get done…not sure if they still do that or not
A bit of thread archaeology here 
Genius on getting Integromat to do the job.
What I think this lets me do is be able to get the HTML response back as something that the workflow can handle?
If I then pass that back to the caller of by Bubble API - I am thinking it will always result in a “real” 200 but the response (404, 422, 200 etc) would be in a returned parameter?
I don’t think I can specify the return code via the workflow?
I had to refresh my memory, but it appears you can specify the return code in Integromat. I opted to return a 200 to Bubble and simply send back a custom string called “error” as the Stripe customer id; but it appears the original error code could indeed be sent back to Bubble as a param. Here’s how I set up the webhook response in Integromat for my quick test…
I haven’t tried, but It appears one could also relay the original HTTP response code back to Bubble as the “Status”.
Thanks
Yes, that works and you can send it back as a parameter too to do “stuff” in the workflow if you need.
Bubble moans if you have multiple “Return API” steps, so you can’t get too fancy.
A 200 and something in the JSON about the error is what I ended up with.
Integromat handles if all very well.
