Skip to content

Updating visuals

If you see any images containing outdated UI, please bear with us.

We are updating all content as quickly as possible to mirror our new UI.

Try/Catch

The Try/Catch action allows you to handle errors gracefully in your workflows. Instead of stopping the entire workflow when an error occurs (like a failed API call), you can define a specific Catch path to handle the situation—for example, by returning an error response to the caller or logging the error for debugging.

How it works

This action works by creating a special block with up to two distinct branches:

1
Try
This is where you put your main actions. The workflow will attempt to execute these actions first.
2
Catch
If any action in the `Try` branch fails (throws an error), the workflow immediately stops the `Try` branch and jumps to this `Catch` branch. This is where you handle the error.

How errors are triggered

The Catch branch executes when an error occurs in the Try branch. This happens in two ways:

  • Automatically — When an action fails (e.g., an API request returns an error, a database query fails).

  • Manually — When you use the Throw Error action. This allows you to stop execution and handle logic errors (like invalid inputs or failed validation).

The Error Object

When an error is caught, the Try/Catch action exposes a caughtError object that contains details about what went wrong. You can access the values of the error in the binding panel in the lightning bolt tab.

The object contains the following properties:

PropertyTypeDescription
messageStringA readable description of the error (e.g., "Network Error" or "Email is required").
nameStringThe name/type of the error.
causeString/ObjectAdditional technical details or the underlying cause of the error (if available).

When using the Throw error action, you are able to manually define the message and cause that gets passed.

You can bind these values to other actions in your Catch block. For example, you can bind a Send response action’s message to caughtError.message to return a clear error to the API Endpoint caller.

Advanced Patterns

Using with "Throw Error"

The Throw Error action is the perfect companion to Try/Catch. While system errors (like a failed API request) trigger the Catch block automatically, you can also trigger it manually using Throw Error.

Here is an example use case with logical validation:

Try

1
Validate Input
Use a True/False split action to check if the inputs are valid.
2
Throw Error
Inside the True branch (input is invalid), add a Throw Error action with the message 'Inputs are invalid'.
3
API Request
Call your external API using HTTP request. If this fails (e.g. network error), it will automatically trigger the Catch branch.
4
Success Path
Continue with normal logic (e.g. update a table, send a success response).

Catch

1
Handle Error
Use a Send response action. Bind the message to caughtError.message to return the specific error (whether it was the API failing or the 'Invalid inputs' check) back to the caller.

In this flow, both an automatic error AND a manual Throw error action are handled by the same Catch block.

Re-throwing Errors

Sometimes you may want to handle an error (for example, log it) but also stop the workflow so it does not continue.

1
Try
Execute an action that might fail.
2
Catch
Log the error for debugging.
3
Re-throw
Add a Throw Error action at the end of the Catch branch. This ensures the parent workflow knows the operation failed and would cause it to error, resulting in it not continuing.

CONTINUE LEARNING

Learn how to call your API Endpoints from the interface.

Calling API Endpoints from the interface →