Form validation and spam protection

Documentation / Media, forms, and integrations

Native forms combine browser-side input constraints with server-side checks. These reduce invalid submissions, but they do not prove that a sender is genuine or make every form field safe for every purpose.

Configure fields and protection

In the form builder, mark necessary questions as required and choose suitable input types. Browser controls can check formats such as email addresses and apply configured constraints. The submission endpoint independently rejects missing required values.

Form settings include a honeypot toggle and an hourly rate limit. The honeypot is a hidden field intended to catch automated filling: a filled honeypot produces an accepted-looking response but discards the submission. Rate limiting uses a site, form, and IP-based key.

The current limiter is process-memory based. It should not be described as a distributed guarantee across every server instance. No verified CAPTCHA configuration is part of these controls.

Recognize current limits

The settings screen includes an option concerning multiple submissions, but the verified submission handler does not enforce a separate identity-based duplicate rule. Do not promise one response per person from that option alone.

A required checkbox can support a consent question, but its wording and use still require review. The generic required-value check is not a complete legal-consent audit system. Likewise, a file input is not evidence that attachments are securely uploaded and stored.

Test expected failures

On the saved public page, try an empty required field, a malformed browser-validated input, and one valid submission. Confirm that errors are readable and a valid record reaches the admin. Check closure behavior if you stop accepting responses.

See Legal and privacy with LEX8 and Saving, recovery, and troubleshooting.