Home Deployment Infrastructure

Deployment Infrastructure

By Admin General
15 articles

Widget Installation

The Support Portal live chat widget provides a real-time communication channel between your organization and its end users. Once a website inbox has been created and configured (see Live Chat Widget Configuration), the next step is deploying the widget to the target web property or application. This article covers the installation process for all supported platforms — from direct JavaScript embedding through framework-specific integrations. Prerequisites Before proceeding with installation, ensure the following are in place: - A website inbox has been created in Support Portal. Navigate to Settings > Inboxes and confirm the inbox exists. If not, follow the inbox creation process in Live Chat Widget Configuration. - The widget snippet is available. Open the inbox's Configuration tab to locate the generated JavaScript code. - You have access to deploy code changes on the target platform — either directly in the site's HTML, through a tag management system, or within the application's build pipeline. Base JavaScript snippet The foundation of every widget deployment is a JavaScript snippet that loads the SDK and initializes the widget with your inbox credentials. Regardless of the target platform, the underlying mechanism is the same — the snippet creates a script element that loads the SDK asynchronously and calls altoresSDK.run() with your configuration. The generated snippet follows this structure: <script> (function(d, t) { var BASE_URL = "https://your-support-portal-url.com"; var g = d.createElement(t), s = d.getElementsByTagName(t)[0]; g.src = BASE_URL + "/packs/js/sdk.js"; g.defer = true; g.async = true; s.parentNode.insertBefore(g, s); g.onload = function() { window.altoresSDK.run({ websiteToken: 'YOUR_WEBSITE_TOKEN', baseUrl: BASE_URL }); }; })(document, "script"); </script> Replace YOUR_WEBSITE_TOKEN with the token from your inbox's Configuration tab, and set BASE_URL to your Support Portal instance URL. Widget behavior settings Before the SDK loads, you can define a altoresSettings object in the global scope to control runtime behavior such as widget position, locale, style, and dark mode: window.altoresSettings = { hideMessageBubble: false, position: 'right', locale: 'en', type: 'standard', darkMode: 'auto', }; | Parameter | Values | Description | |---|---|---| | hideMessageBubble | true / false | Controls whether the launcher bubble is visible. Set to true when using a custom trigger element. | | position | 'left' / 'right' | Determines which side of the viewport the widget appears on. | | locale | Language code (e.g., 'en', 'fr', 'de') | Sets the widget interface language. | | type | 'standard' / 'expanded_bubble' | Selects the launcher style. The expanded bubble variant displays customizable text alongside the icon. | | darkMode | 'light' / 'auto' | Controls the widget color scheme. 'auto' follows the visitor's OS/browser preference. | For a complete reference of SDK parameters and advanced configuration, see Live Chat Widget Configuration. Direct HTML installation For static websites or server-rendered pages with direct access to the HTML source, place the snippet immediately before the closing </body> tag in your root layout or template file. This ensures the widget loads on every page without blocking the initial render. In enterprise environments with multiple web properties sharing a common layout template, the snippet can be placed in the shared template — with each site using a different inbox and its corresponding token. Google Tag Manager Organizations that manage scripts through Google Tag Manager (GTM) can deploy the widget without modifying site source code directly. This approach is particularly effective for enterprise environments where marketing or operations teams manage multiple web properties through a centralized tag management workflow — such as telecom operators maintaining consumer portals, dealer sites, and self-service platforms under a single GTM account. Creating the tag Open the Google Tag Manager workspace and select Add a new tag from the dashboard. Assign a descriptive name to the tag (e.g., "Support Portal Widget" or a name that identifies the target property). Select Tag Configuration and choose the Custom HTML tag type from the list. Paste the full widget snippet — including the surrounding <script> tags — into the HTML text area. Enable the Support document.write checkbox. Configuring the trigger Select Triggering beneath the tag configuration, then choose All Pages to deploy the widget across every page managed by this GTM container. For deployments that should only appear on specific pages — such as a support section or authenticated portal area — create a custom trigger with the appropriate page path or URL conditions instead. Publishing Save the tag. It appears under Workspace Changes in the GTM dashboard. Select Submit, provide a version name that identifies this deployment (e.g., "Deploy Support Portal widget v1.0"), and select Publish to push the changes live. After publishing, reload your website and confirm that the widget bubble appears. Incoming conversations should route to the agents assigned to the corresponding inbox. WordPress WordPress sites can deploy the widget using a dedicated plugin that exposes the configuration parameters through the WordPress admin interface — no direct code editing required. Installing the plugin Navigate to the WordPress Admin Panel and select Plugins from the sidebar, then select Add New. Upload the plugin package file to install it. After the upload completes, a confirmation screen presents the option to activate the plugin. Select Activate Plugin to enable it. Configuring the plugin Once activated, a new settings entry appears under Settings in the WordPress sidebar. Open it to access the widget configuration form. The configuration form requires the following parameters: | Field | Description | |---|---| | Website Token | The token from your inbox's Configuration tab in Support Portal. | | Installation URL | Your Support Portal instance URL (e.g., https://support.example.com). | | Widget Design | Choose between Standard and Expanded Bubble launcher styles. | | Widget Position | Left or right side of the viewport. | | Language | The widget interface language. | | Launcher Text | Optional. When using the expanded bubble design, this text appears alongside the launcher icon. | Both the website token and the installation URL are derived from the snippet generated during inbox creation. Copy these values from the Configuration tab. Select Save Changes to apply the configuration. Verification Open your WordPress site in a browser and confirm that the widget bubble appears. If the widget does not load, verify that the token and installation URL are correct and that no caching plugin is serving a stale version of the page. Webflow Webflow sites support custom code injection through the project settings interface, making widget deployment straightforward. Adding the snippet Open your Webflow project and navigate to Settings for the target site. Select the Custom Code section and locate the Footer Code field. Paste the widget snippet into this field. The footer position ensures the script loads after the page content, matching the recommended placement before the closing </body> tag. Save the changes. Publishing Select Publish from the Webflow editor, choose the target domain(s), and deploy. The widget becomes active once the published version propagates. Reload the published site and verify that the widget appears. React Native For mobile applications built with React Native, a dedicated widget component provides native-feeling chat integration. The component renders a WebView-based chat interface that can be presented modally. Installing the package Add the widget package to your project using your preferred package manager: yarn add support-portal-react-native-widget or npm install --save support-portal-react-native-widget This package depends on react-native-webview and @react-native-async-storage/async-storage. Follow the installation instructions for these peer dependencies in their respective documentation. For iOS builds, install the CocoaPods dependencies after adding the package: cd ios && pod install Integrating the component Import the widget component and render it conditionally. Replace the websiteToken and baseUrl values with those from your inbox configuration. import React, { useState } from 'react'; import { SafeAreaView, TouchableOpacity, Text, View, StyleSheet } from 'react-native'; import SupportPortalWidget from 'support-portal-react-native-widget'; const App = () => { const [showWidget, toggleWidget] = useState(false); const user = { identifier: '[email protected]', name: 'Jane Operator', avatar_url: '', email: '[email protected]', identifier_hash: '', }; const customAttributes = { accountId: 1, plan: 'enterprise', status: 'active', }; const websiteToken = 'YOUR_WEBSITE_TOKEN'; const baseUrl = 'https://your-support-portal-url.com'; const locale = 'en'; return ( <SafeAreaView style={styles.container}> <View> <TouchableOpacity style={styles.button} onPress={() => toggleWidget(true)} > <Text style={styles.buttonText}>Contact Support</Text> </TouchableOpacity> </View> {showWidget && ( <SupportPortalWidget websiteToken={websiteToken} locale={locale} baseUrl={baseUrl} closeModal={() => toggleWidget(false)} isModalVisible={showWidget} user={user} customAttributes={customAttributes} /> )} </SafeAreaView> ); }; const styles = StyleSheet.create({ container: { flex: 1, justifyContent: 'center', alignItems: 'center', }, button: { height: 48, marginTop: 32, paddingVertical: 8, paddingHorizontal: 16, backgroundColor: '#1F93FF', borderRadius: 8, justifyContent: 'center', }, buttonText: { color: '#fff', textAlign: 'center', fontWeight: '600', fontSize: 16, }, }); export default App; The user object enables contact identification — conversations are associated with the identified user, allowing agents to see interaction history across sessions. The customAttributes object attaches metadata visible in the conversation sidebar, which can be used for routing logic or contextual information (e.g., account tier, subscription status). Next.js Next.js applications require a component-based approach to load the widget script within the React lifecycle. The following pattern loads the SDK asynchronously after the component mounts, avoiding server-side rendering conflicts. Creating the widget component Create a component file (e.g., components/ChatWidget.js) with the following implementation: import React from 'react'; class ChatWidget extends React.Component { componentDidMount() { window.altoresSettings = { hideMessageBubble: false, position: 'right', locale: 'en', type: 'standard', }; (function(d, t) { var BASE_URL = "https://your-support-portal-url.com"; var g = d.createElement(t), s = d.getElementsByTagName(t)[0]; g.src = BASE_URL + "/packs/js/sdk.js"; g.async = true; g.onload = function() { window.altoresSDK.run({ websiteToken: 'YOUR_WEBSITE_TOKEN', baseUrl: BASE_URL }); }; s.parentNode.insertBefore(g, s); })(document, "script"); } render() { return null; } } export default ChatWidget; Replace BASE_URL and websiteToken with the values from your inbox configuration. Adding the component to your layout Import the component in your page or layout file so it renders on every route: import React, { Fragment } from 'react'; import ChatWidget from '../components/ChatWidget'; const Layout = ({ children }) => ( <Fragment> <ChatWidget /> {children} </Fragment> ); export default Layout; For Next.js applications using the App Router (Next.js 13+), place the widget component in your root layout file (app/layout.js) to ensure it loads across all routes. Because the component accesses window and document, wrap it in a dynamic import with SSR disabled or guard the lifecycle methods with a browser environment check. Vue.js Vue.js applications can load the widget by placing the snippet directly in the application's index.html file, or by using a component-based approach for more control. Direct HTML approach Open your Vue project's index.html file and paste the widget snippet before the closing </body> tag: <body> <div id="app"></div> <script> (function(d, t) { var BASE_URL = "https://your-support-portal-url.com"; var g = d.createElement(t), s = d.getElementsByTagName(t)[0]; g.src = BASE_URL + "/packs/js/sdk.js"; g.defer = true; g.async = true; s.parentNode.insertBefore(g, s); g.onload = function() { window.altoresSDK.run({ websiteToken: 'YOUR_WEBSITE_TOKEN', baseUrl: BASE_URL, }); }; })(document, "script"); </script> </body> Replace BASE_URL and websiteToken with the values from your inbox configuration. Nuxt.js deployments For Nuxt.js projects, the widget can be loaded using a client-side plugin. Create a plugin file (e.g., plugins/chat-widget.client.js) that executes the SDK loader in the browser context only. Register the plugin in your nuxt.config.js to ensure it loads on the client side. Verification and troubleshooting After completing the installation on any platform, verify the deployment by opening the target site or application in a browser or device. The widget bubble should appear in the configured position. Selecting the bubble should open the chat interface and, if channel greeting is enabled, display the configured greeting message. If the widget does not appear, check the following: Script loading — Open the browser developer console and verify that the SDK file (/packs/js/sdk.js) loads without errors. Network errors may indicate an incorrect BASE_URL or a content security policy blocking the script. Token validity — Confirm that the websiteToken value matches the token shown in the inbox's Configuration tab. An incorrect token results in a silent failure — the script loads but the widget does not render. Caching — Content delivery networks, browser caches, or platform-level caching (common in WordPress and Webflow) may serve a stale page version that does not include the snippet. Clear applicable caches and reload. Content Security Policy — Enterprise environments often enforce strict CSP headers. Ensure that your CSP allows script loading from your Support Portal domain and inline script execution if the snippet is embedded directly. Console errors — Review the browser console for JavaScript errors. Conflicts with other scripts on the page may prevent the SDK from initializing. For widget behavior configuration — including visual customization, business hours, pre-chat forms, and agent assignment — see Live Chat Widget Configuration.

Last updated on Feb 25, 2026

Live Chat Widget Configuration

Support Portal provides a configurable live chat widget that can be embedded on any website to establish a real-time communication channel between your organization and its end users. This article covers the full configuration surface — from initial inbox creation through visual customization, operational availability settings, dark mode, and SDK-level deployment. Operational objective The live chat widget serves as a front-line engagement layer for web properties. Proper configuration ensures that the widget reflects your organization's branding, operates within defined availability windows, and routes conversations to the correct agent pool. For regulated environments — government portals, telecom self-service sites, financial institutions — these settings also control the initial data collection posture and after-hours messaging behavior. Browser and platform support The live chat widget and the Support Portal dashboard are compatible with current versions of all major browsers. | Browser | Minimum version | |---|---| | Mozilla Firefox | 52+ | | Google Chrome / Chromium | 57+ | | Apple Safari | 14.1+ | | Microsoft Edge | 16+ | Mobile applications are supported on Android 5.0+ and iOS 11.0+. Creating a website inbox Before configuring widget settings, you must create a website inbox that serves as the container for the channel. Navigate to Settings > Inboxes and select Add Inbox, then choose the Website channel type. The creation interface presents the following parameters: | Field | Description | |---|---| | Website Name | A descriptive label for the site this inbox represents (e.g., "Municipal Services Portal" or "Customer Self-Service"). | | Website Domain | The fully qualified domain where the widget will be deployed (e.g., services.example.gov). | | Widget Color | The primary accent color applied to the widget bubble, header, and interactive elements. Select a color that aligns with your organization's visual identity. | | Welcome Heading | A short headline displayed at the top of the widget when a visitor opens it. | | Welcome Tagline | A supporting message below the heading that sets expectations for the interaction. | | Channel Greeting | When enabled, an automated greeting message is sent as soon as a visitor initiates a conversation. Define the greeting text in the accompanying field. | After providing the required parameters, select Create Inbox. The next step prompts you to assign agents. Assigning agents to the inbox Conversations are routed only to agents associated with the inbox. Even administrators must be explicitly added as collaborators to receive conversations from a given inbox. Select agents from the dropdown and confirm the assignment. Agent rosters can be modified at any time from the Collaborators tab in the inbox settings (see below). For guidance on creating agent accounts, see Agents. Widget deployment Once the inbox is created, Support Portal generates a JavaScript snippet for embedding the widget on your website. Navigate to Settings > Inboxes, select the inbox, and open the Configuration tab. Copy the snippet and place it in the root HTML template of your website — typically before the closing </body> tag. In enterprise deployments, this snippet is often managed through a tag manager or included in a shared layout template that spans multiple properties. For telecom operators managing multiple web properties (e.g., consumer portal, dealer portal, corporate self-service), each site typically maps to a separate inbox with its own widget configuration. This ensures that conversations are routed to the correct operational team and that the widget appearance matches each property's branding. Widget settings reference After creating the inbox, the full range of configuration options becomes available. Navigate to Settings > Inboxes, locate the website inbox, and select the gear icon to open its settings. General settings The Settings tab provides controls for the core widget behavior. Key options on this tab include: Email collection — Enabled by default. When active, the widget prompts visitors to provide an email address at the start of a conversation. This supports contact identification and follow-up workflows. Organizations that prefer anonymous initial interactions (e.g., government complaint portals where anonymity is required) can disable this setting. CSAT surveys — When enabled, a satisfaction survey is presented to the visitor each time a conversation is resolved. Survey results are aggregated in the Reports section. See Reports for details on interpreting CSAT data. Select Update to persist any changes made on this tab. Collaborators The Collaborators tab controls which agents have access to this inbox and whether automatic conversation assignment is active. When automatic assignment is enabled, incoming conversations are distributed among the agents associated with this inbox based on the configured routing logic. Disabling automatic assignment places all new conversations in the unassigned queue, where agents or supervisors can claim them manually — a pattern common in regulated environments that require human triage before assignment. Business hours The Business Hours tab defines the operational availability window for this inbox. Enable the Business availability toggle to activate scheduling. Once enabled, configure the following: Availability schedule — For each day of the week, set the opening and closing hours along with the applicable time zone. Days left unchecked are treated as non-operational. Unavailability message — Define the message displayed to visitors who initiate a conversation outside of configured business hours. This message should set clear expectations about response timing (e.g., "Our team is available Monday through Friday, 08:00–18:00 CET. Your message has been received and will be addressed during the next business day."). When an AI Module is active on the inbox, the unavailability message is suppressed during AI-handled sessions. The message is only sent if the AI Module transfers the conversation to a human agent or if no AI Module is configured. See Agentbot Configuration for details on AI Module behavior during off-hours. For government institutions operating across multiple time zones or with varying holiday schedules, business hours can be configured independently per inbox — allowing a single Support Portal workspace to serve regional offices with different availability windows. Select Update Business Hour Setting to save. Pre-chat form The Pre Chat Form tab allows you to collect visitor information before the conversation begins. This is particularly useful in environments where identification is required before an agent engages — for example, telecom support portals that need an account number or government services that require a case reference. Enable the pre-chat form and configure the following: Pre-chat message — An introductory message explaining why information is being collected (e.g., "To assist you efficiently, please provide the following details."). Form fields — The standard fields include Name, Email, and Phone. Additional fields can be added by creating custom attributes first — see Custom Attributes — which then become available as selectable form fields. Each field can be marked as required or optional, giving you control over the data collection posture. Select Update to activate the form. Widget builder The Widget Builder tab provides a visual interface for customizing the widget's appearance. Changes are previewed in real time within the builder. Available customization options include the widget bubble position, style, and the launcher icon. For organizations deploying the widget across multiple branded properties — such as a telecom operator with consumer and enterprise portals — the widget builder ensures each deployment can match the target site's visual language without code changes. Dark mode configuration The live chat widget supports automatic dark mode, adapting its appearance to match the visitor's operating system or browser theme preference. This is configured through the SDK settings rather than the inbox UI. To enable dark mode, add the darkMode parameter to the altoresSettings object in your widget deployment code: window.altoresSettings = { // ... other settings darkMode: "auto", }; The darkMode parameter accepts the following values: | Value | Behavior | |---|---| | light | The widget always renders in light mode. This is the default. | | auto | The widget follows the visitor's operating system or browser dark mode preference. | For government or enterprise portals that enforce a specific visual theme, setting darkMode to light ensures consistent appearance regardless of individual device settings. For consumer-facing sites where user preference is prioritized, auto provides a seamless experience. SDK settings overview The JavaScript snippet generated during inbox creation supports additional configuration through the altoresSettings object. This object is defined in the global scope before the widget script loads and controls runtime behavior such as dark mode (documented above), locale, widget position, and custom launcher behavior. window.altoresSettings = { darkMode: "auto", position: "right", locale: "en", // Additional SDK parameters as needed }; For a complete reference of available SDK parameters, see Sdk Setup. Enterprise deployment considerations Multi-site deployments — Telecom operators and large enterprises often deploy live chat across several web properties. Each property should map to a dedicated inbox with its own widget configuration, agent roster, and business hours. This ensures clean conversation routing and per-site reporting. The widget snippet is unique per inbox, so each site receives the correct configuration automatically. Brand-consistent theming — Government portals and regulated institutions typically have strict visual identity requirements. Use the Widget Color setting and Widget Builder to match official color schemes, and set darkMode to light if the portal enforces a fixed theme. Pre-chat form fields can be configured to collect identifiers required by organizational process (case number, department, service category). Availability governance — In environments where response time commitments are contractual (SLA-bound operations), business hours configuration should align precisely with staffed service windows. Combine business hours with the unavailability message to communicate expected response times transparently. When AI Modules are deployed for after-hours coverage, the handoff behavior between AI and human agents should be documented in your operational procedures.

Last updated on Feb 25, 2026

API Channel

Overview The API channel provides a developer integration point for connecting custom messaging platforms, proprietary interfaces, or any external system to Support Portal. Unlike pre-built social media channels, the API channel requires programmatic interaction through REST APIs and webhook callbacks, giving your engineering team full control over the conversation lifecycle. Use cases include: - Building a custom chat interface in place of the default web widget. - Embedding conversational support into mobile applications. - Bridging Support Portal to platforms for which no native channel integration exists. Prerequisites - An active Support Portal account with permission to create Inboxes (see Adding Inboxes). - A callback URL endpoint capable of receiving HTTP POST requests (for webhook delivery). - An API access token, obtainable from Profile Settings > Access Token within Support Portal. Configuration Steps 1. Initiate Inbox Creation Navigate to Settings > Inboxes and select Add Inbox. 2. Select the API Channel Type From the channel selection interface, select the API icon. 3. Provide Channel Parameters The configuration interface presents the following fields: | Parameter | Description | |---|---| | Channel Name | A descriptive label for this Inbox (e.g., "Mobile App Support"). | | Callback URL | The HTTPS endpoint where Support Portal sends event notifications via POST requests. | Select Create API Channel to proceed. 4. Assign Agents Add one or more Agents to the Inbox. Sending Messages to the API Channel All API requests require the api_access_token header. The following sequence establishes a conversation: Step 1: Create a Contact Issue a POST request to create a contact, including the Inbox ID of the API channel. The response includes contact_inboxes, each containing a source_id that serves as a session identifier. { "email": "[email protected]", "name": "Customer Name", "phone_number": "+1234567890", "contact_inboxes": [ { "source_id": "session-identifier-string", "inbox": { "id": 1, "name": "Mobile App Support", "channel_type": "Channel::Api" } } ], "id": 42 } Step 2: Create a Conversation Use the source_id from the previous response to create a conversation. The response returns a conversation ID. { "id": 101 } Step 3: Create a Message Send a message to the conversation. Messages are classified as either: - Incoming (message_type: 0) — messages originating from the end user. - Outgoing (message_type: 1) — messages sent by an Agent. { "id": 1, "content": "Message content", "inbox_id": 1, "conversation_id": 101, "message_type": 0, "created_at": 1693000000, "private": false, "sender": { "id": 42, "name": "Customer Name", "type": "contact" } } Receiving Messages via Webhook Callback When a new message is created in the API channel (for example, an Agent reply), Support Portal delivers a POST request to the callback URL configured during Inbox creation. The payload follows the message_created event structure: { "id": 1, "content": "Agent response content", "created_at": "2024-08-30T15:43:04.000Z", "message_type": "outgoing", "sender": { "id": 5, "name": "Agent Name", "type": "user" }, "inbox": { "id": 1, "name": "Mobile App Support" }, "conversation": { "channel": "Channel::Api", "id": 101, "inbox_id": 1, "status": "open" }, "event": "message_created" } For a complete list of supported webhook events, see Webhooks. Client APIs Support Portal exposes Client APIs specifically designed for building customer-facing interfaces on top of the API channel. Authentication Obtain the inbox_identifier from Inbox Settings > Configuration. The customer_identifier (also referred to as source_id) is returned when creating a contact through the API. Store this identifier on the client side (e.g., in cookies or local storage) to make subsequent requests on behalf of the customer. HMAC Verification Client APIs support HMAC-based identity validation to prevent impersonation. The HMAC token for the channel is available through the platform's administrative interface. WebSocket Connectivity To receive real-time updates from the Agent Dashboard, establish a WebSocket connection to: wss://<your-instance-url>/cable Subscribe using the customer's pubsub_token (provided during contact creation) to receive events directed to that customer object. const connection = new WebSocket('wss://your-instance.example.com/cable'); connection.send(JSON.stringify({ command: "subscribe", identifier: JSON.stringify({ channel: "RoomChannel", pubsub_token: customer_pubsub_token }) })); Expected Behavior Once configuration is complete, contacts and conversations created through the API appear in the Support Portal Dashboard identically to those from other channels. Agents can respond through the Dashboard, and those responses trigger webhook callbacks to your callback URL. All standard features — including labels, macros, and automation rules (see Automation) — apply. Governance Notes - Data responsibility: Because the API channel connects arbitrary external systems, your organization is responsible for ensuring that data transmitted through this channel complies with applicable privacy regulations. - Callback URL security: The callback endpoint should validate incoming requests to prevent unauthorized payloads. Consider implementing signature verification or IP allowlisting. - Token management: API access tokens grant broad permissions. Rotate tokens regularly and restrict their distribution to authorized systems. Store tokens securely and never expose them in client-side code.

Last updated on Feb 25, 2026

Deploy a Help Center Knowledge Base

Overview The Help Center in Support Portal by Altores provides a customer-facing knowledge base portal where your organization can publish self-service documentation, operational guides, and frequently referenced information. This reduces inbound support volume by enabling customers to resolve common inquiries independently. This article covers the complete deployment workflow: portal creation, category structure definition, and article authoring. Operational Objective Deploy a structured, publicly accessible Help Center portal within your Support Portal workspace, organized by categories and populated with published articles. Prerequisites - An active Support Portal workspace with administrative privileges - Content planned for initial publication (recommended but not required) Part I: Create a Portal Step 1: Initiate Portal Creation Navigate to the Help Center section using the sidebar navigation. Select the New Portal action to begin the portal provisioning process. Step 2: Configure Portal Settings The portal configuration interface presents the following parameters: | Parameter | Description | |-----------|-------------| | Logo | Upload your organization's logo. This appears in the portal header and establishes brand identity. | | Name | The internal name for the portal, used for identification within your workspace. | | Slug | Auto-generated URL path segment derived from the portal name. | | Custom Domain (optional) | Provide a custom domain if you intend to serve the portal at a branded URL (e.g., docs.yourorganization.com). See Configure SSL for a Help Center Custom Domain for SSL certificate configuration. | Select Create portal basic settings to provision the portal. The portal is now active and ready for content structure configuration. Part II: Define Category Structure Categories provide the organizational taxonomy for your Help Center content. Each article is assigned to a category, and categories are presented to visitors as navigational groupings. Step 1: Create a Category Select the + control adjacent to the Category section in the secondary sidebar to create a new category. Step 2: Configure Category Parameters A modal interface presents the following fields: | Parameter | Description | |-----------|-------------| | Name | The category title. This is displayed to visitors on the public portal. | | Slug | Auto-generated URL path segment derived from the category name. | | Description (optional) | A brief summary of the category scope. Assists visitors in navigating to relevant content. | Select Create category to save. Repeat this process to establish the full category structure for your portal. Part III: Author and Publish Articles Step 1: Create a New Article The New Article action is accessible from multiple locations within the Help Center interface. Select it to open the article editor. Step 2: Compose and Configure the Article The article editor provides a rich text composition environment. Use the sidebar panel to assign the following metadata: - Category -- The category under which the article is published - Author -- The team member attributed as the article author - Meta content -- SEO-relevant metadata for the article Use the Preview function to review the article as it will appear to visitors. When the content is finalized, select Publish to make the article publicly accessible. Expected Behavior Upon completion of all parts: - A publicly accessible Help Center portal is operational at the configured URL - Categories provide a structured navigation framework for visitors - Published articles are discoverable via category browsing and search - The portal can be further enhanced with a custom domain and SSL (see Configure SSL for a Help Center Custom Domain), embedded video content (see Embed Video Content in Help Center Articles), or integrated into your website via the Help Center widget (see Embedding Help Center Articles in the Live Chat Widget) Related Resources - Configure SSL for a Help Center Custom Domain -- Configure SSL for a custom domain on your Help Center - Embed Video Content in Help Center Articles -- Embed video content in Help Center articles - Embedding Help Center Articles in the Live Chat Widget -- Integrate the Help Center widget into your website

Last updated on Feb 25, 2026

Email Channel

Overview The Email channel enables your organization to manage inbound and outbound support email directly within Support Portal. Incoming messages create conversations that Agents can triage, assign, and resolve through the standard Dashboard interface. Support Portal supports three email ingestion methods — forwarding, IMAP polling, and Microsoft OAuth — along with SMTP for outbound delivery. Prerequisites - A dedicated support email address (e.g., [email protected]). - Access to the email provider's settings for configuring forwarding rules, IMAP, or SMTP. - For Gmail: IMAP access enabled in Gmail settings and, if two-factor authentication is active, an App Password generated for Support Portal. - For Microsoft/Outlook: OAuth credentials for the Microsoft account. - An active Support Portal account with permission to create Inboxes (see Adding Inboxes). Configuration Steps 1. Initiate Inbox Creation Navigate to Settings > Inboxes and select Add Inbox. 2. Select the Email Channel Type From the channel selection interface, select the Email icon. 3. Provide Channel Details Provide the required parameters: | Parameter | Description | |---|---| | Channel Name | A descriptive label for this Inbox (e.g., "Customer Support Email"). | | Email Address | The support email address customers will write to. | Microsoft users: If your organization uses Outlook or Microsoft 365 email, select the Microsoft provider option and follow the OAuth flow described in the Microsoft Email section below. Select Create Email Channel to proceed. 4. Assign Agents Add one or more Agents to the Inbox. Email Ingestion Methods After Inbox creation, navigate to Settings > Inboxes > [Email Inbox] > Configuration to configure how Support Portal receives email. Method A: Email Forwarding This is the simplest ingestion method. Support Portal provides a forwarding address that you configure as a forwarding target in your email provider. 1. Copy the Forward to email address displayed in the Configuration tab. 2. In your email provider's settings, add this address as a forwarding destination. 3. Complete any verification steps required by your provider (e.g., confirming a verification code). 4. Enable forwarding for all incoming messages or configure selective forwarding rules. Gmail Forwarding Setup 1. Open Gmail Settings (gear icon) and select See all settings. 2. Navigate to the Forwarding and POP/IMAP tab. 3. Select Add a forwarding address and provide the address from Support Portal. 4. Confirm the forwarding address using the verification code delivered to the Support Portal Inbox. 5. Select Forward a copy of incoming mail and configure the desired handling for the original message. Method B: IMAP Configuration IMAP polling allows Support Portal to directly retrieve messages from your email server at regular intervals. 1. Navigate to Settings > Inboxes > [Email Inbox] > Configuration. 2. Enable the IMAP configuration option. 3. Provide the required parameters: | Parameter | Description | |---|---| | Address | IMAP server hostname (e.g., imap.gmail.com). | | Port | IMAP port (typically 993 for SSL). | | Email | The email account username. | | Password | The account password or App Password. | Gmail IMAP Notes - IMAP must be explicitly enabled in Gmail: Gmail Settings > Forwarding and POP/IMAP > Enable IMAP. - For accounts with two-factor authentication, generate an App Password: Google Account > Security > App Passwords. Select "Mail" as the app, generate the password, and use it in the IMAP configuration. Method C: SMTP Configuration SMTP configuration enables Support Portal to send outbound replies from your email address. 1. Navigate to Settings > Inboxes > [Email Inbox] > Configuration. 2. Enable the SMTP configuration option. 3. Provide the required parameters: | Parameter | Description | |---|---| | Address | SMTP server hostname (e.g., smtp.gmail.com). | | Port | SMTP port (typically 587 for TLS). | | Email | The email account username. | | Password | The account password or App Password. | | Domain | The email domain for HELO/EHLO identification. | Microsoft Email Configuration Support Portal supports Microsoft OAuth for Outlook and Microsoft 365 email accounts, eliminating the need for manual IMAP/SMTP credential configuration. 1. During Inbox creation, select the Microsoft provider icon. 2. Provide your Outlook or Microsoft 365 email address. 3. Complete the Microsoft OAuth authentication flow, including granting Support Portal permission to read and send email on behalf of the account. 4. Assign Agents to the Inbox. IMAP and SMTP settings are configured automatically through the OAuth grant. Do not modify the default IMAP/SMTP values unless directed by your administrator. Token renewal: If the Microsoft OAuth access token expires, re-authorize the account by navigating to Settings > Inboxes > [Email Inbox] > Configuration and initiating the reauthorization flow. SPF, DKIM, and Email Authentication To ensure reliable outbound delivery and prevent spoofing, configure the following DNS records for your email domain: - SPF (Sender Policy Framework): Add an SPF record authorizing the SMTP server used by Support Portal to send on behalf of your domain. - DKIM (DomainKeys Identified Mail): If your email provider supports DKIM signing, ensure the appropriate public key is published as a DNS TXT record. - DMARC: Consider publishing a DMARC policy to instruct receiving servers how to handle messages that fail SPF or DKIM validation. Failure to configure these records may result in outbound messages being classified as spam or rejected by the recipient's mail server. Expected Behavior Once configuration is complete: - Inbound emails to the configured address create new conversations in the Support Portal Dashboard. - Agent replies sent through Support Portal are delivered to the customer's email address via the configured SMTP provider or Microsoft OAuth grant. - Email threads are grouped by conversation, maintaining full correspondence history. Governance Notes - Third-party data flow: Email content is transmitted between your email provider's servers and Support Portal. For IMAP/SMTP configurations, credentials are stored within your Support Portal instance. - Microsoft OAuth: When using Microsoft OAuth, Support Portal accesses email through Microsoft Graph API. Review Microsoft's data processing terms for compliance with your organization's policies. - Credential security: For IMAP/SMTP configurations, use App Passwords or service-specific tokens rather than primary account passwords. Rotate credentials periodically according to your organization's security policy. - Data retention: Email messages stored within Support Portal are subject to your instance's data retention policies. Coordinate with your email provider's retention settings to maintain consistent records.

Last updated on Feb 25, 2026

Embed Video Content in Help Center Articles

Overview The Help Center in Support Portal by Altores supports automatic embedding of video content from multiple hosting platforms. When you include a supported video URL in an article, the system automatically renders a responsive video player in place of the link, enabling customers to view instructional or explanatory content directly within the knowledge base. This capability is useful for supplementing text-based documentation with visual demonstrations, product walkthroughs, or recorded training sessions. Operational Objective Embed video content from supported hosting platforms into Help Center articles to enhance the self-service experience for customers accessing your knowledge base. Prerequisites - An active Help Center portal with at least one published or draft article (see Deploy a Help Center Knowledge Base) - Video content hosted on one of the supported platforms listed below Supported Video Platforms | Platform | URL Format | Obtaining the URL | |----------|-----------|-------------------| | YouTube | https://www.youtube.com/watch?v=VIDEO_ID or https://youtu.be/VIDEO_ID | Copy the URL from the browser address bar or use the Share function | | Vimeo | https://vimeo.com/VIDEO_ID | Copy the URL from the browser address bar or use the Share function | | Loom | https://loom.com/share/VIDEO_ID | Use the Share function after recording or from the video library | | Wistia | https://SUBDOMAIN.wistia.com/medias/VIDEO_ID | Copy the URL from the browser or use the Share & Embed function | | Arcade | https://app.arcade.software/share/VIDEO_ID | Use the Share function from your demo library | | Bunny CDN | https://iframe.mediadelivery.net/play/LIBRARY_ID/VIDEO_ID | Obtain the iframe URL from the Bunny CDN dashboard | | Direct MP4 | Any URL ending in .mp4 | Use a direct link to the MP4 file from any hosting service | Formatting Requirements For the automatic video embedding to function correctly, the following formatting conditions must be satisfied: 1. Isolation -- The video URL must appear on its own line. It must not be embedded within a paragraph or adjacent to other text on the same line. 2. Surrounding whitespace -- The URL must be preceded and followed by an empty line (a blank line above and below the URL). 3. Link formatting -- The URL must be formatted as a clickable link in Markdown. Plain-text URLs that are not rendered as links will not trigger the embedding behavior. 4. Exact URL pattern -- The URL must conform to one of the supported patterns listed in the table above. Modified, shortened, or non-standard URL formats may not be recognized. Correct Formatting Example This paragraph introduces the feature demonstration. [https://www.youtube.com/watch?v=example123](https://www.youtube.com/watch?v=example123) The following section continues with additional detail. Incorrect Formatting Example Watch this video: [https://www.youtube.com/watch?v=example123](https://www.youtube.com/watch?v=example123) for a quick overview. In the incorrect example, the URL is embedded within a paragraph rather than isolated on its own line, which prevents the embedding system from detecting it. Expected Behavior When the formatting requirements are met, the Support Portal rendering engine automatically detects the video URL pattern and replaces it with a responsive video player. The player: - Adapts to the width of the article content area - Functions across desktop and mobile browsers - Loads on demand to minimize page load impact - Displays platform-native playback controls Related Resources - Deploy a Help Center Knowledge Base -- Deploy a customer-facing Help Center portal - Configure SSL for a Help Center Custom Domain -- Configure SSL for a custom domain on your Help Center - Embedding Help Center Articles in the Live Chat Widget -- Integrate the Help Center widget into your website

Last updated on Feb 25, 2026

Embedding Help Center Articles in the Live Chat Widget

Overview Support Portal enables organizations to embed Help Center knowledge base articles directly within the live chat widget. This integration allows customers to search and access self-service content without leaving the chat interface, reducing conversation volume for common inquiries and improving time-to-resolution. Operational Objective Configure a live chat inbox to display Help Center articles within the customer-facing widget, enabling self-service access to your knowledge base alongside conversational support. Prerequisites - Administrator access to your Support Portal workspace. - A configured live chat inbox. - A Help Center with at least one published article. Refer to Deploy a Help Center Knowledge Base for Help Center configuration guidance. Procedure Step 1: Navigate to Inbox Settings From the Support Portal dashboard, navigate to Settings, then select Inbox Settings from the navigation bar. Step 2: Open Live Chat Inbox Configuration Locate your Live Chat inbox in the inbox list. Select the settings icon adjacent to the inbox name to open its configuration interface. Step 3: Configure the Help Center Integration Within the inbox configuration interface: 1. Scroll to the Help Center section. 2. Select the dropdown to display available Help Center instances. 3. Select the Help Center you want to embed in this inbox's widget. Step 4: Save the Configuration Select Update to persist the configuration change. A confirmation message indicates the update has been applied. Verification After completing the configuration: 1. Navigate to your website where the live chat widget is deployed, or use the widget preview within the dashboard. 2. Verify that the Help Center section is visible within the widget interface. 3. Confirm that articles are searchable and readable directly from the widget. Expected Behavior Once configured, customers interacting with the live chat widget can: - Browse Help Center categories and articles within the widget. - Search for articles by keyword. - Read full article content without leaving the chat interface. - Transition seamlessly from self-service browsing to a live conversation with an operator if their question is not resolved by the available articles.

Last updated on Feb 25, 2026

Facebook Messenger Channel

Overview The Facebook Messenger channel enables your organization to receive and respond to customer messages sent through a Facebook Page directly within Support Portal. Once connected, all Messenger conversations surface as standard Inbox conversations, supporting agent assignment, automation rules, and CSAT collection. Prerequisites - A Facebook Page with admin-level access. - A Facebook account authorized to manage the target Page. - An active Support Portal account with permission to create Inboxes (see Adding Inboxes). Configuration Steps 1. Initiate Inbox Creation Navigate to Settings > Inboxes and select Add Inbox. 2. Select the Messenger Channel Type From the channel selection interface, select the Messenger icon. 3. Authenticate with Facebook Select the Sign in with Facebook button. A new browser window opens for OAuth authentication. 4. Authorize Permissions Authenticate with the Facebook account that administers the target Page. When prompted, select the Page you wish to connect and grant all requested permissions. These permissions allow Support Portal to read and respond to Messenger conversations on behalf of your Page. 5. Select the Facebook Page After authorization, the configuration interface presents a dropdown of available Pages. Select the Page you wish to connect to this Inbox. 6. Assign Agents Add one or more Agents to the Inbox. Only assigned Agents will have visibility into conversations arriving through this channel. Post-Configuration Settings Once the Inbox is created, navigate to Settings > Inboxes and select the gear icon on the Facebook Messenger Inbox to access additional configuration. Settings Tab - Channel greeting: When enabled, Support Portal sends a configurable greeting message to new conversations initiated through this Inbox. - CSAT: When enabled, a Customer Satisfaction survey is dispatched each time a conversation is resolved. Results are available in the Reports section (see Customer Satisfaction (CSAT) Surveys). - Reauthorize: If the Facebook OAuth token expires or permissions change, use this control to re-authenticate. Collaborators Tab Manage Agent assignments for this Inbox. You may also enable or disable automatic conversation assignment, which distributes new conversations to available Agents in a round-robin pattern. Business Hours Tab Define the operational hours for the team associated with this Inbox. When business availability is enabled and a message arrives outside defined hours, Support Portal delivers a configurable unavailability message to the customer. Note: If an AI assistant is enabled on the Inbox, the unavailability message is suppressed. The AI assistant handles conversations directly, including those arriving outside business hours, unless it transfers the conversation to a human Agent. Expected Behavior Once configuration is complete, any message sent by a customer to the connected Facebook Page via Messenger creates a new conversation in the Support Portal Dashboard. Agents can respond in real time, and all standard features — including labels, macros, and automation rules (see Automation) — apply to these conversations. Governance Notes - Third-party data flow: All Messenger conversations are routed through Meta's Graph API. Message content, sender identity, and metadata are transmitted between Meta's infrastructure and your Support Portal instance. - Token lifecycle: Facebook OAuth tokens have a limited validity period. Monitor the Inbox settings for reauthorization prompts to avoid service interruptions. - Compliance: Organizations subject to data residency or retention requirements should review Meta's data processing terms in conjunction with their own policies before enabling this channel.

Last updated on Feb 25, 2026

Identity Validation via HMAC Verification

Support Portal provides an HMAC-based identity validation mechanism that cryptographically verifies the identity of visitors interacting with the live chat widget. When enabled, this feature ensures that a visitor claiming to be a particular user has been authenticated by your backend systems — preventing impersonation, session hijacking, and unauthorized access to conversation history. Operational objective In any deployment where the live chat widget serves authenticated users — logged-in customers on a telecom self-service portal, citizens accessing a government digital service, employees using an internal operations dashboard — there is a risk that a malicious actor could forge a visitor identity and gain access to another user's conversation history or personal data. Identity validation eliminates this risk by requiring a server-generated cryptographic signature before the platform accepts a visitor's claimed identity. This is particularly critical in regulated environments. A government portal handling citizen inquiries about tax records or permit applications must guarantee that conversation history is only accessible to the authenticated individual. A telecom operator exposing account details through live chat — billing information, service plans, device IMEI numbers — must prevent one subscriber from impersonating another. HMAC-based identity validation provides this guarantee at the protocol level, without relying on client-side trust alone. How HMAC verification works The verification process follows a challenge-response pattern involving three parties: your backend server, the visitor's browser, and the Support Portal platform. Your server generates a signature. When an authenticated user loads a page containing the live chat widget, your backend computes an HMAC-SHA256 hash of the user's unique identifier (typically their email address) using a secret token that only your server and the Support Portal platform share. The browser passes the signature to the widget. Your frontend code provides the user's identifier and the computed HMAC hash to the widget SDK via the window.$chatwoot.setUser method. The widget transmits both values to the platform. The platform independently verifies the signature. Support Portal computes the same HMAC-SHA256 hash using its copy of the shared secret and the identifier received from the widget. If the hash matches the one provided by the browser, the visitor's identity is confirmed. If it does not match, the identity claim is rejected — the visitor is treated as unverified, and no prior conversation history is exposed. Because the shared secret never leaves the server side, a client cannot forge a valid signature. Even if an attacker intercepts the identifier and hash for one user, they cannot generate a valid hash for a different user without access to the secret token. Retrieving the HMAC token Each website inbox has its own unique HMAC token. To retrieve it, navigate to Settings > Inboxes, select the relevant website inbox, and open the Configuration tab. The identity validation section displays the token used for HMAC generation. Copy this token and store it securely in your backend configuration — environment variables or a secrets manager are appropriate storage mechanisms. This token must never be exposed in client-side code, embedded in JavaScript bundles, or committed to version control repositories. Treat it with the same sensitivity as an API secret key. For deployments spanning multiple website inboxes — for example, a telecom operator with separate inboxes for consumer support, dealer support, and enterprise accounts — each inbox has a distinct HMAC token. Your backend must use the correct token for the inbox associated with each web property. Generating the HMAC hash (server-side) The HMAC hash must be computed on your server for each authenticated user session. The inputs are the user's unique identifier (the value you will pass as the identifier to the widget SDK) and the HMAC token retrieved from the inbox configuration. The output is a hexadecimal SHA-256 HMAC digest. Below are reference implementations in commonly used server-side languages. PHP <?php $key = '<webwidget-hmac-token>'; $message = '<identifier>'; $identifier_hash = hash_hmac('sha256', $message, $key); ?> Node.js const crypto = require("crypto"); const key = "<webwidget-hmac-token>"; const message = "<identifier>"; const hash = crypto.createHmac("sha256", key).update(message).digest("hex"); Ruby require 'openssl' key = '<webwidget-hmac-token>' message = '<identifier>' OpenSSL::HMAC.hexdigest('sha256', key, message) Python import hashlib import hmac secret = bytes('<webwidget-hmac-token>', 'utf-8') message = bytes('<identifier>', 'utf-8') hash = hmac.new(secret, message, hashlib.sha256) hash.hexdigest() Go package main import ( "crypto/hmac" "crypto/sha256" "encoding/hex" ) func main() { secret := []byte("<webwidget-hmac-token>") message := []byte("<identifier>") hash := hmac.New(sha256.New, secret) hash.Write(message) hex.EncodeToString(hash.Sum(nil)) } Elixir key = '<webwidget-hmac-token>' message = '<identifier>' signature = :crypto.mac(:hmac, :sha256, key, message) Base.encode16(signature, case: :lower) In each example, replace <webwidget-hmac-token> with the token copied from the inbox configuration and <identifier> with the authenticated user's unique identifier — typically their email address. Passing identity data to the widget SDK Once your server has generated the HMAC hash, your frontend code must pass both the identifier and the hash to the live chat widget. This is done through the window.$chatwoot.setUser method, which accepts the user's identifier as the first argument and a data object containing the hash as the second. window.$chatwoot.setUser("<identifier>", { identifier_hash: "<hmac-hash-generated-server-side>", name: "Jane Citizen", email: "[email protected]", }); The identifier_hash field is the critical security parameter — it carries the HMAC digest that the platform uses for verification. The name and email fields are optional metadata that populate the contact record within Support Portal. A common implementation pattern is to render the HMAC hash into a data attribute or inline script variable during server-side page rendering, then reference it in the client-side widget initialization code. This keeps the secret token on the server while making the computed hash available to the browser. When identity validation is active and a visitor's HMAC hash is successfully verified, the platform displays a verification indicator on the contact record. Agents can use this indicator to confirm that the visitor has been authenticated by the organization's backend systems before sharing sensitive information. What happens when validation fails If the HMAC hash provided by the browser does not match the hash computed by the platform — due to a mismatched token, an incorrect identifier, or a deliberate forgery attempt — the visitor's identity claim is rejected. The platform treats the visitor as an unauthenticated guest, and no prior conversation history associated with the claimed identifier is loaded. This fail-closed behavior is deliberate. In security-sensitive deployments, it is preferable to deny access and require re-authentication rather than risk exposing another user's conversation records to an unverified party. Governance and compliance considerations Impersonation prevention in regulated channels. For government digital services, identity validation provides a verifiable chain of trust: the citizen authenticates through the government identity provider, the backend generates a cryptographic proof, and the support platform independently verifies it. This chain is auditable and does not rely on client-side assertions alone. Telecom subscriber protection. Telecom operators using live chat for account management — SIM swaps, plan changes, billing inquiries — face regulatory requirements around subscriber identity verification. HMAC-based validation integrates naturally with existing authentication flows (SSO, two-factor authentication) and provides a defense-in-depth layer that operates independently of the primary session management system. Data isolation assurance. In multi-tenant deployments where a single Support Portal workspace serves multiple user populations, identity validation ensures that conversation history is compartmentalized per verified identity. Combined with the per-inbox HMAC token model, this provides organizational assurance that cross-user data leakage through the live chat channel is structurally prevented. For additional configuration of the live chat widget, including pre-chat forms, business hours, and visual customization, see Live Chat Widget Configuration. For SDK deployment options and parameter reference, see Sdk Setup.

Last updated on Feb 25, 2026

Instagram Channel

Overview The Instagram channel connects an Instagram Business Account to Support Portal, enabling your team to receive and respond to Instagram Direct Messages through the standard Dashboard interface. Support Portal offers two authentication methods for connecting Instagram: - Instagram Business Login (recommended) — a streamlined OAuth flow that authenticates directly with Instagram. - Meta Business Login (legacy) — authenticates through Facebook and requires your Instagram account to be linked to a Facebook Page. Instagram Business Login is the preferred method and provides a simpler configuration experience. Prerequisites - An Instagram Business Account. If you do not have one, convert your existing account using Instagram's Business Account setup guide. - For Meta Business Login only: A Facebook Page connected to your Instagram Business Account. Link them through your Facebook Page settings under the Instagram section. - An active Support Portal account with permission to create Inboxes (see Adding Inboxes). Method 1: Instagram Business Login (Recommended) 1. Initiate Inbox Creation Navigate to Settings > Inboxes and select Add Inbox. 2. Select the Instagram Channel Type From the channel selection interface, select the Instagram icon. 3. Authenticate with Instagram Select Continue with Instagram. You are redirected to Instagram's authorization interface. 4. Grant Permissions On the Instagram authorization page, enable Access and manage messages and select Allow to complete authorization. This grants Support Portal the necessary permissions to read and respond to Direct Messages on behalf of your Business Account. 5. Assign Agents After authorization, you are redirected back to Support Portal. Add one or more Agents to the Instagram Inbox. Method 2: Meta Business Login (Legacy) Note: This method authenticates through Facebook rather than directly through Instagram. Instagram Business Login (Method 1) is the recommended approach. 1. Connect Instagram to a Facebook Page Before configuring this method, ensure your Instagram Business Account is linked to a Facebook Page: 1. Navigate to your Facebook Page settings. 2. Select Instagram from the settings menu. 3. Connect your Instagram Business Account. 2. Initiate Inbox Creation Navigate to Settings > Inboxes and select Add Inbox. 3. Select the Messenger Channel Type From the channel selection interface, select the Messenger icon. The Instagram connection is established through the Facebook Messenger integration path when using Meta Business Login. 4. Authenticate with Facebook Select the Sign in with Facebook button. A new browser window opens for authentication. 5. Authorize and Select Accounts Authenticate with the Facebook account that manages the linked Page. When prompted: 1. Select the Instagram account you wish to connect. 2. Select the associated Facebook Page. 3. Grant all requested permissions to ensure full messaging functionality. 6. Assign Agents Add one or more Agents to the Inbox. Expected Behavior Once configuration is complete, Direct Messages sent to your Instagram Business Account create new conversations in the Support Portal Dashboard. Agents can respond directly, and all standard features — including labels, macros, and automation rules (see Automation) — apply. Governance Notes - Third-party data flow: All Instagram messages are transmitted through Meta's APIs (Instagram Graph API or Messenger Platform). Message content, sender identity, and media attachments are exchanged between Meta's infrastructure and your Support Portal instance. - Authentication method migration: Instagram Business Login is the preferred path. The Meta Business Login method may be deprecated in future releases. Plan to migrate existing Inboxes to the Instagram Business Login method when feasible. - Token lifecycle: OAuth tokens issued through either authentication method have a limited validity period. Monitor the Inbox settings for reauthorization prompts to avoid service interruptions. - Compliance: Organizations subject to data privacy regulations should review Meta's Platform Terms and data processing agreements before enabling this channel.

Last updated on Feb 25, 2026

Locating Your Personal Access Token

Overview Support Portal provides a comprehensive API that enables programmatic access to workspace data, conversation management, contact operations, and platform configuration. All API requests require authentication via a Personal Access Token. This token uniquely identifies the authenticated user and grants API access scoped to the permissions associated with that user's role. Operational Objective Locate and retrieve your Personal Access Token from the Support Portal dashboard to authenticate API requests for integration development, automation workflows, or third-party system connectivity. Prerequisites - Administrator privileges on your Support Portal workspace. Procedure Step 1: Access Your Profile Select your avatar in the lower-left corner of the dashboard to open the profile menu. Step 2: Open Profile Settings From the profile menu, select Profile Settings to access your profile configuration. Step 3: Retrieve the Access Token Scroll to the bottom of the Profile Settings page. The Personal Access Token field displays your token value. Using Your Access Token Include the token in the api_access_token parameter or the Authorization header of your API requests: curl -H "api_access_token: YOUR_TOKEN_HERE" \ https://your-instance.com/api/v1/profile Security Considerations Your Personal Access Token provides the same level of access as your authenticated dashboard session. Observe the following security practices: - Do not share your token publicly or embed it in client-side code. - Do not commit your token to version control repositories. - Rotate your token immediately if you suspect it has been compromised. - Scope access by using tokens associated with accounts that have the minimum required permissions for the integration. For API documentation and endpoint references, consult the Support Portal API documentation provided by Altores.

Last updated on Feb 25, 2026

Passing Visitor Identity Data Through the SDK

When the live chat widget is deployed on an authenticated web property, Support Portal can receive structured identity data about the visitor through the SDK. This enables the platform to associate conversations with known contacts, enrich the agent's sidebar with contextual information, and enforce identity verification through HMAC validation. For telecom self-service portals, government citizen accounts, or enterprise customer dashboards, passing identity data transforms the widget from an anonymous channel into an authenticated communication layer tied to your existing user directory. Operational objective Without identity data, every widget session is treated as a new anonymous visitor. Agents must ask for identifying details manually, and conversation history cannot persist across sessions. By transmitting identity data through the SDK, organizations achieve several operational outcomes: conversations are linked to a persistent contact record, returning visitors see their prior history, agents receive subscriber or account context before the first message, and HMAC validation prevents impersonation. In regulated environments — where audit trails require a verifiable link between a conversation and an authenticated user — SDK-level identity binding is a deployment requirement rather than an optional enhancement. SDK readiness Before calling any identity methods, the widget script must be fully loaded. The SDK exposes window.$chatwoot as the primary interface object, but it is only available after initialization completes. Listen for the chatwoot:ready event to ensure that all subsequent SDK calls execute reliably: window.addEventListener("chatwoot:ready", function () { // window.$chatwoot is now available }); All identity-related SDK calls described in this article — setUser, setCustomAttributes, and reset — must be invoked inside this event handler or after it has fired. Calling these methods before the SDK is ready will result in silent failures. Identifying visitors with setUser The setUser method binds the current widget session to a known identity. It accepts a unique identifier as the first argument and an object of profile fields as the second: window.$chatwoot.setUser("subscriber-88421", { email: "[email protected]", name: "J. Müller", phone_number: "+49 170 555 0199", avatar_url: "https://portal.example.gov/avatars/88421.png", }); The unique identifier (first argument) should be a stable value from your user directory — a database primary key, subscriber ID, or account reference number. Support Portal uses this identifier to match the session to an existing contact record or create a new one. Available profile fields The following fields are supported in the profile object passed to setUser: | Field | Type | Description | |---|---|---| | email | String | Primary email address. Used for contact matching and follow-up notifications. | | name | String | Display name shown to agents in the conversation sidebar. | | phone_number | String | Contact phone number, including country code. | | avatar_url | String | URL to a profile image displayed alongside the contact record. | | description | String | Freeform text providing additional context about the user (e.g., account type or department). | | company_name | String | Organization or company the contact is affiliated with. | | country_code | String | Two-letter ISO 3166-1 country code (e.g., DE, NL, US). | | city | String | City of residence or primary location. | | social_profiles | Object | An object containing optional social media handles with keys: twitter, linkedin, facebook, github. | All fields are optional. Only fields with non-empty values are written to the contact record. Enterprise example: telecom subscriber identification In a telecom self-service portal, the authenticated session typically contains subscriber metadata. Passing this data through setUser allows agents to see the subscriber's plan, region, and account status before the conversation begins: window.addEventListener("chatwoot:ready", function () { window.$chatwoot.setUser(currentUser.subscriberId, { email: currentUser.email, name: currentUser.displayName, phone_number: currentUser.msisdn, company_name: "Residential", description: "Fiber 100 — Active since 2021", country_code: "NL", city: currentUser.serviceCity, }); }); This pattern eliminates the need for the pre-chat form on authenticated portals, since the identity is already established by the host application's session. Identity verification with HMAC In production deployments, passing identity data without verification allows any client-side script to impersonate a user by supplying a fabricated identifier. HMAC-based identity validation prevents this by requiring a server-generated signature alongside each setUser call. The identifier_hash field carries an HMAC-SHA256 signature computed on your backend using the widget's HMAC token (available in the inbox configuration) and the user's unique identifier: window.$chatwoot.setUser("subscriber-88421", { name: "J. Müller", email: "[email protected]", identifier_hash: "a]5f2c...server-generated-hmac-hash", phone_number: "+49 170 555 0199", }); When identifier_hash is present, Support Portal validates the signature before accepting the identity binding. If the hash does not match, the session is treated as unverified. Enabling HMAC validation also activates conversation history persistence — authenticated visitors returning to the site will see their previous conversations. For details on generating the HMAC token and implementing server-side signature logic, see Identity Validation via HMAC Verification. In regulated environments — government portals handling citizen data, telecom operators subject to identity verification mandates — HMAC validation is strongly recommended. It provides a cryptographic guarantee that the identity presented to agents matches the authenticated session on the host application. Full setUser call with HMAC and social profiles The following example demonstrates a comprehensive setUser invocation that includes identity verification, demographic fields, and social profile links: window.$chatwoot.setUser("acct-2947-eu", { name: "Elisa Korhonen", email: "[email protected]", identifier_hash: "b8d91e...server-generated-hmac", phone_number: "+358 50 123 4567", description: "Enterprise contract — Platinum SLA", company_name: "Nordic Logistics Oy", country_code: "FI", city: "Helsinki", avatar_url: "https://portal.enterprise.fi/photos/2947.jpg", social_profiles: { linkedin: "elisakorhonen", twitter: "e_korhonen", }, }); Setting custom attributes Beyond the standard profile fields, your deployment may need to surface domain-specific data in the agent's sidebar — contract tier, device model, subscription status, or internal case reference numbers. The setCustomAttributes method attaches arbitrary key-value pairs to the current conversation's contact record: window.$chatwoot.setCustomAttributes({ subscriptionTier: "Enterprise", contractId: "CT-2024-88421", deviceModel: "Nokia XR30", provisioningRegion: "EU-West", }); Custom attribute keys must correspond to attributes defined in Settings > Custom Attributes. If a key does not match an existing custom attribute definition, it will still appear as a conversation-level attribute but will not be indexed or filterable. See Custom Attributes for guidance on defining custom attributes in the platform. Custom attributes support String, Number, and Date value types. The type must match the definition configured in the platform — passing a string value to a number-type attribute will result in a type mismatch. Removing a custom attribute To remove a specific custom attribute from the current contact, use the deleteCustomAttribute method with the attribute key: window.$chatwoot.deleteCustomAttribute("provisioningRegion"); This is useful when session context changes — for example, when a subscriber navigates from a device management section to a billing section and the device-specific attributes are no longer relevant. When to call setUser The timing of the setUser call depends on your application's authentication flow. On page load (authenticated portals) — If the host application requires authentication before the user reaches the page with the widget, call setUser immediately inside the chatwoot:ready handler. This is the most common pattern for enterprise and government portals where the session is already established. After login (single-page applications) — In applications where authentication occurs after the initial page load — such as SPAs with deferred login flows — call setUser after the authentication callback completes. The widget will transition from an anonymous session to an identified one without requiring a page reload. Conditional identification — Some deployments intentionally allow anonymous browsing with the option to identify later. In this pattern, the widget loads without identity data, and setUser is called only when the visitor explicitly signs in or provides identifying information through the application's own UI. In all cases, setUser should be called only once per session. Calling it multiple times with different identifiers within the same page lifecycle may produce unpredictable contact matching behavior. Resetting the session When a visitor signs out of your application, the widget session must be reset to prevent the next user on the same device from inheriting the previous visitor's identity and conversation history. Call the reset method as part of your application's logout flow: window.$chatwoot.reset(); This clears the identity binding, removes any custom attributes associated with the session, and returns the widget to an anonymous state. If a new user subsequently signs in, a fresh setUser call establishes the new identity. Failing to reset on logout is a data hygiene risk, particularly in shared-device environments common in government offices, retail locations, and call center workstations. In these contexts, the reset call should be treated as mandatory rather than optional. Listening for widget events The SDK emits events that can be used to coordinate identity data transmission with widget activity. Beyond the chatwoot:ready event (required before any SDK call), the following events support operational monitoring: Message events — To capture inbound messages from the widget for logging or analytics integration: window.addEventListener("chatwoot:on-message", function (e) { console.log("Message received:", e.detail); }); Error events — To detect and log widget-level errors during operation: window.addEventListener("chatwoot:error", function (e) { // Forward to your application's error tracking service }); These event listeners are independent of identity data but are frequently deployed alongside setUser as part of a comprehensive SDK integration. Deployment checklist Before promoting an identity-enabled widget deployment to production, verify the following: - The setUser call executes inside the chatwoot:ready handler or after the event has fired. - The unique identifier used in setUser is stable and does not change across sessions for the same user. - HMAC identity validation is enabled and the identifier_hash is generated server-side — never expose the HMAC token in client-side code. - Custom attribute keys passed to setCustomAttributes match definitions in Settings > Custom Attributes. - The reset method is called on user logout, particularly in shared-device environments. - Widget error events are monitored in production to detect silent failures in identity binding. For widget configuration options beyond identity data — including visual customization, dark mode, business hours, and pre-chat forms — see Live Chat Widget Configuration.

Last updated on Feb 25, 2026

SMS Channel

Overview The SMS channel enables your organization to send and receive text messages through Support Portal using Twilio as the underlying carrier API. Once configured, inbound SMS messages create conversations in the Dashboard, and Agents can respond directly. Support Portal also supports Bandwidth as an alternative SMS provider. Prerequisites - A Twilio account with an active SMS-capable phone number. If you do not have an account, register at twilio.com. - The following Twilio credentials: Account SID, Auth Token, and the phone number provisioned for SMS. - An active Support Portal account with permission to create Inboxes (see Adding Inboxes). Configuration Steps 1. Initiate Inbox Creation Navigate to Settings > Inboxes and select Add Inbox. 2. Select the SMS Channel Type From the channel selection interface, select the SMS icon. 3. Choose the API Provider Select Twilio from the provider dropdown. 4. Provide Twilio Credentials The configuration interface presents the following fields: | Parameter | Source | |---|---| | Account SID | Twilio Console — Account Info section. | | Auth Token | Twilio Console — Account Info section. | | Phone Number | The Twilio phone number in E.164 format (e.g., +15551234567). | Select Create Twilio Channel to proceed. 5. Assign Agents Add one or more Agents to the Inbox. 6. Configure the Webhook in Twilio After Inbox creation, navigate to Settings > Inboxes > [SMS Inbox] > Configuration and copy the webhook URL. In the Twilio Console: 1. Navigate to the phone number's configuration page. 2. Under the Messaging section, provide the webhook URL from Support Portal as the destination for incoming messages. 3. Save the configuration. Bandwidth Provider (Alternative) Support Portal also supports Bandwidth as an SMS provider. When selecting Bandwidth from the provider dropdown, the configuration interface presents provider-specific credential fields. Complete the required fields and proceed with the standard Inbox creation workflow. Twilio Studio Integration If your organization uses Twilio Studio for custom conversation flows, updating the webhook URL directly may disrupt existing Studio flows. Instead, configure an agent handoff within your Studio flow: 1. Identify the step in your flow where agent handoff should occur. 2. Add an HTTP Request widget configured to POST to the Support Portal webhook URL. 3. Ensure the flow handles subsequent user responses to agent replies appropriately. Expected Behavior Once configuration is complete, inbound SMS messages to the configured phone number create new conversations in the Support Portal Dashboard. Agent replies are delivered to the customer's mobile number through the Twilio API. All standard features — including labels, macros, and automation rules (see Automation) — apply. Governance Notes - Third-party data flow: All SMS messages are transmitted through the Twilio (or Bandwidth) API. Message content, phone numbers, and delivery metadata are exchanged between the carrier provider's infrastructure and your Support Portal instance. - Regulatory compliance: SMS communications are subject to carrier regulations (e.g., TCPA in the United States, GDPR in the European Union). Ensure your SMS usage complies with opt-in/opt-out requirements, message frequency limits, and applicable data protection legislation. - Cost implications: SMS messages incur per-message charges through your Twilio (or Bandwidth) account. Monitor usage through the provider's billing dashboard. - Number portability: If you migrate SMS providers, coordinate number porting to maintain continuity of service.

Last updated on Feb 25, 2026

Telegram Channel

Overview The Telegram channel connects a Telegram Bot to Support Portal, enabling your team to receive and respond to customer messages sent through Telegram. Support Portal supports both standard Telegram Bots and Telegram Business Bots, each operating under different messaging constraints. Prerequisites - A Telegram Bot created through BotFather, with the API token available. - For Business Bot mode: the bot must have Business Mode enabled via BotFather (/business_mode command). - An active Support Portal account with permission to create Inboxes (see Adding Inboxes). Configuration Steps 1. Initiate Inbox Creation Navigate to Settings > Inboxes and select Add Inbox. 2. Select the Telegram Channel Type From the channel selection interface, select the Telegram icon. 3. Create a Telegram Bot If you have not already done so, open BotFather in Telegram and create a new bot. Copy the API token provided upon bot creation. 4. Provide the Bot API Token In the Inbox creation interface, provide the API token for your Telegram bot and select Create Telegram Channel. 5. Assign Agents Add one or more Agents to the Inbox. 6. Verify Inbox Configuration After creation, navigate to the Inbox settings page and confirm the Inbox name matches the bot username registered through BotFather. Telegram Business Bot Configuration Support Portal supports Telegram Business-mode bots, which allow customer conversations to be handled through a business account rather than a standard bot persona. Enabling Business Mode 1. In BotFather, run /business_mode, select your bot, and confirm activation. 2. Create a new Telegram Inbox in Support Portal using the same bot token. Support Portal automatically detects Business Mode and registers the appropriate webhook. 3. For clarity, maintain a dedicated Inbox for your Business Bot, separate from any standard bot Inboxes. Business Bot Constraints - 24-hour reply window: Telegram permits responses only within 24 hours of the customer's last message. - Bot identity conflicts: If a user has previously interacted with the same bot outside Business Mode, replies may appear to originate from the bot rather than the business account. Using a dedicated Business Bot avoids this behavior. - Limited feature set: The Telegram Business API currently supports fewer message types and does not include features such as typing indicators. Expected Behavior Once configuration is complete, any message sent by a user to the connected Telegram Bot creates a new conversation in the Support Portal Dashboard. Agents can respond directly, and standard features — including labels, macros, and automation rules (see Automation) — apply. To verify the integration, send a test message to the bot from a Telegram account and confirm the conversation appears in the corresponding Inbox. Governance Notes - Third-party data flow: All Telegram messages are transmitted through the Telegram Bot API. Message content, sender metadata, and media attachments are exchanged between Telegram's servers and your Support Portal instance. - Webhook security: Support Portal registers a webhook with Telegram automatically during Inbox creation. Ensure your instance is accessible over HTTPS for webhook delivery. - Data retention: Telegram does not guarantee indefinite storage of bot messages. Consult Telegram's Bot API documentation for current data lifecycle policies.

Last updated on Feb 25, 2026

WhatsApp Channel

Overview The WhatsApp channel enables your organization to manage WhatsApp Business conversations directly within Support Portal. Support Portal provides three methods for connecting a WhatsApp Business number, each suited to different organizational requirements: | Method | Best For | |---|---| | Embedded Signup (recommended) | Organizations adding a new WhatsApp number with minimal configuration. | | Twilio | Organizations already using Twilio for messaging infrastructure. | | Manual Cloud API | Technical teams, BSPs, or scenarios requiring direct Meta Developer Console configuration. | All three methods deliver the same end-user experience within Support Portal once configured. Prerequisites - A Meta (Facebook) Business Account or a Twilio account (depending on the chosen method). - A valid phone number not already registered with another WhatsApp Business Account (unless migrating). - An active Support Portal account with permission to create Inboxes (see Adding Inboxes). WhatsApp Messaging Constraints Before configuring any method, understand the following platform constraints that apply to all WhatsApp Business integrations: - 24-hour session window: After a customer sends a message, your organization has 24 hours to respond with free-form messages. After this window closes, only pre-approved template messages may be sent. - Template messaging: Messages sent outside the 24-hour window must use templates approved by Meta. Templates are managed through the Meta Business Manager or your BSP's interface. - Business verification: Meta requires business verification for production access. Prepare legal documentation for submission during or after account setup. - Display name review: The WhatsApp display name must comply with Meta's branding guidelines. Non-compliant names are rejected during verification. Method 1: Embedded Signup (Recommended) Embedded Signup is a browser-based interface provided by Meta that authenticates your Facebook account, creates or links a WhatsApp Business Account (WABA), registers a phone number, and returns production credentials — all in a single guided flow. No manual token generation or webhook configuration is required. Configuration Steps 1. Initiate Inbox Creation Navigate to Settings > Inboxes and select Add Inbox. Select WhatsApp as the channel type. 2. Start the Embedded Signup Flow Select Connect with WhatsApp Business. This initiates Meta's Embedded Signup interface. 3. Complete the Meta Authentication Flow In the Embedded Signup window: 1. Authenticate with the Facebook account that will manage the WABA. 2. Provide business details or select an existing Meta Business portfolio. 3. Select an existing WABA or create a new one. 4. Register and verify your phone number via OTP. Support Portal automatically receives the webhook configuration, access tokens, and phone number details upon completion. Tip: Use a dedicated browser tab and disable ad-blockers during this process. Meta's OAuth windows rely on third-party cookies. 4. Assign Agents Add one or more Agents to the WhatsApp Inbox. Compliance Checkpoints - Business verification: Upload legal documents if Meta prompts during or after signup. - Display name review: Ensure the WhatsApp display name aligns with Meta's branding guidelines to prevent rejection. Method 2: Twilio This method connects WhatsApp through Twilio's messaging platform. Twilio manages the WhatsApp Business API connection and message routing on your behalf. Configuration Steps 1. Prepare Twilio Credentials Log into the Twilio Console and note the following: | Parameter | Location | |---|---| | Account SID | Twilio Console — Account Info. | | Auth Token | Twilio Console — Account Info. | | WhatsApp Number | The Twilio phone number enabled for WhatsApp, in E.164 format. | If you have not yet associated a phone number with WhatsApp through Twilio, complete that process before proceeding. 2. Initiate Inbox Creation Navigate to Settings > Inboxes and select Add Inbox. Select WhatsApp as the channel type, then choose Twilio as the provider. 3. Provide Twilio Credentials Provide the Account SID, Auth Token, and WhatsApp number in the configuration form. Select Create Twilio Channel. 4. Assign Agents Add one or more Agents to the Inbox. 5. Configure the Webhook in Twilio After Inbox creation, navigate to Settings > Inboxes > [WhatsApp Inbox] > Configuration and copy the webhook URL. In the Twilio Console, navigate to the WhatsApp-enabled number's configuration and provide the webhook URL as the inbound message destination. Save the configuration. Twilio Messaging Service (Optional) If your organization uses Twilio Messaging Services for advanced routing: 1. In the Twilio Console, navigate to Messaging > Services and create a Messaging Service (or select an existing one). 2. Record the Messaging Service SID. 3. In Support Portal, during Inbox creation, enable the Use Twilio Messaging Service option and provide the Account SID, Messaging Service SID, and Auth Token. 4. In the Twilio Console, navigate to the Messaging Service's Integration settings and provide the Support Portal webhook URL. Twilio Studio Integration If your organization uses Twilio Studio for custom conversation flows, configuring the webhook URL directly on the phone number will disrupt existing Studio flows. Instead: 1. Identify the step in your Studio flow where agent handoff should occur. 2. Add an HTTP Request widget configured to POST to the Support Portal webhook URL. 3. Ensure the flow correctly handles subsequent user responses to agent replies. Template Limitations Support Portal does not currently support WhatsApp template management through Twilio. Templates must be managed directly within the Twilio Console. Method 3: Manual Cloud API Setup This method provides direct integration with the WhatsApp Cloud API through the Meta Developer Console. It requires creating a Facebook App, generating a permanent access token, configuring a webhook, and providing credentials to Support Portal manually. Configuration Steps 1. Create a Meta Business Portfolio Log into Meta Business Suite and create a business portfolio (or select an existing one). Complete all required business information fields. 2. Create a Facebook App Log into the Meta Developer Console and create a new app: 1. Select Other as the app category. 2. Choose Business as the app type. 3. Provide your contact email and associate the app with your business portfolio. 3. Add WhatsApp to the App From the app dashboard, select Add Product and choose WhatsApp. Select Set up to begin WhatsApp API configuration. Note: Meta requires business verification for production API access. Submit verification documentation before proceeding to production use. 4. Generate a Permanent Access Token Temporary tokens expire and should not be used in production. Create a System User with a permanent token: 1. Navigate to Meta Business Settings > System Users. 2. Create a new System User with the Admin role. 3. Select Add Assets, choose your app, grant Full Control, and assign the assets. 4. Generate a new token for the System User, selecting the following permissions: - whatsapp_business_manage_events - whatsapp_business_management - whatsapp_business_messaging 5. Copy and securely store the generated token. 5. Register and Verify a Phone Number In the Meta Developer Console's WhatsApp configuration: 1. Add a production-ready phone number. 2. Complete phone number verification via OTP. 6. Connect to Support Portal 1. In the Meta Developer Console, locate and copy the Phone Number ID and Business Account ID. 2. In Support Portal, navigate to Settings > Inboxes > Add Inbox and select WhatsApp. 3. Provide the phone number, Phone Number ID, Business Account ID, and the permanent access token generated in Step 4. 7. Assign Agents Add one or more Agents to the Inbox. 8. Configure the Webhook After Inbox creation, navigate to Settings > Inboxes > [WhatsApp Inbox] > Configuration and copy the webhook URL and verification token. In the Meta Developer Console: 1. Navigate to WhatsApp > Configuration. 2. Provide the webhook URL and verification token. 3. Select Verify and Save. 4. Subscribe to the messages webhook field. Multiple Numbers Under a Single App The Meta Developer Console permits only a single webhook endpoint per Facebook App. To connect multiple WhatsApp numbers, create an Inbox in Support Portal for each number but configure the webhook URL from only one Inbox in the Facebook App. All Inboxes associated with numbers under the same app will receive messages through that shared webhook endpoint. Supported Media Types WhatsApp supports a defined set of media types for message attachments. Consult Meta's WhatsApp Cloud API documentation for the current list of supported formats and file size limits. Expected Behavior Regardless of the configuration method used, once the WhatsApp channel is active: - Inbound messages from WhatsApp users create new conversations in the Support Portal Dashboard. - Agents can respond within the 24-hour session window using free-form messages. - After the session window expires, only approved template messages may be sent. - All standard Support Portal features — including labels, macros, CSAT (see Customer Satisfaction (CSAT) Surveys), and automation rules (see Automation) — apply to WhatsApp conversations. Governance Notes - Third-party data flow: All WhatsApp messages are transmitted through either Meta's WhatsApp Cloud API or Twilio's API, depending on the chosen method. Message content, phone numbers, media attachments, and delivery metadata are exchanged between the provider's infrastructure and your Support Portal instance. - 24-hour session window compliance: The 24-hour session window is enforced by WhatsApp at the platform level. Ensure your operational workflows account for this constraint, including escalation paths for conversations that may exceed the window. - Template message approval: Template messages must be submitted for Meta review and approved before use. Plan for review lead times when designing outbound communication workflows. - Business verification: Meta's business verification process may require legal documentation including business registration certificates, utility bills, or similar identity-proving documents. - Data processing: Organizations subject to GDPR, HIPAA, or other data protection frameworks should review Meta's and Twilio's data processing agreements to ensure compliance with their obligations. - Cost implications: WhatsApp Business API usage incurs per-conversation charges based on Meta's pricing tiers. Twilio applies additional markup when used as an intermediary. Monitor usage through the respective provider dashboards.

Last updated on Feb 25, 2026