Guide 10 · Developer docs

Building forms with the Forms module: how a form is put together and placed on a page, validating and branching, presenting it, where submissions are stored, and what happens after one arrives, from jobs and records to CRMs and payments.

L1–L2

Unit 02 of 07 1 page

Validating answers

Updated 23/10/2026 01:43

What the server checks without being configured, the rules you add yourself, how a rejected submission comes back in each submission model, and the patterns that keep errors accessible and preserve what the visitor typed.

A visitor's bad input is caught twice: once by the browser, from each input's own type and attributes, and again by the server, which applies the rules configured here and never trusts the browser alone. This unit covers both layers together with what a rejection looks like in each submission model, and the patterns that keep every visitor able to find and fix one without losing their answers.

Read it before Branching forms: a field that is conditionally required draws on the same validation rules described here.

In this unit

Read in order

01 Validation rules and error handling What each input type checks without configuration, what to check yourself, the rules you configure (with a regex that works on both sides), what a server rejection returns, and the patterns that make errors accessible and keep what the visitor typed.

Objects ReferenceGenerated from the platform, so it is always current

API ReferenceEvery REST endpoint, in cURL, PHP, Python and JavaScript

Validating answers

In this unit