Developers · Data

Data Validation Overview

Last updated 1 November 2026

Why you validate data in the browser and on the server, and where server-side checks live on Insites.

Validation checks that the data someone sends is complete and correct before you store it. It keeps bad data out of your tables and stops people sending input your code does not expect.

Validate in two places. In the browser, validation gives people fast feedback while they fill in a form. On the server, validation is the check you rely on, because anyone can send a request without your form.

Where server-side checks live

Place	What it checks
`validation:` on a field in a form definition	Rules for one field, such as `presence: true` or `length: { minimum: 8 }`
The form's `callback_actions`	Checks across fields, with `form_set_field_error` to report a problem
Your page code before a mutation	Anything else, for pages that call GraphQL directly

On submit, the field validations run first. callback_actions only runs when they pass.

Example: a form with field and cross-field checks

modules/dashboard/public/forms/update_password.liquid

---
name: update_password
resource: User
resource_owner: anyone
fields:
  current_password:
    validation: { presence: true }
  password:
    validation: { presence: true, length: { minimum: 8 } }
  password_confirmation:
    validation: { presence: true }
callback_actions: >
  {% liquid
    if form.password != form.password_confirmation
      form_set_field_error 'password_confirmation', 'Passwords do not match'
      break
    endif
  %}
---

This is the pattern the Insites reference apps use. A form with resource_owner: anyone should also list authorization_policies, so only the right people can submit it.

Note

This example is from the Insites Logic Engine forms reference. It was not run on the docs instance, because submitting a form writes data.

Common mistakes

Trusting browser checks alone. They are skipped by any request that does not come from your page.
Writing with records_create and expecting your rules to run. It stores properties as given, without validations or callbacks.
Assuming a missing CSRF token rejects a POST. It does not; the request arrives with no signed-in user. An endpoint that does not need a user must still check its own input.