Forum Documentation Showcase Pricing Learn more

Error Handling in API Workflows


#1

Hello Bubblers,

Is there an option to catch and handle errors in an API Workflow? I am using error handling for elements and page-wide error handling, but I don’t see any option to handle errors in an API Workflow.

If an error occurs right now, it seems there’s a very generic response delivered to the user. Worse yet, some of my API Workflows are actually calling OTHER APIs (through API Connector), and if those APIs die, some very ugly error messages are passing through to the user - all very unpredictable.

I’d like to be able to catch errors in an API Workflow and handle them gracefully - hoping some of you have ideas or a solution! Thanks!!

Eric


#2

I’ve been thinking about this too, and will likely settle on a combination of an audit trail, keep track of state, and a “dead man switch”, i.e. notification from timeout from certain states.


#3

To handling error in the API, I added a Log table in my app to know more what is going on :

1/ Create a new Log when the endpoint is triggered, with Error = True

2/ Modify it if the workflow succeeds (in my case, only if the PDF is well generated)


#4

@emmanuel - Any thoughts on whether this is possible? I’ve only seen a limited number of threads talking about it (back in September of last year). Some APIs provide meaningful responses through the use of error codes, and even for those that do not, the existence of the error is something that would be useful to gracefully handle in Bubble.

Is there a mechanism or technique I’m missing to handle API Connector errors, or if not, is there a plan to provide support for error handling? Right now, the workflow will just cease to continue… or worse yet, if the API Connector is called from within a Bubble API Workflow, a very ugly response will be returned/passed to the Bubble API Client/User.

It would be great to be able to trigger a workflow to handle API Connector errors.


#5

It’s certainly possible, but not a smaller project. If it’s critical we can talk about sponsoring, otherwise we’ll put this on our wish list (but without a timeline).


#6

@emmanuel - thanks for the quick reply. I suppose I can determine how critical it is given a sponsorship price. :slight_smile:

Would you mind shooting me an estimate?


#7

Sorry I should have mentioned in a few weeks. Can your reach out to support in 2/3 weeks?

Thanks


#8

Bumping thread. Is there yet a graceful way to handle external API errors? Would love an option to simply “ignore error” from an external API if/when it occurs. Bubble is flexible enough to allow forking a workflow using When clauses on downstream steps so I can work around errors in terms of data operations, but I just can’t hide certain API errors themselves from users, which kinda sucks.

Any options here? Any hacks anyone can think of to ping an API silently (based on user input) to make sure it works before running it in a user-facing way? I can’t think of anything.

Thank you!

-Ed


#9

Running into this issue as well. I am trying to check a session token before performing an API call. However the check session either returns true if the session token is ok or an error if it is expired, which I would like to use to request a new token.


#10

Bumping this as well. I have a page that needs to execute another workflow if an API POST action fails.

I attempted to use the workflow element “When an unhandled error occurs” to trigger a redirect, but Bubble doesn’t seem to initiate the Unhandled Error workflow when an API POST action fails and terminates the workflow it sits inside of.


#11

Same problem for me, I need to handle correctly errors from several APIs to implement very basic user experience. For example, if a user signs up with the Facebook API, but comes later logging in (or signing up again) with the Google API, the user is told that the username is already used with a popup… If we could do something in the Workflow when the error occurs, I could improve the user experience a LOT!


#12

This is a really important feature. The API I’m calling doesn’t have an error response. Instead it just fails. So I need to handle the scenario that the service is unavailable.


#13

Bumping this as well. It’s really important so you can at least show an error message to the user.


#14

+1 I am just getting started with bubble and I thought it’s me not being able to find this, cannot believe that this feature is missing! proper error handling in API calls is extremely important if we’re expected to do something more than just a “hubby-playing-around” projects on bubble platform.

@nicolas_dap solution works, however you’re stuck with multiple dependencies specially on a cases when you reply on error codes. The “Initiate Call” action in API connector plugin should have something like “Initiate Error” where you can fetch and parse error.


#15

I agree ! Errors are sometimes as import as sucess responses


#16

Hey I would love to know if you guys have this in your plans, @emmanuel I see messages from back in Sep that the proper error handling is in the list but “not imminent”; if there’s a workaround or a hacky solution, I’d love to at least a quick guide which we can use to refer to. a little bit of transparency will help us understand the situation better and appreciate the platform.


#17

Bumping this to see if there have been any changes regarding this issue.


#18

Re-iterating on this subject. Error handling is key to any proper development and is really missing in Bubble. This is becoming more and more urgent for my needs.


#19

I don’t quite get why this has been hard for Bubble to implement. Everything else in Bubble seems very very Node-like.

Most (many?) APIs will do exactly what’s expected in node: return data if success, return error object if error.

If you’re writing your own APIs for use with Bubble, the workaround is to make your success objects include an error key that you populate with something like the error message on error.

(All that works great, but of course Bubble should have a built in error object tied to API data and action calls that one can simply test.)

Anyway, for cases where it’s essential for an error to “bubble” up to the user level, you basically have to shim your calls to external APIs in order to convert error objects into something Bubble can deal with. It’s more work than it should be, but seems like enhancements to API Connector are lower priority than a bunch of other things…


#20

I am looking for this as well. It’s really clunky to have JSON errors popping up for users and there seems to be no way (without hacking it together) to display meaningful error messages to the user.