Validations

The template includes a built-in validation system that controls which verifications users must complete before navigating or performing actions (deposit, withdraw, play casino, etc.).

How it works

The brand configuration (features.authValidation, served by the API) defines which validation modules are active for each context. The system evaluates the user's profile data against these modules and shows the appropriate modal when something is pending.

This is API-driven, not fork-driven — you do not edit these rules in the template. To change which validations your brand requires, ask the platform team to update your brand settings.

Contexts

authValidation carries one entry per context: global, register, casino, sports, deposit, firstDeposit, withdraw, firstWithdraw, updateData, updateLimits.

Two display modes

Mode	When it appears	Can be closed?
Blocker overlay	Global/regulatory/forced validations pending	No (anti-tamper protection)
Steps modal	Context-specific validations (deposit, withdraw, etc.)	Yes (click outside or X button)

Available modules

Module	What it verifies
email	Email address verified via OTP code
phone	Phone number verified via SMS code
address	Full address (zipcode, street, city, state)
docs	Personal documents (CPF, birth date, nationality)
full_name	Full name present on the profile
kyc	Identity verification (selfie + documents)
password	Strong password confirmation
user_limits	Responsible gaming limits (time + loss)
terms	Terms and conditions accepted
gps	Geolocation permission granted
bank_account	Bank account registered

These are the module names the SDK evaluates. Modules are presented to the user in a fixed priority order (KYC always before user_limits, because the API rejects a limits submission before KYC is validated).

observação

sms and document exist only as label aliases used by the UI — they are not module names you can put in the modules array. Use phone and docs.

Brand configuration

The validation modules for each context come from the brand API (features.authValidation). Example structure:

{
  "global": {
    "active": true,
    "modules": ["user_limits", "address"],
    "frequent": false,
    "minValue": null,
    "device": null
  },
  "deposit": {
    "active": true,
    "modules": ["email", "phone", "address", "kyc"],
    "frequent": false,
    "minValue": null,
    "device": null
  },
  "withdraw": {
    "active": true,
    "modules": ["password"],
    "frequent": true,
    "minValue": 1,
    "device": null
  }
}

Configuration fields

Field	Description
active	Whether this context's validations are enabled
modules	List of module IDs to validate
frequent	If true, modules are re-validated every time (e.g., password on each withdrawal)
minValue	Minimum amount (in cents) to trigger validation. null = always
device	Device filter defined by the brand API. null = all devices. The accepted non-null values are part of the backend contract — ask the platform team if you need to scope a validation to one device class

Customizing labels and messages

All the text in the validation modals comes from the validation i18n namespace — app/components/validation/constants.ts holds no literal copy, only the translation keys (validation:module_labels.*, validation:context.*). Editing that file will not change any wording.

To reword anything, override the namespace:

// app/locales/overrides/<lang>/validation.json
{
  "module_labels": {
    "docs": "Seus documentos"
  },
  "context": {
    "withdraw": "Confirme sua senha para sacar"
  }
}

Only the keys you declare are replaced — everything else keeps the SDK value. See i18n for the full override precedence.

Icons (not text) live in app/components/validation/ui/StepCarousel.tsx.

Theming

All validation modals use the auth.* color tokens from app/config/theme/colors.ts. Changing the auth group updates the validation modals automatically — they share the tokens with the login and register modals.

See Theming for details on available color tokens.