Skip to content
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,112 @@
---
title: Custom error messages
description: Learn how to define custom error messages for input validation in your Actor's input schema. Make validation feedback clearer and more user-friendly.
slug: /actors/development/actor-definition/input-schema/custom-error-messages
---

**Learn how to define custom error messages for input validation in your Actor's input schema. Make validation feedback clearer and more user-friendly.**

---

When an input fails validation against an Actor's input schema, the resulting errors are processed and displayed to the user. By default, these messages are generic and may not clearly convey the specific semantic meaning behind validation rules.

Custom error messages allow Actor developers to define tailored feedback messages for input validation errors, making it easier for users to understand what is required and improving overall usability.

## The problem with generic error messages

Some validation rules defined by Actor developers carry specific semantic meaning that cannot be clearly conveyed by generic error messages.

For example, consider the following input field using the `pattern` validation keyword:

```json
{
"title": "Email address",
"type": "string",
"description": "Your email address",
"editor": "textfield",
"pattern": "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$"
}
```

Input that don't satisfy the pattern, will produce an error message like:

```text
Field "email" should match pattern "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$".
```

However, a message such as the following would be much more understandable for the user:

```text
Field "email" must be a valid email address.
```

## Using the `errorMessage` keyword

Each property in the [input schema](./index.md) can include an `errorMessage` field that defines custom error messages to be displayed when validation of that field fails.

The `errorMessage` must be an object that maps *validation keywords* (e.g., `type`, `pattern`, `minLength`) to their respective custom messages.

```json title="Email input with custom error messages"
{
"title": "Email address",
"type": "string",
"description": "Your email address",
"editor": "textfield",
"pattern": "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$",
"errorMessage": {
"type": "Email must be a string",
"pattern": "Email must be a valid email address"
}
}
```

If a validation error occurs for a keyword that is not listed in the `errorMessage` object, the system will fall back to the default error message.

::::note
Custom error messages are especially useful for complex validation rules like regular expressions, where the default error message would show the entire pattern, which is not user-friendly. See [best practices](#best-practices) for more guidance.
::::

### Supported validation keywords

You can define custom error messages for any validation keyword supported by the [input schema](./index.md), including:

| Type | Supported validation keywords |
|--------------------|-----------------------------------------------------------------------------|
| `string` | `type`, `pattern`, `minLength`, `maxLength`, `enum` |
| `number`/`integer` | `type`, `minimum`, `maximum` |
| `boolean` | `type` |
| `array` | `type`, `minItems`, `maxItems`, `uniqueItems`, `patternKey`, `patternValue` |
| `object` | `type`, `minProperties`, `maxProperties`, `patternKey`, `patternValue` |

#### Nested properties

It's possible to define custom error messages in sub-properties as well. For objects with nested properties, you can define error messages at any level of nesting:

```json
{
"title": "User",
"type": "object",
"description": "Provide user details",
"editor": "schemaBased",
"properties": {
"email": {
"type": "string",
"pattern": "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$",
"errorMessage": {
"pattern": "Please enter a valid email address"
}
}
}
}
```

## Best practices

While custom error messages can improve the user experience by providing clearer guidance, it's generally better to rely on the default error messages unless there's a specific need for customization. Only use custom error messages when they significantly help users understand the requirements better than the default messages.

If you do decide to use custom error messages, follow these best practices:

1. **Be specific** - Clearly explain what is required or what went wrong
2. **Be concise** - Keep messages short and to the point
3. **Be helpful** - Provide guidance on how to fix the issue
4. **Be consistent** - Use a similar tone and style across all messages
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure about this entire section. Do we want to be the source of information about how to write error messages? @TC-MO

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question tbh. It feels like this is better suited for Academy then our Platform docs, let me think a bit on that. Apart from that:

  1. Bold is for UI elements. (at least for now), so it should be either italics, or no emphasis whatsoever.
  2. Ordered lists should be done with all 1. since Docusaurus can handle then the numbering while rendering the page and maintenance is much easier

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's remove this part, platform docs shouldn't be source of info on such generic thing as to how create custom error messages

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to keep at least this part:

While custom error messages can improve the user experience by providing clearer guidance, it's generally better to rely on the default error messages unless there's a specific need for customization. Only use custom error messages when they significantly help users understand the requirements better than the default messages.

We want to avoid users applying custom messages where it won't make sense and will worsen UX

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that would be okay

Original file line number Diff line number Diff line change
Expand Up @@ -78,4 +78,4 @@ The actual input object passed from the autogenerated input UI to the Actor then
}
```

Next, let's take a look at [input schema specification](./specification.md), and the possibility of using input schema to enable users to pass [secrets](./secret_input.md).
Next, let's take a look at [input schema specification](./specification.md), the possibility of using input schema to enable users to pass [secrets](./secret_input.md), and how to define [custom error messages](./custom_error_messages.md) for input validation.
Original file line number Diff line number Diff line change
Expand Up @@ -130,6 +130,7 @@ Each field of your input is described under its key in the `inputSchema.properti
| `default` | Must match `type` property. | No | Default value that will be <br/>used when no value is provided. |
| `prefill` | Must match `type` property. | No | Value that will be prefilled <br/>in the Actor input interface. |
| `example` | Must match `type` property. | No | Sample value of this field <br/>for the Actor to be displayed when <br/>Actor is published in Apify Store. |
| `errorMessage` | Object | No | Custom error messages for validation keywords. <br/>See [custom error messages](./custom_error_messages.md) <br/>for more details. |
| `sectionCaption` | String | No | If this property is set, <br/>then all fields following this field <br/>(this field included) will be separated <br/>into a collapsible section <br/>with the value set as its caption. <br/>The section ends at the last field <br/>or the next field which has the <br/> `sectionCaption` property set. |
| `sectionDescription` | String | No | If the `sectionCaption` property is set, <br/>then you can use this property to <br/>provide additional description to the section. <br/>The description will be visible right under <br/>the caption when the section is open. |

Expand Down
Loading