Strict vs Non-Strict Mode

Many Multilogin X API endpoints support two validation modes controlled by the X-Strict-Mode header.

How It Works

Mode	Header Value	Behavior
Non-Strict (default)	false or omitted	Missing parameters get default values automatically
Strict	true	All required parameters must be explicitly provided; no defaults applied

Setting the Mode

# Non-Strict mode (default) — defaults applied for missing params
curl -X POST https://api.multilogin.com/profile/create \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name": "my-profile", "browser_type": "mimic", "folder_id": "..."}'

# Strict mode — all required params must be specified
curl -X POST https://api.multilogin.com/profile/create \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -H "X-Strict-Mode: true" \
  -d '{"name": "my-profile", "browser_type": "mimic", "os_type": "windows", "folder_id": "...", ...}'

When to Use Each Mode

Use Non-Strict Mode When:

• Prototyping and testing quickly
• You want sensible defaults applied
• Creating profiles with minimal configuration

Use Strict Mode When:

• Running production automation
• You need full control over every parameter
• You want to ensure no unexpected defaults

Endpoints That Support Strict Mode

• POST /profile/create — Profile creation
• POST /profile/update — Profile updates
• POST /cookies/apply — Cookie injection
• PUT /cookies/metadata — Cookie metadata updates

Default Values in Non-Strict Mode

When using Non-Strict mode, common defaults include:

Parameter	Default Value
os_type	windows
browser_type	mimic
is_headless	false
target_website	mix

TIP

Each endpoint's documentation specifies which parameters have defaults and what those defaults are.