Error handling

Handling errors returned from HTTP API endpoints

Since any API endpoint can return an error during an execution of a scenario, Make provides methods to handle errors and keep scenarios reliable and functional.

All apps in Make should implement error handling to ensure that users understand the cause of any errors. Error handling should always be customized to the type of error and how the API returns the error.

Read more about error handling in the Help Center:

• Introduction to errors and warnings
• Overview of error handling
• Error handlers

When the service returns an HTTP error, it is not possible to evaluate it as a success.

Error handling: 401 error

Output from API

Error in Make DevTool

Without error handling

Error with no detail message

With error handling

Error with a detail message

With error handling, details of the error are available and the user will know how to solve the problem.

Code

{
    // ...
    "response": {
        "error": {
            "message": "[{{statusCode}}] {{body.error}}"
        }
    },
    // ...
}

How Make treats HTTP statuses

Make treats any response with an HTTP status in the range 400 - 599 as an error and assigns a sensible default error type and message based on that status — a rate-limit response is retried automatically, a server error is treated as a temporary connection problem, and other client errors stop the execution. In most cases you don't need to handle these statuses manually; add the error directive only when you want to show a clearer, service-specific message or override the default type.

For the exact status-to-type and status-to-message mapping and the directive syntax, see the error directive reference.

Errors returned with a 2xx or 3xx status

Some APIs signal an error with a 2xx/3xx status code (usually 200) and a flag in the response body. Because a status below 400 is treated as success by default, use the valid directive to mark the response as invalid and raise an error.

For the full valid behavior — message and type resolution priority and fallbacks — see the valid directive reference.

Error types

When you raise an error you can choose its type with the response.error.type directive. The type controls how a scenario reacts to the failure: some types interrupt and roll back the execution, while others let the scenario retry automatically or store the state so the user can repair the data and resume. Picking the type that matches the real cause is what lets a scenario recover gracefully instead of being disabled.

For the full list of types and how each one behaves, see the Error types section of the error directive reference.