Tenant Settings
Every tenant in Vyntech Account has a settings object that controls security policies, session behavior, risk engine thresholds, branding, and notifications. This guide covers the full settings structure, how to read and update settings via the API, and common configuration patterns for different security postures.
Overview
Tenant settings are stored as a JSON object in the database and cached in Redis for fast access. When you update settings via the API, changes take effect immediately — the cache is invalidated and all subsequent authentication and authorization operations use the new values.
The settings object is divided into logical sections. You can update one section at a time or multiple sections in a single request. Updates use deep merge semantics — only the fields you include are changed; everything else remains untouched.
Deep merge behavior: If your current password_policy.min_length is 8 and you send a PATCH with {"password_policy": {"require_symbols": true}}, the min_length stays at 8. Only require_symbols is updated.
Settings Sections
The settings object contains 7 top-level sections. Each section controls a specific aspect of tenant behavior.
password_policy
Controls password strength requirements and rotation rules. Applied at registration, password change, and password reset.
| Field | Type | Default | Description |
|---|---|---|---|
| min_length | integer | 8 | Minimum password length (4–128) |
| require_uppercase | boolean | true | Require at least one uppercase letter |
| require_lowercase | boolean | true | Require at least one lowercase letter |
| require_numbers | boolean | true | Require at least one digit |
| require_symbols | boolean | false | Require at least one special character |
| max_age_days | integer | 0 | Force password rotation after N days (0 = disabled) |
| history_count | integer | 0 | Prevent reuse of last N passwords (0 = disabled) |
mfa
Controls multi-factor authentication availability and enforcement for the tenant.
| Field | Type | Default | Description |
|---|---|---|---|
| enabled | boolean | true | Whether MFA is available for users to opt-in |
| enforced | boolean | false | Require all users to set up MFA |
| allowed_methods | string[] | ["totp"] | Accepted MFA methods: "totp", "webauthn" |
session
Controls token lifetimes, idle timeouts, and concurrent session limits.
| Field | Type | Default | Description |
|---|---|---|---|
| access_token_ttl_seconds | integer | 900 | Access token lifetime (60–86400) |
| refresh_token_ttl_seconds | integer | 604800 | Refresh token lifetime (3600–2592000) |
| idle_timeout_seconds | integer | 0 | Revoke session after inactivity (0 = disabled) |
| max_concurrent_sessions | integer | 5 | Max active sessions per user (1–100) |
| absolute_timeout_seconds | integer | 0 | Force re-auth after N seconds regardless of activity (0 = disabled) |
risk_engine
Controls the behavioral risk engine that scores login attempts and triggers challenges or blocks.
| Field | Type | Default | Description |
|---|---|---|---|
| enabled | boolean | true | Enable risk scoring on login |
| challenge_threshold | integer | 70 | Score at which step-up MFA is required (1–99) |
| block_threshold | integer | 90 | Score at which login is blocked (1–100) |
| challenge_type | string | "mfa" | Challenge method: "mfa" or "email_verification" |
| trust_device_days | integer | 30 | Days a device is trusted after passing challenge (0 = never trust) |
ip_access
IP allowlist/blocklist configuration. When enabled, restricts login to specific IP addresses or CIDR ranges.
| Field | Type | Default | Description |
|---|---|---|---|
| enabled | boolean | false | Enable IP-based access control |
| mode | string | "allowlist" | "allowlist" (only listed IPs can access) or "blocklist" (block listed IPs) |
| addresses | string[] | [] | IP addresses or CIDR ranges (e.g., "10.0.0.0/8", "203.0.113.42") |
branding
Customize the appearance of hosted login pages and email templates.
| Field | Type | Default | Description |
|---|---|---|---|
| logo_url | string | null | URL to company logo (displayed on login page) |
| primary_color | string | "#0066FF" | Hex color for buttons and accents |
| company_name | string | null | Company name shown in emails and login page |
notifications
Control which email notifications are sent to users automatically.
| Field | Type | Default | Description |
|---|---|---|---|
| welcome_email | boolean | true | Send welcome email on user registration |
| login_alert | boolean | false | Email users on new device/IP login |
| password_change_alert | boolean | true | Notify users when password is changed |
Reading Settings
Retrieve the full settings object for your tenant. The response includes all sections with their current values (including defaults for any fields you haven't explicitly set).
/api/v1/settings🔒 AuthRetrieve the complete tenant settings object.
Updating Settings
Update one or more settings sections with a single PATCH request. The API uses deep merge — only the fields you include in the request body are modified. Omitted fields retain their current values.
/api/v1/settings🔒 AuthUpdate tenant settings (deep merge). Only include fields you want to change.
{
"password_policy": {
"min_length": 12,
"require_symbols": true,
"max_age_days": 90,
"history_count": 5
},
"session": {
"access_token_ttl_seconds": 600,
"idle_timeout_seconds": 1800,
"max_concurrent_sessions": 3
}
}Response behavior: The response always contains the complete settings object after the merge, so you can verify exactly what changed and confirm the final state.
Common Configurations
Here are three battle-tested configuration patterns for different security postures. Copy and adapt these to your needs.
Enterprise Security
Maximum security posture: strict password requirements, mandatory MFA, short sessions, aggressive risk engine. Ideal for financial services, healthcare, and government.
/api/v1/settings🔒 AuthEnterprise security configuration — maximum protection.
Developer-Friendly
Balanced security with minimal friction: reasonable password rules, optional MFA, longer sessions for better developer experience. Good for internal tools and dev environments.
/api/v1/settings🔒 AuthDeveloper-friendly configuration — balanced security with low friction.
Compliance Mode
Meets common compliance requirements (SOC 2, HIPAA, PCI-DSS): password rotation, session limits, IP restrictions, and mandatory notifications. Suitable for regulated industries.
/api/v1/settings🔒 AuthCompliance mode configuration — meets SOC 2, HIPAA, PCI-DSS requirements.
IP restriction warning: When enabling IP allowlist mode, make sure your current IP is included in the addresseslist. Otherwise, you'll lock yourself out of the API. Include your admin network and any CI/CD IPs.
Best Practices
Test in staging first
Always apply settings changes to a staging tenant before production. Misconfigured session timeouts or IP restrictions can lock out all users — including admins. Verify the behavior with a test user account.
Communicate changes to users
When tightening security (enforcing MFA, reducing session length, requiring password rotation), notify users in advance. A surprise lockout generates support tickets and frustrates users who weren't prepared for the change.
Don't lock yourself out
Before enabling IP restrictions or lowering max sessions to 1, ensure you have an active admin session that won't be affected. The settings API respects the current session — your active token remains valid until it expires, giving you a window to revert if needed.
Use the schema endpoint for validation
Call GET /api/v1/settings/schema to retrieve the full JSON Schema for settings. Use this to validate values client-side before submitting, or to dynamically build settings forms in your admin UI.
Audit log tracks all changes
Every settings update is recorded in the audit log with the full before/after diff, the actor (user ID), IP address, and timestamp. Use GET /api/v1/audit-logs?action=settings.updated to review the history of settings changes for compliance or troubleshooting.
What's Next
Settings API →
Full API reference for GET, PATCH, and schema endpoints.
Password Policies Guide →
Deep dive into password policy configuration and enforcement behavior.
Session Management Guide →
Detailed guide on session lifecycle, timeouts, and revocation.
Risk Engine Guide →
How the risk engine scores logins and how to tune thresholds.