ChatGPT website widget: options, setup, and rollout checks

What a ChatGPT website widget actually includes

A useful website chat experience has more parts than a model call. It needs a visible interface, a server-side way to keep credentials out of the browser, an answer policy, a source of business information, and a route to human help when the answer should not be automated.

OpenAI provides ChatKit, an embeddable chat interface with features such as widgets and file attachments. For new work, its current documentation directs developers to a custom-server integration. That is different from embedding a GPT from ChatGPT, and it still requires a backend and operational decisions. The older hosted Agent Builder path is transitioning away; do not start a new deployment from an old hosted tutorial.

If you build with OpenAI directly, the API quickstart shows a server-side SDK flow. Keep API keys on the server, not in page JavaScript. You also own conversation state, abuse controls, monitoring, data choices, and integrations. That can fit a product team that already maintains the web application and needs a bespoke experience.

For a public support widget, the right question is less “does it use ChatGPT?” and more “what can it answer, cite, or hand off?” A fluent answer without current product context can still confuse a visitor.

Three ways to add an AI chat bubble

None of these routes is automatically the “best.” A custom build buys control but assigns engineering work to your team. A simple widget can shorten setup but may not have the source and handoff controls a support operation needs. A connected platform can reduce integration work, but it still needs an owner to decide what belongs in a public channel.

Start with public knowledge, not every document

The first launch scope should be small. Put public help-center material, shipping policy, or product documentation in scope if it is current and meant for visitors. Do not treat an internal wiki, private ticket history, or an authenticated dashboard as public widget content merely because it is useful to employees.

Ask these questions before connecting a source:

• Who is allowed to read this on the public website?
• Does it answer the top visitor questions accurately today?
• Who updates it when policy or product details change?
• What should the widget do when it cannot answer: say so, collect a request, or direct the person to human support?

That is also why a generic prompt is not a knowledge strategy. A prompt can state tone and boundaries, but it does not turn old or private documents into a safe public answer.

Design the visitor journey around handoff

Website chat has a different job from an internal engineering assistant. A visitor may ask for refund terms, account access, an order detail, a contract exception, or help with something that requires authentication. Decide the response for each category before launch.

For example, a widget can explain the documented returns policy, link to the correct help article, and say when a support specialist needs to review a specific order. Do not promise that it can view an order or change an account unless the configured action and permission actually permit that behavior. A helpful handoff includes the next step, rather than a vague “contact us.”

Also test the page around the chat bubble: mobile layout, keyboard access, the open/close state, consent or privacy notices, and the route from a chat to a support form or channel. Model quality cannot repair an inaccessible or disconnected interface.

Test the website embed separately from the answers

Use a compact test set before launch. Include common pre-sales questions, a question whose answer is in your approved source, a stale or unsupported request, and a request that should reach a human. For each, assess accuracy, source fit, tone, and the next step.

Then load the staging page as a visitor would. Confirm that the bubble opens, branding and welcome text render correctly, the intended teammate responds, and the promised handoff is reachable. Test normal and boundary questions independently. A good answer in a dashboard preview does not verify that the production embed has the same source access or channel permissions.

Budget for the conversation and its upkeep

A custom API widget has model usage costs plus hosting, development, monitoring, and maintenance. A no-code vendor may instead charge by conversation, credits, subscription, or some combination. Check what happens when traffic exceeds the allowance, and whether human handoff or connected sources cost extra. A free embed is not necessarily free support.

The eesel chat-bubble documentation prices a bubble conversation at one regular task, currently $0.40 regardless of the number of messages in that conversation. For example, 250 such conversations would cost $100, before any other billable work. Dashboard chat is free; CLI chat is billed work. Review expected volume and current task pricing before approving automated tests or launch.

Review a website chat-bubble rollout with eesel CLI

eesel's chat bubble is a website channel for its teammate. The Website integration supplies knowledge; the bubble lets visitors talk to the teammate. Those are separate jobs. The eesel CLI operates the same teammate and workspace as the dashboard, so a support owner, script, or coding agent such as Codex, Claude Code, or Cursor can help with setup using Node.js 18.17 or newer.

For a new setup, the documented quickstart reads the chosen website and returns an embed snippet, trigger ID, and hosted chat link:

npx @eesel/cli init chat-bubble --site https://your-site.com

Replace the example URL with an owner-approved public site. This command creates a setup; it is not a read-only preview. Connecting a chat bubble makes the channel live without a separate automation switch, so use a non-production setup and do not distribute its hosted link or embed until reviewed. Without an existing account, the quickstart creates an anonymous workspace; log in to claim it before relying on it for ongoing work.

For an existing teammate, ask the coding agent to inspect its sources and instructions first. Replace the example agent name with the intended teammate:

npx @eesel/cli integrations sources --agent "Website support"
npx @eesel/cli instructions --agent "Website support"

The coding agent reads the structured CLI output and flags missing or unsuitable sources for the owner. Suppose visitors need a delivery-policy answer: check that the current public shipping page is indexed, then test a question about delivery times and an account-specific request the public policy cannot answer. The owner approves source and instruction changes; connecting private documents is not an acceptable shortcut.

Once the owner approves paid test cost, a script or coding agent can run separate eesel chat checks against that non-production teammate, with consequential actions disabled or absent. Read the returned answers and cited evidence rather than treating a successful command as a correct answer. A fresh conversation alone does not remove the teammate's permissions.

Next, have the coding agent propose a website-code change using the actual returned snippet, placed before </body> on a staging page. Review it before merging. Set the name, colors, welcome message, and suggested questions in the Chat Bubble settings. Configure the intended handoff to a connected helpdesk, Slack, or email, and specify when the teammate should use it. Test the hosted chat link and staging embed: the right teammate should answer, the policy citation should work, and the handoff should reach its destination. Only then approve the public embed. This connects terminal-led setup to a visitor experience you have actually checked.

Build a website widget visitors can trust with eesel CLI

An embedded chat bubble should give a visitor an answer from approved public knowledge or a clear way to get a person. Try eesel when you want to review those answers and the actual website channel together.

Sources

• OpenAI GPTs FAQ
• OpenAI API quickstart
• eesel CLI documentation