Configuration

Comprehensive configuration options for the VECU IDV Web SDK.

SDK-Only Access

To ensure your integration remains stable and supported, always use the official SDKs. The underlying API endpoints are internal implementation details that may change in purpose, functionality, or be removed at any time without notice. Direct API access is not supported. Learn more →

The SDK handles environment routing automatically — use the provided environment methods rather than targeting endpoints directly.

SDK Initialization

Configure the SDK instance using createVecuIDVSDK():

import { createVecuIDVSDK } from 'vec-idp-web-sdk';

const sdk = createVecuIDVSDK({
  // Required: Deployment environment
  deploymentStage: 'sandbox', // 'sandbox' | 'production'

  // Required: Authentication
  bearerToken: 'your-bearer-token',

  // Optional: API configuration
  apiUrl: 'http://localhost:8080', // For local mock server testing only (auto-detected from deploymentStage if not provided)
  timeout: 30000, // Request timeout in ms (default: 30000)
  maxRetries: 3, // Number of retry attempts (default: 3)

  // Optional: Debug and logging
  debug: true, // Enable debug mode (default: false)
  logLevel: 'info', // 'debug' | 'info' | 'warn' | 'error'
});

Initialization Options

deploymentStage'sandbox' | 'production'required

Deployment environment for verification. Use 'sandbox' for testing and 'production' for live verifications.

bearerTokenstringrequired

Bearer token for API authentication. Required for all API calls.

apiUrlstring

For local mock server testing only. The SDK automatically targets the correct API URL based on deploymentStage. Do not use this to call API endpoints directly.

timeoutnumberDefault: 30000

Request timeout in milliseconds.

maxRetriesnumberDefault: 3

Maximum number of retry attempts for failed requests.

debugbooleanDefault: false

Enable debug mode for detailed logging.

logLevel'debug' | 'info' | 'warn' | 'error'Default: 'info'

Logging level for SDK messages.

Verification Config Options

Properties available in the config object when calling startVerificationWithCustomer():

await sdk.startVerificationWithCustomer('#container', {
  customerInfo: {
    /* ... */
  },
  referenceId: 'customer-12345',
  config: {
    qrCode: true, // Enable QR code for mobile handoff
    showSsnOnInitialForm: true, // Show SSN field in form
    showEmail: true, // Show email field in address confirmation
    showPhone: true, // Show phone field in address confirmation
    allowPhoneEdit: false, // Allow user to edit pre-populated phone
    hideEmailDisplay: false, // Hide email from form (still sent to API)
    allowEmailOverride: false, // Show editable Personal Email above readonly Company Email
    tamperingBehavior: 'warn', // 'warn' | 'block'
  },
});

qrCode

qrCodebooleanDefault: false

Enables QR code functionality for mobile handoff verification. When enabled, users can scan a QR code to complete verification on their mobile device.

await sdk.startVerificationWithCustomer('#container', {
  customerInfo: {
    /* ... */
  },
  config: {
    qrCode: true, // Users can scan QR code for mobile handoff
  },
});

showSsnOnInitialForm

Added in v1.3.3

This option supports compliance with GDPR, CCPA, and other regional data protection regulations.

showSsnOnInitialFormbooleanDefault: true

Controls whether the SSN/National ID field appears in the information verification form. When set to false, the field is hidden and excluded from API submission.

// Hide SSN field for privacy compliance
await sdk.startVerificationWithCustomer('#container', {
  customerInfo: {
    /* ... */
  },
  config: {
    showSsnOnInitialForm: false, // Field hidden & excluded from API
  },
});

showEmail / showPhone

Added in v1.5.0

These options allow conditional display of contact fields in the address confirmation form.

showEmailbooleanDefault: true

Controls whether the email field appears in the address confirmation form.

showPhonebooleanDefault: true

Controls whether the phone field appears in the address confirmation form.

allowPhoneEdit

Added in v2.1.0

Enables phone number editing on the address confirmation form. Useful when pre-populated phone data may be outdated or incorrect.

allowPhoneEditbooleanDefault: false

When set to true, the phone field on the address confirmation form becomes editable, allowing users to correct their pre-populated phone number. The SDK tracks which fields were edited and includes an editedFields array in the API payload so the backend can flag manual changes for review.

// Allow users to edit their phone number
await sdk.startVerificationWithCustomer('#container', {
  customerInfo: {
    /* ... */
  },
  config: {
    allowPhoneEdit: true, // Phone field is editable
  },
});

hideEmailDisplay

Added in v2.1.0

Hides the email field from the address confirmation form while still including it in the API submission. Useful when email display is not needed or when reducing visible PII on screen.

hideEmailDisplaybooleanDefault: false

When set to true, the email field is hidden from the address confirmation form UI. The email value is still sent to the API as part of the address patch request — only the visual display is suppressed.

// Hide email from form display (still submitted to API)
await sdk.startVerificationWithCustomer('#container', {
  customerInfo: {
    /* ... */
  },
  config: {
    hideEmailDisplay: true, // Email hidden from UI, still sent to backend
  },
});

allowEmailOverride

Added in v2.2.2-rc3 (Release Candidate)

Lets the user provide a separate Personal Email at the address-confirmation step when their session was started with a company email. Useful when the email known at session start (e.g. corporate / dealer email) is not the one the user wants verified.

allowEmailOverridebooleanDefault: false

Controls the layout of the email section on the address-confirmation form when an email was supplied at session start.

  • false (default, legacy behavior): renders a single readonly email field carrying the value supplied at session start. That value is what gets sent to the verification provider.
  • true: renders an editable Personal Email field above a readonly Company Email field. The user enters their personal email; that's the value sent to the provider. The Company Email is informational only ("we already have this") and is not transmitted in the patch.

Has no effect when showEmail is false or hideEmailDisplay is true. Has no effect when no email was supplied at session start (the form falls back to a single editable email field, same as before).

// Opt in to the dual Company / Personal Email layout
await sdk.startVerificationWithCustomer('#container', {
  customerInfo: {
    email: 'user@acme.com', // Company email known at session start
    /* ... */
  },
  config: {
    allowEmailOverride: true,
  },
});

Why a separate field?

When allowEmailOverride is on and the user enters a Personal Email that differs from the Company Email, the SDK signals the change to the backend via editedFields: ['email']. This is automatic and only fires in this mode — in legacy single-readonly mode the readonly value is locked and any modification is treated as tampering.

tamperingBehavior

Added in v1.5.2

This is a client-side defense-in-depth feature for audit trail and early user feedback. Backend validation remains the primary security control.

tamperingBehavior'warn' | 'block'Default: 'warn'

Controls how the SDK responds when users modify pre-filled readonly fields (email, phone) during address confirmation.

  • 'warn' (default): Allows form submission but emits address:field_tampering_detected events for audit logging
  • 'block': Prevents form submission and displays error messages, emits address:field_tampering_blocked events
// Block mode - prevents submission when tampering detected
await sdk.startVerificationWithCustomer('#container', {
  customerInfo: {
    /* ... */
  },
  config: {
    tamperingBehavior: 'block',
  },
});

// Listen for tampering events
sdk.on(SdkEvent.ADDRESS_FIELD_TAMPERING_DETECTED, event => {
  console.warn('Field modified:', event.data);
  // event.data: { field, expectedValue, receivedValue }
});

Display Modes

The SDK supports two display modes:

Embedded Mode

The verification UI renders inside the container element, inheriting its dimensions.

// Container needs dimensions
<div id="container" style={{ minHeight: '600px', width: '100%' }} />

await sdk.startVerificationWithCustomer('#container', {
  customerInfo: { /* ... */ },
  mode: 'embedded'  // Default
});

Modal Mode

The verification UI appears in a centered modal overlay.

// Container used as attachment point only
<div id="container" />

await sdk.startVerificationWithCustomer('#container', {
  customerInfo: { /* ... */ },
  mode: 'modal'
});

Updating Configuration

Update SDK configuration after initialization using updateConfig():

Always Await updateConfig()

When updating bearerToken or deploymentStage, token exchange happens asynchronously. Failing to await will cause verification to use the wrong token.

// CORRECT - Await the config update
await sdk.updateConfig({
  deploymentStage: 'production',
  bearerToken: 'your-new-token'
});

// Now safe to start verification
await sdk.startVerificationWithCustomer(...);

// WRONG - Missing await causes race condition!
sdk.updateConfig({  // Missing await!
  deploymentStage: 'production',
  bearerToken: 'your-new-token'
});

await sdk.startVerificationWithCustomer(...);  // Will use OLD token!

Environment Variables

For React applications:

const sdk = createVecuIDVSDK({
  deploymentStage:
    process.env.NODE_ENV === 'production' ? 'production' : 'sandbox',
  bearerToken: process.env.REACT_APP_BEARER_TOKEN,
  debug: process.env.NODE_ENV === 'development',
});

For Next.js applications:

const sdk = createVecuIDVSDK({
  deploymentStage:
    process.env.NODE_ENV === 'production' ? 'production' : 'sandbox',
  bearerToken: process.env.NEXT_PUBLIC_BEARER_TOKEN,
  debug: process.env.NODE_ENV === 'development',
});

For Vue/Vite applications:

const sdk = createVecuIDVSDK({
  deploymentStage: import.meta.env.PROD ? 'production' : 'sandbox',
  bearerToken: import.meta.env.VITE_BEARER_TOKEN,
  debug: import.meta.env.DEV,
});

Provider Configuration

The identity verification provider is managed entirely server-side. The SDK automatically detects and adapts to the active provider — no client-side configuration is required.

Backend Configuration

Provider selection and credentials are managed by your platform administrator. Contact your VECU representative for provider configuration changes.

Next Steps