@leadbot/react

React components for LeadBot: an AI agent chat, lead forms, callback/email requests, a WhatsApp handoff, and a full embedded flow — rendered into your own DOM and styled by your site.

Thin wrapper around @leadbot/components, which is where the theming reference, the token table and the class-name list live. Everything below is what is specific to React.

Install

npm install @leadbot/react

React 18 or newer is a peer dependency. The package is SSR-safe: every component renders an empty host <div> on the server and mounts in an effect.

Usage

import {
  LeadBotProvider,
  LeadBotAgent,
  LeadBotCallbackRequest,
  LeadBotForm,
} from "@leadbot/react";
import "@leadbot/react/styles.css";

export default function App() {
  return (
    <LeadBotProvider
      domainKey="your-domain-key"
      leadbotId={18}
    >
      <LeadBotAgent id="chat-step-uuid" initialMessage="Hi! How can I help?" />
      <LeadBotCallbackRequest id="callback-step-uuid" />
      <LeadBotForm id="form-step-uuid" eventLabel="Homepage form" />
    </LeadBotProvider>
  );
}

import "@leadbot/react/styles.css" is the default look; skip it entirely and style the plain light-DOM markup yourself. Both spellings resolve to the same stylesheet, but import it from the package you installed — importing @leadbot/components/styles.css only works while npm happens to hoist the transitive dependency, and breaks under pnpm's strict layout or Yarn PnP.

Configuration precedence

A prop on the component always wins over the provider. Every LeadbotComponentsConfig key (domainKey, apiHost, leadbotId, path, language, baseColor, preview, previewToken, debug) can be set in either place; the provider is the default for everything under it, and a component that sets the same key overrides it for itself only.

<LeadBotProvider domainKey="dk" leadbotId={18}>
  <LeadBotAgent id="chat-step-uuid" />               {/* leadbotId 18 */}
  <LeadBotForm id="form-step-uuid" leadbotId={22} /> {/* leadbotId 22 */}
</LeadBotProvider>

So there is no need to repeat leadbotId on every component — set it once on the provider, and override it only where a component belongs to a different bot.

Components

| Component | Renders | |---|---| | LeadBotAgent | AI agent chat | | LeadBotForm | Published lead form | | LeadBotCallbackRequest | Callback request (name + phone) | | LeadBotEmailRequest | Email request (name + email + message) | | LeadBotWhatsApp | WhatsApp handoff | | LeadBotButtons / LeadBotButton | Published button step, or your own buttons | | LeadBotFlow | A whole bot conversation, inline |

Forms also accept declarative fields — TextField, EmailField, PhoneField, NumberField, TextAreaField, SelectField, CheckboxField, RadioListField, CheckListField — as children, instead of the published form's fields.

Published steps

Every component is backed by a published step: id is that step's uuid, and the dashboard configures the component through it (fields, labels, WhatsApp number, agent). The flow is fetched once per bot per page and shared by every component; that request is also what counts the pageview.

Because the published flow is the source of truth, unpublishing a bot removes its components from every page. On localhost — or with debug — a component whose id matches no published step renders a visible placeholder instead of nothing.

Language

Components speak the language of the bot as published, which arrives with the boot fetch — not the page's <html lang>. Pass a labels object to a component to override any individual string.

Theming

See the @leadbot/components README for the full token table, dark mode, and the stable class names. The short version: override --leadbot-primary (or pass baseColor) on the provider or any ancestor, and write plain unlayered CSS against the .leadbot-* classes to beat any default.

License

MIT