Chat and support

Front Chat

Configure Front Chat

Copy the chatId from the widget snippet in your Front Chat channel's Installation tab.

npm install @c15t/integrations@alpha

src/consent-scripts.ts

import { frontChat } from '@c15t/integrations/front-chat';

export const scripts = [frontChat({ chatId: 'YOUR_FRONT_CHAT_ID' })];

Register the scripts

Complete your framework quickstart first. Keep its Inth endpoint, policy, styles and consent UI. Remove the vendor's original script, SDK initializer or tag-manager entry, so the vendor loads only through c15t.

The vendor pages put the helper in src/consent-scripts.ts. If your framework quickstart already has a scripts array, such as the one in c15t.config.ts in the Next.js guide, add the helper to that array instead of creating a second file. The scripts export is a configuration, not an initializer. Add it to the c15t provider you already have, at the registration point for your framework below. These are edits to that provider, not a second provider.

Add the configuration to scripts in c15t.config.ts, next to next.config.ts:

import { defineConsentConfig } from 'c15t/next';
import { scripts } from './src/consent-scripts';

export default defineConsentConfig({ scripts });

Keep the rest of your config, such as mode and routePrefix, in the same call. ConsentRoot reads the config in the browser, so the layout keeps passing only state. App Router, Pages Router and static export all read the same file. See Next.js scripts and embeds.

Options

Option	Default	Behavior
`chatId`	Required	Public chat ID passed to `FrontChat('init')`. Surrounding whitespace is trimmed. An empty value logs an error and the script does not load.
`useDefaultLauncher`	`true`	Shows Front's launcher. With `false`, open the widget from your own launcher through Front's SDK.
`nonce`	None	CSP nonce for the loader and Front's generated scripts. A loader nonce from your consent provider is forwarded to `init` too.
`scriptSrc`	`https://chat-assets.frontapp.com/v1/chat.bundle.js`	Loader URL override. A proxy here does not proxy the widget's other requests.

Front creates more resources for the widget. Follow Front's CSP instructions for the rest of the policy.

Loading and revocation

frontChat uses the functionality category and appends its loader to <body> once functionality is allowed. After the SDK loads, the helper calls FrontChat('init') with your chat ID. If functionality is revoked while the SDK is still downloading, the helper skips init.

On revocation the helper removes the loader element and calls no Front API. The running widget stays until c15t reloads the page, so keep reloadOnConsentRevoked enabled.

Clear the Front session on revocation

The reload removes the widget but keeps the visitor's Front session. To clear it, call shutdownFrontChat() from the onBeforeConsentRevocationReload callback in your consent options:

src/consent-callbacks.ts

import { shutdownFrontChat } from '@c15t/integrations/front-chat';

export const callbacks = {
	onBeforeConsentRevocationReload: ({ preferences }) => {
		if (!preferences.functionality) {
			shutdownFrontChat();
		}
	},
};

shutdownFrontChat sends FrontChat('shutdown', { clearSession: true }) when the SDK has loaded and does nothing otherwise. Front returns no completion signal, so the reload does not wait for the session to clear.

Verify Front Chat

After you allow functionality, chat.bundle.js loads and the widget connects to your Front inbox. With shutdownFrontChat wired, revoke functionality and check that the next grant starts a new Front session.

Test in a private window with an opt-in policy. Open DevTools Network, disable the cache and filter by the vendor's domain:

Load the page. No request goes to the vendor before you choose.
Click Reject, then reload. There is still no vendor request.
Open Privacy settings and allow the helper's category. The vendor script loads without a page reload.
Turn the category off again and save. c15t reloads the page, and the new page makes no vendor request.

c15t reloads on revocation because removing a script element does not stop code that already ran. The vendor's listeners, timers and queued events stay alive until the page unloads. If you set reloadOnConsentRevoked: false, stop the vendor yourself. Register a callback-only script whose onConsentChange calls the vendor's opt-out API, as shown in custom integrations, and check the permission before each of your own event calls. The reload does not delete cookies the vendor already set; see clear on revocation for your framework.

The helper sets vendor to its script ID, so once you declare that vendor a visitor can turn it off inside an allowed category. See vendor consent for your framework. The consent verification guide covers navigation, expiry and hosting checks.