Skip to main content
The configure action allows you to customize the Corti Assistant interface to match your application’s needs and user preferences. This guide provides a comprehensive reference for all available configuration options, their behavior, and best practices for customization.

Overview

Configuration is applied using the configure action, which accepts three main categories of settings:
  • Features: Toggle UI components and functionality
  • Appearance: Customize visual styling and branding
  • Locale: Set interface and dictation languages, plus custom string overrides
Configuration can be applied incrementally. You can call configure with only the properties you want to change, and the rest will remain at their current values. The action returns the full current configuration object, allowing you to read the current state.
For implementation examples, see the PostMessage API or Window API documentation.

Feature Toggles

Feature toggles control which UI components and functionality are visible and available in the embedded Assistant. Each feature can be independently enabled or disabled, allowing you to create a tailored experience that matches your application’s workflow and user needs.

interactionTitle

Type: boolean
Default: true
Controls whether the interaction title field is displayed in the interface. The title typically shows the encounter title that was provided when creating the interaction. When to disable:
  • You want a more minimal, streamlined interface
  • You’re managing the interaction title externally in your application
  • The title is redundant with information already displayed in your host application
When to keep enabled:
  • Users need to see or edit the interaction title within the Assistant
  • The title provides important context for the current session
  • You want users to be able to identify different interactions
Impact: When disabled, the title field is completely hidden from the interface, reducing visual clutter but removing the ability for users to see or modify the interaction title within the Assistant.

aiChat

Type: boolean
Default: true
Controls whether the AI chat feature is available to users. The AI chat allows users to interact with Corti’s AI assistant for questions, clarifications, and document-related queries. When to disable:
  • You want to restrict AI chat functionality for compliance or policy reasons
  • Your workflow doesn’t require AI assistance features
  • You’re providing alternative support channels for user questions
When to keep enabled:
  • Users benefit from AI-powered assistance during documentation
  • You want to provide contextual help and clarifications
  • AI chat enhances the user experience and productivity
Impact: When disabled, all AI chat UI elements and functionality are hidden. Users will not be able to access AI assistance features within the Assistant interface.

documentFeedback

Type: boolean
Default: true
Controls whether users can provide feedback on generated documents. This includes the ability to rate document quality, report issues, or provide corrections. When to disable:
  • You handle document feedback through external systems
  • Feedback collection is not part of your workflow
  • You want to simplify the interface by removing feedback mechanisms
When to keep enabled:
  • You want to collect user feedback to improve document quality
  • Feedback helps identify issues or areas for improvement
  • You want users to have a way to report problems with generated documents
Impact: When disabled, all document feedback controls and related UI are hidden. Users will not be able to provide feedback on documents directly within the Assistant. Type: boolean
Default: false
Controls whether the navigation sidebar is visible, providing access to templates, settings, archive, and other areas of the Assistant. When to enable:
  • You want users to have full access to Assistant features
  • Users need to browse and manage templates
  • Users should be able to access settings and preferences
  • Archive functionality is needed for your workflow
When to keep disabled:
  • You want a focused, minimal interface for specific workflows
  • Navigation is handled externally in your application
  • You’re creating a single-purpose integration that doesn’t need full navigation
Impact: When enabled, the navigation sidebar becomes visible, allowing users to access:
  • /templates - Browse and create document templates
  • /settings/preferences - Edit defaults like languages and default session settings
  • /settings/input - Edit dictation input settings
  • /settings/account - Edit general account settings
  • /settings/archive - View items in and restore from archive
Best Practice: Enable navigation when you want users to have self-service access to Assistant features. Disable it for tightly controlled, workflow-specific integrations where you manage navigation externally.

virtualMode

Type: boolean
Default: true
Controls whether the interface operates in virtual mode (for remote/telemedicine consultations) or live mode (for in-person consultations). This affects the recording interface, audio handling, and user experience. When to set to false (live mode):
  • Consultations are conducted in-person
  • Recording happens locally or through local audio devices
  • You’re integrating with physical clinic environments
  • The consultation type is explicitly in-person
When to keep as true (virtual mode):
  • Consultations are conducted remotely (telemedicine)
  • Audio is captured through web-based or remote systems
  • The default virtual consultation workflow applies
  • Remote consultation is the primary or only mode
Impact:
  • Virtual mode (true): Optimized for remote consultations with web-based audio capture
  • Live mode (false): Optimized for in-person consultations with local audio handling
Best Practice: Match this setting to your actual consultation type. If your application supports both modes, you may want to configure this dynamically based on the specific encounter type.

syncDocumentAction

Type: boolean
Default: false
Controls whether the “Synchronize document” button is available for syncing documents directly to EHR systems or external systems. When to enable:
  • You want users to be able to sync documents directly from the Assistant interface
  • Direct EHR synchronization is part of your workflow
  • Users need immediate access to sync functionality
When to keep disabled:
  • Document syncing is handled externally through your application
  • You manage document export through your own systems
  • You want to control the sync process outside the Assistant
Impact: When enabled, the synchronize document button appears in the document interface. The button text can be customized using locale overrides (see String Overrides). Best Practice: Enable this if you want users to have direct control over document synchronization. If you handle syncing programmatically through your application, you may prefer to keep this disabled and manage syncing externally.

Appearance Customization

Primary Color

Type: string | null
Default: null (uses built-in default theme)
You can customize the primary accent color used throughout the Corti Assistant interface to match your application’s branding. This color is applied to interactive elements, buttons, links, focus indicators, and other accent elements throughout the interface. Format: Hex color code as a string (e.g., "#00a6ff", "#1a73e8") When to customize:
  • You want to maintain brand consistency with your host application
  • Your application has a specific brand color palette
  • You need to match existing design systems or style guides
  • Visual consistency across your integrated experience is important
When to use default:
  • Brand consistency is not a priority
  • You prefer Corti’s default accessible color scheme
  • You want to minimize customization complexity
Impact: The primary color affects:
  • Button backgrounds and hover states
  • Link colors
  • Focus indicators and active states
  • Accent elements and highlights
  • Selected states and active UI elements
Important Considerations:
  • The color must meet WCAG 2.2 AA contrast requirements (see WCAG Compliance)
  • The color is applied across all UI states (default, hover, active, focus, disabled)
  • Test thoroughly to ensure accessibility and usability
await api.configure({
  appearance: {
    primaryColor: "#00a6ff"
  }
});

WCAG 2.2 AA Compliance

Always ensure WCAG 2.2 AA conformance when customizing appearance
Corti Assistant’s default theme has been evaluated against WCAG 2.2 Level AA and meets applicable success criteria in our supported browsers. Important: This conformance claim applies only to the default configuration. Customer changes (e.g., color palettes, CSS overrides, third-party widgets, or content) are outside the scope of this claim. Customers are responsible for ensuring their customizations continue to meet WCAG 2.2 AA.

Required WCAG 2.2 AA Criteria

When supplying a custom accent color or theme, you must ensure WCAG 2.2 AA conformance, including:
  • 1.4.3 Contrast (Minimum):
    • Normal text: ≥ 4.5:1 contrast ratio
    • Large text: ≥ 3:1 contrast ratio
  • 1.4.11 Non-text Contrast:
    • UI boundaries, focus rings, and selected states: ≥ 3:1 contrast ratio
  • 2.4.11 Focus Not Obscured (Minimum):
    • Focus indicators must remain visible and unobstructed

Best Practices for Color Customization

  1. Test contrast ratios: Use tools like WebAIM Contrast Checker to verify your color choices
  2. Test all states: Verify contrast for default, hover, active, disabled, and focus states
  3. Test on all backgrounds: Ensure your color works on both light and dark backgrounds if applicable
  4. Maintain focus visibility: Ensure focus indicators remain clearly visible with your custom color
  5. Consider color blindness: Test with color blindness simulators to ensure usability
Corti provides accessible defaults. If you override them, verify contrast for all states (default, hover, active, disabled, focus) and on all backgrounds you use.

Locale Settings

Locale settings control the language used for the interface and dictation, as well as allow for custom string overrides.

Interface Language

Type: string | null
Default: null (uses user’s default or browser setting)
Sets the language for the user interface, including buttons, labels, menus, messages, and all UI text. This is separate from the dictation language, allowing you to have a German interface with English dictation, for example. Format: Language code as a string (e.g., "en", "de-DE", "fr-FR") When to set:
  • Your application serves users in specific languages
  • You want to ensure a consistent language experience
  • Users prefer a specific interface language regardless of browser settings
  • You’re building a localized application
When to use default (null):
  • You want to respect user browser/OS language preferences
  • Language detection should be automatic
  • You support multiple languages and want automatic selection
Available languages: See Available Interface Languages Best Practice: Set the interface language based on your application’s user preferences or locale settings. You can also allow users to change it if navigation is enabled.

Dictation Language

Type: string
Default: "en"
Sets the language for speech recognition and dictation. This determines which language model is used for transcribing spoken audio. The dictation language can be different from the interface language. Format: Language code as a string (e.g., "en", "de", "fr", "da-DK") When to customize:
  • Users dictate in a language different from the interface language
  • You need to support multilingual dictation
  • Regional variations require specific language codes (e.g., "en-GB" vs "en")
Important Notes:
  • Region-specific: Different regions (EU, US) support different dictation languages
  • Separate from interface language: Interface and dictation languages are independent
  • Must be valid: The language code must be supported in your region (see Available Dictation Languages)
Available languages: See Available Dictation Languages Best Practice: Set the dictation language based on the actual language users will speak during consultations. This may differ from the interface language, especially in multilingual environments.

String Overrides

Type: Record<string, string>
Default: {} (empty object)
Allows you to customize specific UI strings in the interface by providing key-value pairs where keys are string identifiers and values are the replacement text. Format: Object with string keys and string values:
{
  "string.key": "Custom text",
  "another.key": "Another custom text"
}
When to use:
  • You need to customize button labels to match your terminology
  • You want to localize specific strings that aren’t covered by interface language
  • You need to match your application’s terminology (e.g., “EHR” vs “EMR”)
  • You want to provide context-specific labels
Limitations:
  • Only specific keys are available for override (see Available String Overrides)
  • Not all UI strings can be customized
  • Overrides apply regardless of interface language
Best Practice: Use string overrides sparingly for critical terminology that must match your application. For broader localization, use the interface language setting instead.

Available String Overrides

Currently, the following keys are exposed for override:
KeyDefault valuePurpose
interview.document.syncDocument.label”Synchronize document”The button text for the “synchronize document” button if enabled.
More string override keys may be added in future releases. Contact support if you need additional strings customized.

Available Interface Languages

Updated as per November 2025
Language codeLanguage
enEnglish
de-DEGerman
fr-FRFrench
it-ITItalian
sv-SESwedish
da-DKDanish

Available Dictation Languages

Updated as per November 2025

EU Region

Language codeLanguage
enEnglish
en-GBBritish English
deGerman
frFrench
svSwedish
daDanish
nlDutch
noNorwegian

US Region

Language codeLanguage
enEnglish

Configuration Structure

The configure action accepts a configuration object with three main sections:
{
  features: {
    interactionTitle: boolean,
    aiChat: boolean,
    documentFeedback: boolean,
    navigation: boolean,
    virtualMode: boolean,
    syncDocumentAction: boolean
  },
  appearance: {
    primaryColor: string | null
  },
  locale: {
    interfaceLanguage: string | null,
    dictationLanguage: string,
    overrides: Record<string, string>
  }
}
All properties are optional. You can configure only the sections you need, and the rest will maintain their current values. The action returns the complete current configuration object, allowing you to read the current state.

Best Practices

Configuration Timing and Lifecycle

Apply configuration early: Configure the Assistant as soon as it’s ready (after the ready event) and before users interact with it. This ensures a consistent experience from the start. Configure before navigation: If you’re navigating to specific routes, set your configuration first to ensure the target page loads with the correct settings. Reconfigure dynamically: You can update configuration at any time during a session. This is useful for:
  • Adapting to different user roles or contexts
  • Responding to user preferences changes
  • Switching between different workflow modes
Configuration persistence: Configuration settings persist for the duration of the session but do not persist across page reloads or new sessions. You’ll need to reapply configuration each time the Assistant is initialized.

Incremental Configuration

The configure action supports incremental updates. You can update only specific sections without affecting others:
  • Update only features to change UI visibility
  • Update only appearance to change branding
  • Update only locale to change language settings
This allows you to make targeted changes without needing to specify the entire configuration object each time.

Reading Current Configuration

The configure action always returns the complete current configuration object, regardless of what you pass in. This allows you to:
  • Read the current state of all settings
  • Verify that your configuration was applied correctly
  • Build upon existing configuration rather than replacing it entirely

Error Handling

Always implement proper error handling when configuring:
  • Handle configuration failures: Configuration may fail due to invalid values, network issues, or other errors
  • Provide fallbacks: Have default configuration ready in case of failures
  • Log errors appropriately: Log configuration errors for debugging while maintaining user experience
  • Validate before applying: Validate configuration values (especially colors and language codes) before sending them

Accessibility Best Practices

Color customization:
  • Always test color contrast ratios using tools like WebAIM Contrast Checker
  • Test all UI states: default, hover, active, disabled, and focus
  • Ensure focus indicators remain clearly visible
  • Test on both light and dark backgrounds if applicable
  • Consider color blindness: Test with simulators to ensure usability
Feature toggles:
  • Ensure that disabling features doesn’t break keyboard navigation
  • Verify that screen readers can still navigate the interface
  • Test that essential functionality remains accessible when features are disabled
  • Consider the impact on users who rely on specific features
Language settings:
  • Ensure interface language changes don’t break layout or functionality
  • Test that all UI elements are properly localized
  • Verify that right-to-left languages (if supported) work correctly

Performance Optimization

Configure once at startup: Apply your primary configuration once when the Assistant is ready, rather than repeatedly calling configure. Batch configuration changes: If you need to change multiple settings, do it in a single configure call rather than multiple separate calls. Cache configuration objects: Store your configuration objects and reuse them across sessions to avoid reconstructing them each time. Minimize reconfiguration: Avoid unnecessary reconfiguration during a session. Only update configuration when user preferences or context actually change.

User Experience Guidelines

Match user workflows: Configure features based on your users’ actual workflow needs. Consider:
  • What features do users actually need for their tasks?
  • What can be simplified or hidden to reduce cognitive load?
  • How does the Assistant fit into the broader application workflow?
Consistent branding: Use appearance settings to maintain visual consistency with your host application. This creates a more cohesive, integrated experience. Respect user preferences:
  • Use interface language settings that match your application’s user preferences
  • Set dictation language based on the actual language users will speak
  • Consider allowing users to change settings if navigation is enabled
Context-aware configuration:
  • Configure differently for different user roles (e.g., physicians vs. nurses)
  • Adapt configuration based on consultation type (virtual vs. in-person)
  • Consider workflow-specific configurations for different use cases
Progressive disclosure: Start with a minimal configuration and enable additional features as needed. This reduces initial complexity while allowing power users to access advanced features.

Security and Compliance

No sensitive data in configuration: Configuration values are visible in client-side code. Never include sensitive information like API keys, tokens, or personal data in configuration. Validate user permissions: If you’re configuring based on user roles or permissions, validate those permissions server-side before applying configuration. Compliance considerations:
  • Ensure customizations maintain compliance with relevant regulations (HIPAA, GDPR, etc.)
  • Document any customizations that affect compliance
  • Test that disabled features don’t impact required functionality

Testing Recommendations

Test all feature combinations: Test how different feature toggle combinations affect the interface and functionality. Test color customizations thoroughly:
  • Test with various color values
  • Verify accessibility in all states
  • Test with different screen sizes and resolutions
Test language settings:
  • Verify all supported languages work correctly
  • Test interface language and dictation language combinations
  • Ensure string overrides work as expected
Test incremental updates: Verify that partial configuration updates work correctly and don’t reset other settings. Test error scenarios: Test what happens when invalid configuration values are provided.
Please contact us for help or questions about configuration.