Skip to main content
Use this page when you want practical examples for the current Embedded API configuration options. If you need to combine branding, UI, and interaction defaults in one setup flow, jump to I need to configure several settings together.

Intended usage pattern

  • Call configureApp() for app-level settings.
  • Call setInteractionOptions() before the user starts or opens an interaction.
If you are moving from configure() or configureSession(), use the Config Migration Guide. For timelines and compatibility, see Scheduled Deprecations.

App UI and navigation

Use this when the interaction title is already shown elsewhere in your product and you do not want to repeat it inside the embedded assistant.
Use this when you do not want clinicians to submit document feedback from inside the embedded assistant.
Use this when your workflow does not allow in-product AI chat or when you want to keep the embedded experience focused on recording and documentation only.
Use this when you do not want clinicians to open settings, browse older interactions, or navigate away from the flow controlled by your host application.
Use this when you need the embedded Assistant debug panel while developing or troubleshooting an integration locally.
debug is only intended for development. Do not enable it in staging or production.
Use this when your product already provides the surrounding navigation and context, and you want the embedded assistant to stay limited to the current interaction.

Appearance, language, and network

Use this when you want the embedded experience to match your product branding.
Always ensure WCAG 2.2 AA conformance when customizing appearance
Use this when you want to control the language of the embedded UI.
Use this when you want the embedded experience to start with a specific dictation language.
Use this when you need to replace specific interface strings with product-specific wording.
Use this only for proxy setups that need a custom WebSocket endpoint. See the Proxy guide.

Interaction mode and spoken language

Use this when you want to set the initial interaction mode while keeping both modes available.
Use this when users should still be able to switch modes, but one mode should be the default.
Use this when your workflow only supports one interaction type.
Use this when a session should default to a specific spoken language.
Use this when an embedded deployment supports only a specific set of spoken languages. If you provide one option, users cannot change the spoken language. If you provide a fallback, make sure it is included in options.

Template defaults and personal templates

Use this when you want to provide a fallback standard template for new sessions using the fully resolved template id. It is used only when the user does not already have their own default template set.
If your old integration used defaultTemplateKey: "corti-soap" together with defaultOutputLanguage: "en", the new template.id should be "corti-soap-en".
Use this when your host application controls the default template and clinicians should not be able to choose or persist their own default from inside the embedded Assistant.
Use this when you want clinicians to create, edit, copy, view, or delete personal templates through the Guided Document Generation template editor.
Requires Guided Document Generation. Only applies to new templates.
Use this when you want to hide or lock specific section-level fields in the guided template creation flow. For example, to let users edit headings but hide the writing-style and misc prompts:
heading and description are always visible; only editable applies. For contentPrompt, writingStylePrompt, miscPrompt, and outputSchema, omitting visible or setting visible: false hides the field and prevents editing. When a prompt field is visible, it is editable by default unless you set editable: false.

Standard and project template sources

Use this when standard templates should remain available without filtering.
Use this when the embedded assistant should not show any standard templates in the picker.
Use this when the embedded experience should only present standard templates from specific regions using ISO 3166-1 alpha-3 codes such as BEL, DNK, or CAN. When limited to a single region, the region headline is automatically hidden.
Use this when you want to narrow standard templates by family, such as soap.
Use this when standard templates should stay available, but specific regions should be removed from the picker.
Use this when you want to remove a family such as letter while keeping other standard templates available.
Use this when you need both narrowing and removal in the same configuration. The embedded assistant applies include first and exclude second.
Region values use ISO 3166-1 alpha-3 codes such as BEL, DNK, or CAN. Family values are standard template family identifiers such as soap, depending on the available standard template metadata.
Use this when you want to expose project templates selectively. Project templates are referenced by UUID in include.ids and exclude.ids.
Use this when project templates should remain available, but a specific UUID or set of UUIDs must be hidden.
Use this when the embedded assistant should not show any project templates in the picker.

Documents and companion workflows

Use this when you want to show or hide the document sync action inside the embedded experience.
Use this when an embedded workflow should allow only one or two generated documents for the current interaction. When the limit is reached, document generation controls are hidden.
Use this when you want to restrict the output language options shown to users. For Guided Document Generation, the output language dropdown displays only the allowed languages; if restricted to a single language, the dropdown is disabled. For older document generation, this limits which template language groups appear in the left sidebar.
Use this when your embedded deployment offers phone-based companion capture. Enable the companion app surface at app level, then call showDeviceLinkQR() with the current user’s OAuth token response when the user starts pairing.
See showDeviceLinkQR() for return statuses and error handling.

Combined setup flows

Use this when you need to apply several settings together.If the settings all belong to configureApp(), you can group them into one call or chain multiple configureApp() calls. Because configureApp() is patchable, both patterns are valid.
If you need both app-level settings and interaction-level settings, group app-level settings inside configureApp() as needed, then call setInteractionOptions() before the user starts or opens an interaction.
A practical rule is: optional app-level settings can be grouped or split across configureApp() calls, but interaction options should be finalized in setInteractionOptions() before the interaction is opened.

Scheduled Deprecations

Review timing, compatibility expectations, and rollout guidance.

API Reference

Review method-level details for configureApp() and setInteractionOptions().