> 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/app-components/base/error-handling.md).
# Error handling
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.
{% hint style="info" %}
Read more about error handling in the Help Center:
* [Introduction to errors and warnings](https://help.make.com/introduction-to-errors-and-warnings)
* [Overview of error handling](https://help.make.com/overview-of-error-handling)
* [Error handlers](https://help.make.com/error-handlers)
{% endhint %}
{% hint style="warning" %}
When the service returns an HTTP error, it is not possible to evaluate it as a success.
{% endhint %}
## Error handling: 401 error
{% tabs %}
{% tab title="Output from API" %}
{% hint style="info" %}
With error handling, details of the error are available and the user will know how to solve the problem.
{% endhint %}
{% endtab %}
{% tab title="Code" %}
```json
{
// ...
"response": {
"error": {
"message": "[{{statusCode}}] {{body.error}}"
}
},
// ...
}
```
{% endtab %}
{% endtabs %}
## 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`](/custom-apps-documentation/component-blocks/api/handling-responses/error.md) 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`](/custom-apps-documentation/component-blocks/api/handling-responses/valid.md) 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`](/custom-apps-documentation/component-blocks/api/handling-responses/valid.md) 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](/custom-apps-documentation/component-blocks/api/handling-responses/error.md#error-types) section of the `error` directive reference.
---
# 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, and the optional `goal` query parameter:
```
GET https://developers.make.com/custom-apps-documentation/app-components/base/error-handling.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.