> For the complete documentation index, see [llms.txt](https://api-docs.intratool.help/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://api-docs.intratool.help/introduction/validation.md).

# Validation

Shared input rules apply wherever a resource's Request Keys table or validation type references them. The resource contract defines whether a value is required, nullable, unique, or subject to additional constraints; a shared format does not change those requirements.

## Email Addresses

An email value must contain one mailbox address using ASCII characters, valid mailbox syntax, and no more than 254 characters. Internationalized domains must already be encoded as Punycode. Unicode characters in the local part are not supported.

Whitespace, control characters, quoted local parts, comments, address literals, backslashes, and display names are rejected. A single-address field does not accept multiple addresses separated by commas. The email validator does not trim or rewrite an address to make it valid.

| Value                         | Result                                  |
| ----------------------------- | --------------------------------------- |
| `first.last+tag@example.test` | Accepted syntax.                        |
| `user@xn--bcher-kva.test`     | Accepted Punycode domain.               |
| `user@bücher.test`            | Rejected Unicode domain.                |
| `user name@example.test`      | Rejected whitespace within the address. |
| `Name <user@example.test>`    | Rejected display-name format.           |
| `user@[127.0.0.1]`            | Rejected address literal.               |

These rules validate the address format; they do not establish that the mailbox exists or can receive mail. A nullable field can accept `null` according to its endpoint contract. An update's treatment of `null` and omitted keys is documented on the affected resource.

## Email Lists

A field documented as a comma-separated email list accepts a string containing one or more addresses. Every address must satisfy the [Email Addresses](#email-addresses) rules. Whitespace around each comma-separated entry is ignored during validation, so `first@example.test, second@example.test` is valid.

Empty entries are rejected, including leading commas, trailing commas, consecutive commas, and entries containing only whitespace. For example, `first@example.test,,second@example.test` is invalid. The comma-separated list format is used by [recipient-select options](/api-reference/forms/form-field-types.md#form-field-type-recipient-select).

An endpoint that declares an array of email addresses uses one mailbox per array element instead. For example, the [Form](/api-reference/forms/forms.md) `recipient` field accepts `["first@example.test", "second@example.test"]`; a comma-separated list inside one element is invalid.

## Phone Numbers

Fields with the [phone validation](/api-reference/forms/form-field-validation-types.md#form-field-validation-type-phone) accept valid telephone numbers according to the applicable country numbering plan. Use international E.164 notation for API values: a leading `+`, the country calling code, and the number without spaces or parentheses, for example `+491701234567`.

National notation, such as `01701234567`, needs an appropriate country context during validation. The field's `default_country_code` preselects the editor's country; it does not supply country context for a bare API value. International notation identifies the country within the value itself.

The validation's configuration can further limit accepted numbers:

* `country_codes` restricts numbers to the configured countries. An omitted, null, or empty list applies no country restriction.
* `fixed_line` and `mobile` select the accepted number categories. When either flag is enabled, the number must match a selected category; when neither is enabled, no category restriction is applied.
* A number must be valid for its country and satisfy the configured restrictions. A valid format does not establish that the number is assigned to a person or reachable.

| Value                | Result with German mobile numbers allowed |
| -------------------- | ----------------------------------------- |
| `+491701234567`      | Accepted international number.            |
| `01701234567`        | Requires German country context.          |
| `not-a-phone-number` | Rejected.                                 |

The `phone` properties of [Users](/api-reference/users.md) and [Contacts](/api-reference/contact-lists/contacts.md) accept nullable strings. Configurable form, task, and additional-attribute fields apply these phone-number rules when the `phone` validation is attached. Required and nullable behavior follows the affected field's contract.

## Related Input Rules

[Attribute Set Keys](/introduction/additional-attributes.md#attribute-set-keys) define how sets are identified when values are assigned. [System Variables](/introduction/system-variables.md#rendered-templates) define separate syntax for rendered expressions and [key-only values](/introduction/system-variables.md#key-only-values).

[FormFieldValidationTypes](/api-reference/forms/form-field-validation-types.md) define the accepted configuration for field validations, including dates, numeric bounds, selections, files, and regular expressions. The same validation types apply to configurable form, task, and additional-attribute fields.

[Assignment and Targeting](/introduction/assignment-and-targeting.md) defines the rules for static and computed recipients. [Rich Text](/introduction/rich-text.md) defines the shared HTML format for formatted text.