LiipGPT Chat & Library

This package provides the following:

1. A web component for embedding the LiipGPT chat UI (<liipgpt-chat>)
2. A web component for embedding the LiipGPT button as a link (<liipgpt-button>)
3. A one-shot search summary web component (<liipgpt-search-summary>)
4. A client library for interacting with the LiipGPT API

Embed

<!-- Chat -->
<script src="https://cdn.example.com/@liip/liipgpt/chat/liipgpt-chat.iife.js"></script>
<liipgpt-chat api-url="https://your-api.example.com/org" lang="en"></liipgpt-chat>

<!-- Button -->
<script src="https://cdn.example.com/@liip/liipgpt/button/liipgpt-button.iife.js"></script>
<liipgpt-button api-url="https://your-api.example.com/org" lang="en"></liipgpt-button>

<!-- Search summary -->
<script src="https://cdn.example.com/@liip/liipgpt/search-summary/liipgpt-search-summary.iife.js"></script>
<h2 id="ai-overview">AI overview</h2>
<liipgpt-search-summary
    labelled-by="ai-overview"
    question="What can you tell me about your services?"
    api-url="https://your-api.example.com/org"
    lang="en"
    height="280"
></liipgpt-search-summary>

ESM builds (optional)

Every widget is also published as an ES module next to its IIFE bundle. Same components, same attributes — only the module format differs. Drop the .iife from the file name and add type="module":

<!-- Chat -->
<script type="module" src="https://cdn.example.com/@liip/liipgpt/chat/liipgpt-chat.js"></script>

<!-- Button -->
<script type="module" src="https://cdn.example.com/@liip/liipgpt/button/liipgpt-button.js"></script>

<!-- Search summary -->
<script type="module" src="https://cdn.example.com/@liip/liipgpt/search-summary/liipgpt-search-summary.js"></script>

Chat and button weigh the same either way. The search summary is smaller as a module: an IIFE cannot code-split, so its ChatConfig support had to be inlined, while the module fetches that part only when use-chat-config is set — an embed styled through host CSS downloads about a quarter less.

Importing from npm resolves to the module build as well, so import "@liip/liipgpt/search-summary" registers the element and gives you the named exports (LiipGPTSearchSummary, PiiChecks) — with the IIFE the namespace came back empty. require() still resolves to the IIFE.

The IIFE builds stay supported and unchanged; nothing needs to migrate. Two things to check before switching:

• Content-Security-Policy — a module can load additional files from the host it was served from, and that host is cdn.jsdelivr.net for both embed variants: the fixed CDN URL points there directly, and the backend's /cdn/npm route redirects there. The on-demand files are imported relative to the entry, so they resolve against jsdelivr in either case. Add https://cdn.jsdelivr.net to your script-src — also when the script tag points at your own domain — or the widget will fail to load.
• Pin the version. Serve the module from a version-pinned URL. With a floating "latest" URL a release can land between the entry and its companion files being fetched, and the two no longer match.

Subresource Integrity covers only the file you name in the tag, so the on-demand files are not integrity-checked. Stay on the IIFE build if you rely on SRI.

Note: The standalone @liip/liipgpt-search-summary package is superseded by @liip/liipgpt/search-summary from this package.

For more information please refer to: docs.liipgpt.ch