launch_session_ui
REQUIRES set_api_key to be called first. Launch a local web page in the browser for a FaceSign session. You MUST supply landingHtml (the pre-session page shown before the iframe), recapHtml (the results page shown after the session finishes), and uiStrings (a per-language dictionary whose keys are invented by you to match placeholders in the HTML). The MCP server provides NO default chrome — every visible string comes from you. Each page load / refresh creates a fresh session.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| flow | Yes | Array of nodes forming the session's directed graph | |
| zone | No | Data processing zone | |
| langs | No | Optional whitelist of BCP-47 language codes (from facesign://catalog) the session may use. DEFAULT BEHAVIOUR (recommended): OMIT this parameter entirely — the session then supports every language in the FaceSign catalog, and `uiStrings` must cover every catalog language. ONLY set `langs` when the user EXPLICITLY restricts the language set (e.g. 'Spanish-only demo', 'support English and Russian'). Do NOT narrow to `['en']` just because the user described the demo in English or did not mention languages — that would silently drop multilingual support. Example (explicit restriction): ["en", "es", "ru"]. The set of target languages for `uiStrings` is derived from this list (or the full catalog if omitted). | |
| avatarId | No | Avatar ID from the facesign://catalog resource. | |
| metadata | No | Arbitrary metadata to attach | |
| recapHtml | Yes | REQUIRED. Raw HTML/JS for the results/recap page. NO CDATA, NO markdown fences. Every visible string MUST come from `uiStrings` (via {{KEY}} or window.t('KEY')). Contract: reads window.__FACESIGN_SESSION__ (session data, re-populated on each poll), window.__FACESIGN_SESSION_ID__, window.__refetchSession() (returns Promise with updated data). The COMMON MISTAKES sections from the `landingHtml` field description apply here too — read them once and follow for both fields. For the complete session data shape (Session, SessionReport, NodeReport types, delayed vs immediate fields), read the `facesign://session-data-types` MCP resource. STYLE GUIDE (Results/Recap Page): Match this visual style for consistency with the FaceSign UI. Background: Light gray #f5f7fa with subtle gradient to light blue at top. Layout: Single-column, max-width 900px, centered (margin 0 auto), padding 2rem. Page header: "Session summary" bold 1.6rem. Subtitle with date/time and duration in muted color #888, font-size 0.9rem. User info card: White card with rounded photo (80-100px), grid of icon+text pairs for age, gender, location, device. Icons in muted blue #6b7faa. Section cards: White background, border-radius 12px, box-shadow 0 2px 12px rgba(0,0,0,.05), padding 1.5rem, margin-bottom 1.5rem. Section headings: Bold 1.15rem, color #1a1a2e, with small emoji/icon prefix (e.g. ✨ AI Analysis, 🔍 Detected Signals, 📋 Transcript). Margin-bottom 1rem. Status banners (full-width within card, border-radius 12px, padding 1rem 1.5rem, white text, bold): - Verified/success: background #4a9d6e, shield ✓ icon - High-risk/warning: background #d97b30, ⚠ warning icon Signal items: Left border 4px solid, padding-left 1rem, margin-bottom 1rem, background white or tinted. - Normal: border-color #059669, light green tint background #f0fdf4 - Suspicious: border-color #f59e0b, light yellow tint background #fefce8 - High-risk: border-color #ef4444, light red tint background #fef2f2 Status badges (inline, pill): border-radius 6px, padding 2px 10px, font-weight 700, font-size 0.8rem, uppercase. - RECOGNIZED/NORMAL: background #d1fae5, color #065f46 - SUSPICIOUS: background #fef3c7, color #92400e Confidence scores: Right-aligned, font-size 0.85rem, color #aaa. Key-value grid: Two-column layout. Label: small text, color #888, font-size 0.8rem, uppercase. Value: font-size 0.95rem, color #1a1a2e, below label. Transcript: Dark background #1e2a3a, border-radius 10px, padding 1.5rem, monospace font. "CONVERSATION LOG" header uppercase, small, muted. Each line: timestamp (gray #777), speaker label (FACESIGN: in teal #4db8a4, USER: in green #6bc96f), message text white. Line-height 1.8. Video: Centered, border-radius 8px, max-width 100%, dark container background. Font: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif. BEST PRACTICES FOR STABLE RENDERING (recapHtml): Session data arrives in two stages: some fields are available immediately when the session ends (user info, AI analysis, transcript), while others require polling. Video AI analysis may take up to 60 seconds; media usually arrives sooner. Naive implementations cause layout jumping (DOM rebuild on each poll) and duplicate network requests. ARCHITECTURE: Split Static vs Dynamic Rendering. renderStatic(data) — called ONCE: Renders all sections that won't change: user info (age, sex, location, device), aiAnalysis.overallSummary, aiAnalysis.analysis list, transcript, documentImages. updateDynamic(data) — called on each poll: Updates ONLY sections whose data arrives asynchronously: nodeReports, videoAIAnalysis, deepfakeDetection, and media (avatarVideo, screenshots). IMPORTANT: nodeReports is DELAYED — do NOT render node report data (face compare results, document scan results, etc.) in renderStatic(). Each dynamic section has its own wrapper element (e.g. <div id="video-ai-content">, <div id="node-reports-content">) so updates replace only that element's innerHTML, leaving the rest untouched. Track completion with boolean flags (videoAIDone, recordingDone, nodeReportsDone). Once a section is populated, skip further updates. Set videoAIDone when videoAIAnalysisStatus is either `succeeded` or `failed`. A failed analysis is terminal: replace the spinner with an unavailable message and do not interpret the missing result as clean evidence. If the status is absent, analysis was not requested, so omit the section. HTML STRUCTURE: <!-- Static sections: rendered once --> <div id="userinfo-card"></div> <div id="summary-card"></div> <div id="analysis-card"></div> <!-- Dynamic sections: inner content updated by polling --> <div id="video-ai-card"> <div class="card"> <div class="card-title">Video AI Analysis</div> <div id="video-ai-content"><!-- spinner initially, replaced when data arrives --></div> </div> </div> <div id="recording-card"> <div class="card"> <div class="card-title">Session Recording</div> <div id="recording-content"><!-- spinner initially, replaced when data arrives --></div> </div> </div> <!-- Static section: rendered once --> <div id="transcript-card"></div> POLLING: Single Entry Point with Guard (IIFE pattern): IMPORTANT: Polling MUST be limited — max 30 attempts, max 2 minutes total. Stop polling when limits are reached even if some data hasn't arrived. (function() { var polling = false; var pollCount = 0; var MAX_POLLS = 30; var startTime = Date.now(); var MAX_DURATION = 2 * 60 * 1000; // 2 minutes var videoAIDone = false; var recordingDone = false; var nodeReportsDone = false; function shouldStop() { return pollCount >= MAX_POLLS || (Date.now() - startTime) >= MAX_DURATION; } function poll() { if (polling) return; if (shouldStop()) return; polling = true; pollCount++; if (typeof window.__refetchSession !== 'function') { polling = false; setTimeout(poll, 2000); return; } window.__refetchSession() .then(function(data) { polling = false; updateDynamic(data); if ((!videoAIDone || !recordingDone || !nodeReportsDone) && !shouldStop()) setTimeout(poll, 4000); }) .catch(function() { polling = false; if (!shouldStop()) setTimeout(poll, 4000); }); } function init() { var data = window.__FACESIGN_SESSION__; if (!data) return; renderStatic(data); var needMore = updateDynamic(data); if (needMore) setTimeout(poll, 4000); } if (window.__FACESIGN_SESSION__) { init(); } else { var chk = setInterval(function() { if (window.__FACESIGN_SESSION__) { clearInterval(chk); init(); } }, 500); } })(); KEY RULES: - Call renderStatic() exactly once — avoids DOM rebuild and layout jumps - updateDynamic() only touches dedicated container elements — no reflow outside the updated section - Use a polling boolean guard — prevents concurrent __refetchSession() calls - ALWAYS limit polling — max 30 attempts AND max 2 minutes total. Never poll indefinitely. - Use videoAIDone / recordingDone / nodeReportsDone flags — stops updating a section once its data has been rendered - For video AI, derive videoAIDone from videoAIAnalysisStatus, not from the presence of videoAIAnalysis alone - nodeReports is DELAYED — always render node report data (face compare, document scan, etc.) in updateDynamic(), never in renderStatic() - Single init() entry point via IIFE — eliminates duplicate initialization paths - Check typeof __refetchSession === 'function' before calling — handles the case where the API isn't injected yet - Use setTimeout not setInterval for polling — ensures the next poll starts only after the previous one completes - nodeReport.type is lowercase snake_case ("face_compare", "document_scan") — use case-insensitive comparison - Document scan report fields are Microblink nested objects — use a safe-value extractor function (see COMMON MISTAKES) - videoAIAnalysis criterion is camelCase — convert to human-readable with toStartCase() (see COMMON MISTAKES) SUMMARY: Render once, patch selectively, poll safely with limits. Static content is written to the DOM a single time. Dynamic content (nodeReports, videoAIAnalysis, media) targets specific container elements. Polling is serialized with a guard flag and stops as soon as all async data has arrived or limits are reached (max 30 attempts / 2 minutes). | |
| uiStrings | Yes | REQUIRED. Per-language UI string dictionary: { langId: { key: translatedString } }. You invent the keys to match the {{KEY}} placeholders / window.t('KEY') calls in your landingHtml and recapHtml. Must contain an entry for `en` (ultimate runtime fallback) and for every language in `langs` (or every catalog language if `langs` is omitted). Every per-language dict must share the IDENTICAL set of keys. Example: { "en": { "START": "Start", "LOADING": "Loading..." }, "fr": { "START": "Commencer", "LOADING": "Chargement..." } }. | |
| defaultLang | No | Optional fallback BCP-47 language code used when the end-user's browser language is not in `langs`. DEFAULT BEHAVIOUR: OMIT this parameter. The MCP server falls back to 'en' internally only as a last-resort for UI string lookup; you should not hardcode a default language here unless the user explicitly asks for one. When set, must be one of the codes in `langs` (if `langs` is also set). | |
| landingHtml | Yes | REQUIRED. Raw HTML/JS for the pre-session landing page. NO CDATA, NO markdown fences. Every visible string MUST come from `uiStrings` — reference them via {{KEY}} placeholders (interpolated at inject time) or via window.t('KEY') (dynamic at runtime). Contract: reads window.__FACESIGN_FLOW__ (the flow array). MUST call window.__startSession(updatedFlow?) to launch the session. The session iframe has its own Start button for audio/video autoplay gesture — the landing page does NOT need one for that purpose. STYLE GUIDE (Pre-Session Page): Match this visual style for consistency with the FaceSign UI. Background: Light gray #f5f7fa. Full-viewport centered layout (flexbox, min-height: 100vh; min-height: 100dvh — always use dvh with vh fallback for iOS compatibility). Card: White, border-radius 16px, box-shadow 0 4px 24px rgba(0,0,0,.08), padding 2.5-3rem, max-width 480-600px, centered. Headings: Bold, 1.4-1.8rem, color #1a1a2e, centered in card. Inputs: Full-width, padding 14px 16px, border 2px solid #d1d5db, border-radius 12px, font-size 1rem. Focus: border-color #5b7bab. Placeholder color #9ca3af. Primary buttons: Background #7b8fb5 (steel-blue), color white, font-weight 600, font-size 1.05rem, border-radius 50px (pill shape), padding 14px, full-width in card. Hover: background #6a7fa5. Disabled: background #c5cdd8, cursor not-allowed. Links: Color #4573b8, no underline, underline on hover. Back navigation: "← Back" at top-left of card, color #4573b8, font-size 0.95rem. Profile images: Circular (border-radius 50%), 120-150px diameter, centered, subtle box-shadow. Spacing: 2.5-3rem card padding, 1.5rem between form groups, 1rem between label and input, 2rem above primary button. Font: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif. COMMON MISTAKES TO AVOID (UI/CSS): 1. Never set padding or margin on body The custom HTML is injected into a host page that controls its own layout. Setting padding, margin, or min-height on body will conflict with the host page styles and create unwanted spacing. Wrong: body { padding: 2rem; min-height: 100vh; } (Also wrong — using only 100vh without dvh fallback. Always add min-height: 100dvh after 100vh for iOS Safari.) Right — use a wrapper element instead: body { margin: 0; padding: 0; } .wrap { max-width: 860px; margin: 0 auto; padding: 2rem; } The same applies to background on body — avoid it unless you are certain the host page does not set its own background. 2. Use HTML entities for emoji, not JS unicode escapes When building HTML strings in JavaScript (via innerHTML, string concatenation, etc.), JS unicode escapes like \ud83c\udfa5 will NOT render as emoji. They only work inside JS string literals that are directly displayed via textContent or similar APIs. Wrong — renders as garbled text: h += '<div class="title">\ud83c\udfa5 Video AI Analysis</div>'; Right — use HTML numeric entities: h += '<div class="title">🎥 Video AI Analysis</div>'; Also right — use emoji directly in static HTML (outside of JS): <div class="title">🎥 Video AI Analysis</div> Common emoji HTML entities reference: 👤 👤 User/person 🎂 🎂 Birthday cake 📍 📍 Pin/location 💻 💻 Computer ✨ ✨ Sparkles 🔍 🔍 Search 🎥 🎥 Camera 🎬 🎬 Clapper board 📋 📋 Clipboard ⚧ ⚧ Gender symbol ✓ ✓ Checkmark 3. CSS class name collision between landingHtml and recapHtml CRITICAL: landingHtml and recapHtml are injected into the SAME host document. If both fragments use the same class names (e.g., .card, .container, .header), styles from one will leak into the other, causing layout breakage. ALWAYS use unique prefixed class names: - landingHtml (pre-session/landing page): prefix all classes with .lp- (e.g., .lp-card, .lp-header, .lp-btn) - recapHtml (results page): prefix all classes with .r- (e.g., .r-card, .r-header, .r-wrap) Wrong — causes collisions: /* in landingHtml */ .card { max-width: 460px; } /* in recapHtml */ .card { max-width: 900px; } Right — namespaced: /* in landingHtml */ .lp-card { max-width: 460px; } /* in recapHtml */ .r-card { max-width: 900px; } COMMON MISTAKES TO AVOID (Code/API): 4. window.__startSession race condition NEVER call window.__startSession() synchronously in a click handler. The host page may not have injected the function yet. ALWAYS use polling: function waitAndStart(input) { var n = 0; var iv = setInterval(function() { n++; if (typeof window.__startSession === 'function') { clearInterval(iv); window.__startSession(input); } else if (n > 100) { clearInterval(iv); document.body.innerHTML = '<p style="text-align:center;padding:2rem;color:red;">Failed to initialize session. Please refresh.</p>'; } }, 100); } Wrong: startBtn.addEventListener('click', function() { window.__startSession(); }); Right: startBtn.addEventListener('click', function() { waitAndStart(); }); For exported apps, NEVER send window.__FACESIGN_FLOW__ or another graph back to the server. To select a flow declared in export_app, pass its ID: waitAndStart({ flowId: 'enhanced', providedData: { name: nameInput.value } }); 5. Permissions are automatic — do NOT add a permissions node by default FaceSign automatically requests camera and microphone permissions at session start. Most flows do NOT need a PERMISSIONS node. Only add one in these specific cases: (a) The user wants to request microphone and camera permissions separately at different times during the flow (instead of both at once at session start). (b) The user wants to move the permission request to the initial page (landingHtml), outside the FaceSign flow itself. 6. nodeReport.type values are lowercase snake_case The API returns nodeReport.type in lowercase snake_case: "face_compare", "document_scan", "conversation", "permissions", "liveness_detection", etc. — NOT uppercase like "FACE_COMPARE". ALWAYS use case-insensitive comparison when looking up node reports: function getNode(r, type) { var rr = (r && r.nodeReports) || []; var tl = type.toLowerCase(); for (var i = 0; i < rr.length; i++) { if (rr[i].type && rr[i].type.toLowerCase() === tl) return rr[i]; } return null; } // Usage: getNode(report, 'face_compare'), getNode(report, 'document_scan') 7. Microblink document report — nested field structure DOCUMENT_SCAN nodeReport.report fields are NOT plain strings. They use Microblink's nested structure: firstName: { latin: { value: "JANICE" } } dateOfBirth: { originalString: { latin: { value: "04/30/1970" } } } — OR — dateOfBirth: { day: 30, month: 4, year: 1970 } NEVER read fields directly as strings (e.g., dr.firstName will be an object, not "JANICE"). ALWAYS use this safe-value extractor: function sv(v) { if (v == null) return ''; if (typeof v === 'string') return v; if (v.latin && v.latin.value != null) return String(v.latin.value); if (v.originalString) return sv(v.originalString); if (v.day != null && v.month != null && v.year != null) return v.month + '/' + v.day + '/' + v.year; return ''; } // Usage: sv(dr.firstName) → "JANICE", sv(dr.dateOfBirth) → "04/30/1970" 8. videoAIAnalysis criterion is camelCase — format for display The criterion field (e.g., "facialExpressionAndMovement", "useOfExternalDevices") comes in camelCase. Convert to human-readable format: function toStartCase(s) { if (!s) return ''; return s.replace(/([A-Z]+)/g, function(m) { return ' ' + m.toLowerCase(); }) .trim().replace(/^./, function(c) { return c.toUpperCase(); }); } // "facialExpressionAndMovement" → "Facial expression and movement" 9. Conversation node: condition vs prompt In CONVERSATION nodes: - "condition" (in outcomes) = ONLY describes the trigger event for transitioning to the next node (e.g., "User explicitly agrees to proceed") - "prompt" = ALL instructions for the avatar's behavior, including how to greet, how to respond to questions, how to handle objections, and how to persuade - User questions or objections during the conversation are handled within the SAME node (continued dialog), NOT via separate outcomes - Conversation nodes can have any number of outcomes depending on the use case: * Branching nodes (e.g., "what color?") → one outcome per branch + a fallback * Consent/agreement nodes → typically 2: agreement + fallback after N attempts - ALWAYS include a fallback outcome for when the conversation stalls (e.g., "conversation exceeded N exchanges with no condition met" or "user does not want to reply") Wrong — putting behavior instructions in condition: "condition": "User agrees. If they ask questions, answer warmly and ask again" Right — behavior in prompt, condition is just the trigger: "prompt": "Explain the process. If the user has questions, answer them warmly. Once they're ready, confirm." "condition": "User explicitly agrees or says they are ready" | |
| providedData | No | Pre-known user data | |
| customization | No | UI customization | |
| extractionSchema | No | Optional schema describing fields the FaceSign backend should extract from the session transcript using an LLM. Results are populated post-session at `session.report.extractedData` as `{ [fieldName]: string | number | boolean | null }` (null when the transcript did not contain the data — every field is treated as optional). Use this for structured data collection that does NOT need its own dedicated node — e.g. follow-up questions in a single CONVERSATION node where you'd otherwise have to author multiple branching outcomes. The conversation flow itself is unaffected; extraction runs on the final transcript. Render the results in your recapHtml when present. | |
| clientReferenceId | No | Your own reference ID for this session | |
| videoAIAnalysisEnabled | No | Enable video AI fraud analysis |