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'requiredDeployment environment for verification. Use 'sandbox' for testing and
'production' for live verifications.
bearerTokenstringrequiredBearer token for API authentication. Required for all API calls.
apiUrlstringFor 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: 30000Request timeout in milliseconds.
maxRetriesnumberDefault: 3Maximum number of retry attempts for failed requests.
debugbooleanDefault: falseEnable 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: falseEnables 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: trueControls 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: trueControls whether the email field appears in the address confirmation form.
showPhonebooleanDefault: trueControls 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: falseWhen 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: falseWhen 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: falseControls 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 emitsaddress:field_tampering_detectedevents for audit logging'block': Prevents form submission and displays error messages, emitsaddress:field_tampering_blockedevents
// 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
- API Reference - Explore all available methods
- Events - Handle verification events
- Frameworks - Framework-specific guides