import { type MountOptions, type UserInfo } from './index.js'; /** Everything an embedder can pass. All optional except `profileId`. Field * names DELIBERATELY mirror the React props (`ChatWidgetProps` / * `MarketplaceChatProps` in react.tsx) so the same mental model — and often * the same field names — carries over whether you're using React or a plain * script tag. Where a name changed over time the old one still works (see * the `@deprecated` notes) — this is a published package embedded on live * customer sites (WordPress plugin, Shopify theme block), so nothing here is * ever removed, only added to. */ export interface RelaySettings { /** The chatroom id (from your Relay dashboard). Required. Matches the React * `profileId` prop name. `appId` is the original alias — still works. */ profileId?: string; /** @deprecated alias for `profileId` — kept working, `profileId` is now the * documented name (matches React). */ appId?: string; /** Relay server URL. Defaults to the hosted relay; set for self-hosted. */ url?: string; apiUrl?: string; /** IDENTITY (optional, tiered): `token` (a signed JWT from your backend) is the * secure path; `userId` (any stable string you have) is the easy path; omit * both for an anonymous visitor. See EMBED.md. */ token?: string; userId?: string; /** Called when a signed `token` is rejected (expired): return a fresh token * from your backend to renew the session without a reload. Matches the * React `refreshToken` prop. Only usable from `window.relaySettings` / * `Relay('boot', ...)` (a function can't be expressed as an HTML * attribute) — not available via `data-relay-*`. */ refreshToken?: () => Promise; /** Display info shown to agents (not identity) — matches the React * `userName` / `userEmail` / `userAvatar` props. */ userName?: string; userEmail?: string; userAvatar?: string; /** @deprecated flat aliases for `userName` / `userEmail` / `userAvatar` — * kept working (the shipped Shopify integration used these names nested * under `user`, see `user` below, which is the fix for that; these bare * top-level fields predate that and still work standalone). */ name?: string; email?: string; avatar?: string; /** Same info as `userName`/`userEmail`/`userAvatar`, as one nested object — * matches `MountOptions.user` / React's internal shape exactly, and is * what a server-rendered snippet (e.g. Shopify Liquid, WordPress PHP) will * most naturally emit: `user: { name: "...", email: "..." }`. Takes * precedence over the flat fields if both are somehow given. */ user?: UserInfo; /** Subject the chat is about (e.g. a marketplace listing). `listingId` is * sugar for `subjectId: "listing_"`. */ subjectId?: string; listingId?: string; /** Context-card fields — matches React's `ChatWidget` `contextTitle` / * `contextSubtitle` / `contextStatus` props (a general "here's what this * conversation is about" card: an order, ticket, booking, etc). */ contextTitle?: string; contextSubtitle?: string; contextStatus?: string; /** Marketplace-card fields — matches React's `MarketplaceChat` * `listingTitle` / `listingMeta` / `listingPrice` / `listingStatus` props * (a specific-item card: price + status badge, e.g. "2019 Camry — $12,500 * — Available"). Use these OR `contextTitle`/etc — both build the same * card, pick whichever vocabulary matches your use case. */ listingTitle?: string; listingMeta?: string; listingPrice?: number; listingStatus?: string; /** @deprecated original flat names for the context/marketplace card — * kept working. `contextTitle`/`listingTitle` are now the documented * names (matching the two React components). */ subjectTitle?: string; subjectMeta?: string; subjectPrice?: number; subjectStatus?: string; /** The context/marketplace card as one nested object, if you'd rather build * it yourself than use the flat fields above — matches * `MountOptions.subject` exactly. Takes precedence over every flat field * above if given. */ subject?: { title?: string; subtitle?: string; tags?: string[]; status?: string; ownerLabel?: string; }; /** Pre-set reply chips shown above the input — matches the React * `quickReplies` prop. `window.relaySettings` / `Relay('boot', ...)` only * (an array can't be expressed as a single `data-relay-*` attribute). */ quickReplies?: string[]; /** i18n string overrides — matches the React `i18n` prop. Same restriction * as `quickReplies`: object, so JS-object form only. */ i18n?: MountOptions['i18n']; /** Per-tenant feature switches (default all ON). Object form only. Matches * the React `features` prop. Set a flag false to disable that feature. */ features?: MountOptions['features']; /** Appearance. `launcher` defaults to true (a floating bubble). */ accent?: string; /** Secondary accent (guest bubble + send button). Object/attr form; follows * `accent` when omitted. */ accent2?: string; /** UI language for built-in strings ('ko', 'ko-KR', …). Attr: data-relay-locale. * Omit to auto-detect from the visitor's browser. */ locale?: string; /** Colour scheme: 'auto'|'light'|'dark' (default 'light'; 'auto' follows OS). Attr: data-relay-theme. */ theme?: 'auto' | 'light' | 'dark'; /** Load brand webfonts (default true). Attr: data-relay-webfont="false". */ webfont?: boolean; launcher?: boolean; position?: 'bottom-right' | 'bottom-left'; /** Launcher teaser ("optional message" above the bubble). Matches the React * `launcherMessage` prop exactly: a bare string (title only), or * `{ title, subtitle }`. `launcherSubtitle` below is a SEPARATE flat * field kept only so `data-relay-launcher-message` / * `data-relay-launcher-subtitle` (two HTML attributes — an attribute * can't hold a nested object) can still combine into the same shape; in * JS-object form just pass the object directly, same as React. Omit to * use the chatroom's manifest value. */ launcherMessage?: string | { title: string; subtitle?: string; }; /** @deprecated HTML-attribute-only companion to a string `launcherMessage` * — see the note above. Prefer `launcherMessage: { title, subtitle }` in * JS-object form. */ launcherSubtitle?: string; translateLang?: string; /** Mount INLINE into an existing element instead of the auto-created, * body-appended host that the default floating launcher uses. A CSS * selector string (works from `data-relay-target` too) or an element * reference (JS-object form only). Ignored when `launcher` is true — same * restriction as `height`/`inbox` below: a floating launcher panel is a * fixed-size popup `mount()` owns, not something you place in the page. */ el?: string | HTMLElement; /** Inline container height — matches the React `height` prop. Only applies * when `launcher` is false/omitted. */ height?: string; /** Adds a back-chevron to the widget that swaps it for the full * conversation list — matches the React `ChatWidget`/`MarketplaceChat` * `inbox` prop, INCLUDING its one limitation: not supported in launcher * mode. (React itself requires a different component, `ChatAppLauncher`, * for a launcher+inbox combination — same scope boundary here.) Tapping a * row opens that conversation; its own back-chevron returns to the list; a * ✕ in the list view returns to this widget's original single-thread * view. Requires `launcher: false`. */ inbox?: boolean; /** Open DIRECTLY on the conversation list instead of a single thread — * what you want for a dedicated "Messages" page. `inbox: true` alone only * adds a back-chevron to a single thread, so the list is reachable but * never the landing view; that is the right default for a widget bolted * onto a product page, and the wrong one for a page whose whole job is the * inbox. Implies `inbox`. Requires `launcher: false` (same restriction as * `inbox`), and `profileId` OR `tenantId`. * * With `inboxStart`, tapping a row opens that conversation and its own * back-chevron returns to the list. There is no ✕ — the list IS the root * view here, so there is nothing behind it to close back to. */ inboxStart?: boolean; /** Inbox scope when `inbox` is set: `'tenant'` (default) lists the user's * threads across ALL your chatrooms; `'profile'` limits it to this one. */ inboxScope?: 'tenant' | 'profile'; /** Your business id — lists the visitor's threads across ALL your chatrooms * without naming one, and lets "new conversation" open against your default * chatroom (the server reports it). This is the vanilla equivalent of * React's ``, which has always accepted a tenant with * no profile; the script tag previously could not express that at all and * hard-required a `profileId`. * * Only meaningful with `inboxStart` — a single-thread widget still needs a * `profileId`, because a lone thread has to belong to a specific chatroom. */ tenantId?: string; } export type RelayCommand = 'boot' | 'update' | 'identify' | 'shutdown'; /** The public command dispatcher exposed as `window.Relay`. */ export declare function Relay(command: RelayCommand | string, arg?: unknown): void;