> For the complete documentation index, see [llms.txt](https://developers.make.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developers.make.com/custom-apps-documentation/component-blocks/api/handling-responses/error.md). # Error **Required**: no\ **Default**: Make shows a default error type and message based on the HTTP status The `response.error` directive specifies the error type and the error message to show the user. Make identifies any HTTP status in the range 400 - 599 as an error. You can specify different error messages based on different status codes. The error object has the following attributes:
PropertyTypeDescription
messageIML stringAn expression that parses an error message from the response body or a header.
typeIML stringAn expression that specifies the error type.
<status code>Error specificationAn object that customizes the error message and type based on the status code.
See [error handling](/custom-apps-documentation/app-components/base/error-handling.md) for more details. ## Properties ### message **Required**: no The `response.error.message` directive specifies the message that the error will contain. It can be a statically specified string, or it can point to a message in a response body or header. When the `response.error` or `response.error.message` directive is not specified, Make shows a default message based on the response HTTP status: * HTTP status 429: `Third party API limit likely exceeded` * HTTP status 500 - 599: `Service is temporarily unavailable.` * All other 4xx statuses: `Status Code Error: XXX`, where `XXX` is the returned HTTP status code ### type **Required**: no\ **Default**: varies based on the response HTTP status The `response.error.type` directive specifies a type of error message. Different error types are handled differently by Make. When you don't specify the type, the default error type depends on the response HTTP status: * HTTP status 400 - 428: `RuntimeError` * HTTP status 429: `RateLimitError` * HTTP status 430 - 499: `RuntimeError` * HTTP status 500 - 599: `ConnectionError` See [error handling](/custom-apps-documentation/app-components/base/error-handling.md) for more details. ### \ **Required**: no You can specify custom errors for different status codes by specifying the status code as the key in the `response.error` directive object and using the same error specification as a value. {% hint style="warning" %} A specific `response.error.` directive for an HTTP status in the 200 - 399 range only takes effect when the response has already been marked as an error by the [`valid`](/custom-apps-documentation/component-blocks/api/handling-responses/valid.md) directive. Because a status below 400 is treated as success by default, the `response.error` directive alone never fires for it — you cannot use a `200` - `399` status-code error here. Use directive [`valid`](/custom-apps-documentation/component-blocks/api/handling-responses/valid.md) instead to mark a response as an error when the status is below 400. {% endhint %} ## Error types The value of the `response.error.type` directive (or a per-`` `type`) defines the output error type. The type determines how Make handles the error in a scenario. The types most relevant to app development are: | Error type | Behavior in a scenario | | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `RuntimeError` (default) / `UnknownError` | Primary error type (`UnknownError` is a fallback for untyped or non-error failures and behaves the same way). Execution is interrupted and rolled back. The scenario is **not** deactivated immediately — it is turned off only after the number of consecutive errors reaches the scenario's error limit (3 by default). | | `DataError` / `DuplicateDataError` | Incoming data is invalid (`DataError`) or a duplicate (`DuplicateDataError`); both are handled the same way. If "Store incomplete executions" are enabled, the bundle is stored as an incomplete execution so the user can repair the data and resume, and the scenario is not interrupted. If "Store incomplete executions" are **not** enabled, the bundle is not stored and the error behaves like a `RuntimeError` — execution is interrupted and rolled back, counting toward consecutive errors. | | `RateLimitError` | Rate-limit related error. The scenario is suspended for a delay (by default about 20 minutes) and then resumed, instead of the error counting toward consecutive errors. | | `ConnectionError` | Connection-related problem. Applies a backoff delay and retries on a subsequent run. If the connection keeps failing after all reconnect attempts, the scenario is deactivated. | | `InvalidConfigurationError` | Configuration-related problem. Deactivates the scenario and notifies the user. | | `InvalidAccessTokenError` | Access token-related problem. Deactivates the scenario and notifies the user. | | `IncompleteDataError` | Incoming data is incomplete. Unlike `DataError`, the bundle is **not** stored as an incomplete execution. When raised from an app (where no retry delay can be set), the scenario module execution is interrupted, the scenario is turned off, and the user is notified. | | `UnexpectedError` | Unexpected internal failure. Deactivates the scenario immediately (after the first occurrence) and notifies the user. | Make also defines additional internal error types that are not intended for use in apps. For the full list and a detailed description of how each type behaves, see [Fix errors and warnings](https://help.make.com/fix-errors-and-warnings) in our Help Center. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://developers.make.com/custom-apps-documentation/component-blocks/api/handling-responses/error.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.