Skip to main content
The web widget is a chat launcher you add to your site with a single script tag. A visitor clicks it, types, and is answered by the same agent that runs your outreach and answers inbound WhatsApp — same knowledge base, same policies, same voice, and the same shared inbox when it hands off to a person. Nothing about it is a separate support bot with its own configuration to keep in sync. What is different from WhatsApp is who the visitor is: nobody signs in, so there is no phone number and no email address until the conversation produces one.

​
Install

Copy the snippet from the Boom app — Settings → Channels → Web widget → your widget — and paste it before the closing </body> tag of every page that should show the widget. It looks like this:
Copy it rather than typing it. The origin in the snippet is pinned by the deployment you are looking at, so a hand-written one will point at the wrong environment. The install key in that URL is public — it ships in your page source, and it has to. It identifies the widget; it does not authorize anything. What controls where your widget may be embedded is the origin list below.
async is deliberate. The script does not block your page, and the launcher button appears a moment after the rest of the page has painted.

​
Allow your site’s origin

A widget only renders on origins you list, and the list starts empty. Add every origin that will host it under Allowed origins on the same settings page. Matching is exact string equality, on the origin a browser actually sends: So https://example.com does not cover https://www.example.com, and a staging domain needs its own entry.
A widget with an empty origin list installs cleanly and never opens. The launcher button appears — the script that draws it does not know which site loaded it — and clicking it produces an empty panel. If that is what you are seeing, this list is the first thing to check.

​
If your site sets a Content-Security-Policy

Two directives need our origin. Add them to whatever your site already sends:
script-src covers both the snippet above and the launcher bundle it loads. frame-src covers the chat panel, which is an iframe served from our origin. You do not need a connect-src entry. The panel makes its own network requests, but it makes them from inside that iframe, so they are governed by our policy rather than your page’s. The launcher itself — the button and the greeting bubble, which are the only parts living in your document — makes no requests at all. Serve the page over HTTPS. The widget’s session cookie is Secure, so a visitor on an http:// page will not keep a conversation across reloads.

​
Customize how it looks

The settings page is a live canvas with the widget drawn on a stand-in for your own site, and the settings beside it in four groups. Switch the canvas between desktop and mobile, and between the open panel and the collapsed launcher, to see what a visitor gets. You pick one accent colour and Boom derives the rest, so the text drawn on it stays legible whatever you choose. Launcher — the button visitors click: Panel — the window that opens: Words — everything a visitor reads: the panel title, the greeting, the composer’s hint text, and up to four one-tap suggested questions shown on an empty panel. Every piece of copy is per-language — English, Spanish, and Portuguese — and the visitor gets the language their browser asks for, falling back to English for anything you leave blank. A suggested question left blank in one language simply does not appear for those visitors.
A suggested question is the message. Tapping one sends that exact text as the visitor’s first message, so write them the way a customer would ask, and expect the agent to answer them the way it answers anything else — they are not scripted replies.
Below the composer the panel shows a “Powered by Boom” link. That line is not configurable.
The panel does not tell visitors on its own that they are talking to an AI. Where you need that disclosure — the EU AI Act asks for it wherever it is not otherwise obvious — put it somewhere you control. The greeting is the natural place: it is the first thing a visitor reads, and it is yours to write in all three languages.

​
What a visitor’s session is

A visitor is anonymous. The only thing tying somebody who comes back to the transcript they left is a cookie on our origin, set the moment they send a first message and good for 30 days. That cookie is Partitioned (CHIPS), which has two consequences worth knowing:
  • It survives in browsers that block ordinary third-party cookies, which is now most of them.
  • It is scoped to your site. The same person visiting two different customers of ours is two unrelated visitors, and the same widget embedded on two of your own domains keeps two separate conversations. The widget is not a cross-site identity.
A visitor who blocks cookies for our origin can still use the widget, but every message starts a new conversation, and the panel is empty again after a reload. There is no login to fall back on.

​
Sending images

A visitor can attach an image — PNG, JPEG, GIF or WebP, up to 4 MB, four per message. An image on its own is a message; no caption is required. The agent can read it. It receives a written description of the image plus any text found in it, which is what lets it answer about a screenshot of an error, a photo of a receipt, or a picture of the wrong item that arrived. It does not see the picture itself, so an image whose meaning depends on fine detail is better described in words as well. Your agent can send images back, from the assets you have given it — the same library it draws on for WhatsApp. So can a person replying from the shared inbox.
Images only, in both directions. A PDF, a video or an audio file is refused rather than sent: the panel has no way to show one, and a reply that arrived with the file silently missing would be worse than a refusal you can see. On the inbox side the paperclip only offers image files for a widget conversation, and a reply that somehow carries anything else is marked as failed rather than delivered without it.
Anyone who can open your site can upload to the widget — there is no login. It is rate limited per visitor and per widget, every file is checked to be a real image regardless of what it claims to be, and nothing larger than 4 MB is stored. Treat what arrives as untrusted, exactly as you would a message.

​
Controlling the widget from your page

The snippet installs one global. It works from the moment the tag runs, so you can call it from a button in your own header without waiting for anything to load:
Re-running the snippet is safe. A single-page app that re-executes it on a route change gets the widget that is already there, not a second button.

​
When nothing answers

Answering is a setting, not a default, and it resolves exactly the way inbound does: per channel, falling back to your organization.
If no agent is configured to answer the widget, or the configured agent is disabled, the visitor’s message is still received and stored — it waits in the shared inbox for a person — and the panel stops waiting and offers a retry rather than spinning. Boom does not pick an agent on your behalf, because guessing which agent should speak for you is worse than staying quiet.
Replies a person sends from the inbox arrive in the visitor’s open panel in realtime, minutes later if that is when they are written.

​
Rate limits

Per visitor, 30 messages a minute and 10 image uploads a minute. Per widget, 120 first-messages and 40 uploads a minute from visitors who have no session yet — set far above a real site’s arrival rate, so they throttle a loop rather than a launch. A throttled request is refused before anything is stored. Uploads have their own allowance rather than sharing the message one, so a visitor who has just sent several images can still write about them.

​
Rotating the install key

Rotate on the settings page mints a new key and invalidates the old one immediately. The snippet on your site then points at a key that no longer resolves, and the widget stops appearing until you paste the new one — so rotate when you are ready to deploy the change, not before. Rotating does not touch conversations, transcripts, or appearance.

​
Troubleshooting

Inbound conversations

The same answering behavior, reached from WhatsApp instead of your site.

The agent

What briefs the agent that answers, and when it hands off to a person.

Extraction

Why a cold widget conversation has a transcript but no typed fields.

Use MCP

Read widget conversations from an AI tool.