Field validation

Validation ensures that data collected in forms and structures is correct, usable, and consistent. It helps prevent invalid inputs from being stored in the system and allows you to enforce business rules on top of basic field constraints.

Apart from the basic validation enforced by field type, you can use additional validation methods ranging from simple rules to advanced external services.

What validation applies to

Two rules cover every case:

• Required decides whether the field may be left empty.
• Everything else runs only on a field that has a value. An empty optional field is not checked at all, so a regex or a validation scenario never turns an optional field into a required one.

This is the same whether the lead comes from a form, an embeddable form, or the API. A partner sending leads over the API is held to the same rules as a visitor filling in the form.

Basic validation

Some field types enforce a minimal level of validation:

• Number – only digits are allowed, leading zeros are removed.
• Phone – must be entered as a valid number with prefix.
• Email – must contain a valid email pattern.
• Date – must follow a valid date format.
• Checkbox – must be true or false.
• Select and Radio Button – must be one of the values defined on the field.

These checks belong to the field type, so there is nothing to configure. See Field types.

Regex validation

You can configure regex validation rules to enforce custom patterns (e.g. a national identifier, a licence plate). You can describe the intended rule to AI to generate the regex, and then test it on multiple values using a tool such as regex101.com.

A regex is the right tool when the rule is about the shape of the value and nothing else. If the rule needs to look the value up somewhere, use a validation scenario instead.

External validation through Connection Creator

You can use the Connection Creator to call an external service for validation. Typical examples include:

• Checking whether a phone number or email actually exists.
• Verifying a company ID against an official database.
• Bank account to validate bank account numbers against banking standards.
• Personal ID check to validate identifiers against checksum algorithms or national registries.
• Domain check to validate that a domain exists, has active DNS records, or belongs to a specific organization.

Many other validation scenarios can be implemented this way.

How a validation scenario works

The scenario is built in the Connection Creator, where it calls the service and decides what the answer means. What it hands back to the field is one of two results: the value is accepted, or the value is rejected and the visitor is asked to correct it.

Build a branch for every answer the service can give, including the one where it does not answer at all.

Handle the outage

This is the branch people leave out, and it is the one that costs money.

If the service is down and nothing in the scenario handles that, the field is never accepted and nobody can submit the form. An outage at the provider becomes an outage at your offer.

Send that case to an accepted result instead. The value was not verified, but the lead is still collected. You lose one check for as long as the provider is down. Without it you lose every lead in that time.

Decide this per field. A check that exists to keep data tidy should always fall back to accepted. A check that decides whether you may take the lead at all is the rare case where blocking is right, and even then you want to know how long you would be blocked for.

Validation can also record what it found

A scenario can write a value into a field on its way through, so a check can both verify something and store the answer. An insolvency check can accept the lead either way and put yes or no into a field the advertiser receives.

When you only want to store a value and never block anything, use Modify instead.

More than one scenario on a field

A field can have more than one validation scenario. All of them must succeed for the value to be accepted. One failure rejects the field, whatever the others returned.

The order things run in

1. Basic validation and regex run first, on every field that has a value.
2. Validation scenarios run only if that first pass found nothing wrong, anywhere in the form.

So a value that fails its regex never reaches the external service. That saves a call, but it also means a scenario you are testing will not run at all while another field is still invalid.

What to watch out for

⚠️ Validation through an external service can break the entire system if it is set up incorrectly, preventing the form from being submitted and the lead from being created.

Validation is always a trade-off between data quality and conversion rate. Stricter validation improves data accuracy, but it can also frustrate users filling out the form and cause them to abandon it before submission.

• Regex validation. If a mask or regex validation fails, the user will be prompted to correct the input before submission. Always ensure that the validation rules are accurate so the form remains submittable. Prefer simpler expressions over overly complex ones, as complicated patterns can lead to unexpected behavior.

• Unhandled responses. Write a branch for every answer the service can give, including the ones you do not expect. A response that matches no branch leaves the scenario with nowhere to go.

• Timeouts. If an external service takes too long to respond, users are stuck waiting with a loading spinner until the request finishes. This creates a poor user experience and increases the risk of abandonment. Set the timeout on the HTTP node, and remember that the whole scenario runs while the visitor waits, so it has to finish inside the synchronous limit. See Limits and timeouts.

👉 Always balance validation strictness with usability. For mission-critical checks, use external validation, but configure fallbacks and reasonable timeouts to prevent the system from breaking.