Error handling

Since any API endpoint can return an error during an execution of a scenario, Make brought a way, how to handle such errors. Therefore, all apps in Make, custom included, should have error handling implemented. This way, the modules are more transparent as users of them exactly know, what caused the error. Also, error handling in a scenario can be used.

Read more about error handling in Make:

• Introduction to error handling

• Directives for error handling

• Advanced error handling

Error handling should always be designed accordingly to the way, how API returns the error. You can always check the Integromat DevTool or Console and see the structure of the error.

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

Example of error handling

Output from API

Error in Integromat DevTool

Without error hanling

Error with no detail message

With error handling

Error with a detail message

Notice, that the wording of the error is now available. Thanks to this, you know where is an error and how to solve/handle it.

Code

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

HTTP 4** and 5** error handling

When the response is returned with 4** or 5** HTTP Status Code, this is automatically considered an error. If the error directive is not specified, the user will see a message for the status code that was returned (List of HTTP status codes). But you are able to customize the message, shown to the user with the error or error.message directive.

Example:

{
    "response": {
        "error": {
            "type": "RuntimeError",
            "message": "[{{statusCode}}] {{body.error.message}}",
            "400": {
                "type": "DataError",
                "message": "[{{statusCode}}] {{body.error.message}}"
            },
            "500": {
                "type": "ConnectionError",
                "message": "[{{statusCode}}] {{body.error.message}}"
            }
        }
    }
}

HTTP 2** and 3** error handling

Some APIs signal an error with a 200 status code and a flag in the body. For this scenario, there is the validdirective, which tells whether the response is #valid or not.

{
    "response": {
            "valid": {
                "condition": "{{body.status != 'error'}}"
            },
            "error": {
                "200": {
                    "message": "{{ifempty(errors(body.message), body.message)}}"
                },
                "message": "[{{statusCode}}]: {{body.reason}}"
            }
        }
}

Custom error handling based on status codes

You are also able to further customize what error message will be shown to the user based on the status code. To do that, just add your status code to the error directive and fill it in as one:

{
    "response": {
        "error": {
            "message": "Generic error message",
            "400": {
                "message": "Your request was invalid"
            },
            "500": {
                "message": "The server was not able to handle your request"
            }
        }
    }
}

Available error types in apps

When handling an error, you can specify the type of the error:

• UnknownError

• RuntimeError (default)

  • Primary error type. Execution is interrupted and rolled back.

• InconsistencyError

• DataError

  • Incoming data is invalid. If incomplete executions are enabled, execution is interrupted and the state is stored. The user is able to repair the data and resume execution.

• RateLimitError

  • Service responded with rate-limit related error. Applies delay to the next execution of a scenario.

• OutOfSpaceError

  • The user is out of space.

• ConnectionError

  • Connection-related problem. Applies delay to the next execution of a scenario.

• InvalidConfigurationError

  • Configuration-related problem. Deactivates the scenario and notifies the user.

• InvalidAccessTokenError

  • Access token-related problem. Deactivates the scenario and notifies the user.

• UnexpectedError

• MaxResultsExceededError

• IncompleteDataError

  • Incoming data is incomplete.

• DuplicateDataError

  • Reports error as warning does not interrupt execution. If incomplete executions are enabled, execution is interrupted and the state is stored. The user is able to repair the data and resume execution.

Example of error handling with type

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