Deep Chat: a web component for adding an AI chat window to an existing site

The gap Deep Chat fills is the chat window, not the model

Most teams building an assistant already have a model call somewhere. What they do not have is a message list, an input box, file attachment handling, a microphone button and a scroll behaviour that survives a long conversation. Deep Chat is aimed at that layer. The README describes it as a fully customizable AI chat component that can be injected into a website with one line of code, and the repository is organised around a component package plus example servers rather than around a hosted service.

The intended user is a front-end or full-stack developer who is comfortable wiring an HTTP endpoint and who wants the transcript UI to be a dependency rather than a project. It is not aimed at someone who wants a no-code assistant builder. There is no dashboard in the repository layout, no database, and no place to paste documents. The component renders and sends; the endpoint you point it at decides everything else.

How the request property and directConnection differ

There are two ways to get an answer into the window, and the choice has real consequences.

The first is the request property. You give the component a URL, and it posts to that URL in a shape the documentation defines, expecting a response in a shape it also defines. The README shows the minimal form as an attribute carrying JSON with a url key, and notes that the service has to handle the request and response formats used in Deep Chat. If your existing service speaks a different dialect, two escape hatches exist: interceptor properties that augment the transferred objects, and a handler function that takes over the request code entirely. Those two options are where most integration work actually happens.

The second is directConnection. Here the component talks to a hosted AI API from the browser, and the README lists more than 20 supported APIs, naming OpenAI and Claude among them. The release notes for 2.5.0 added Requesty, liteLLM and Dify to that list, and 2.5.1 is titled as deprecating the OpenAI Assistants API. The obvious trade-off is that a browser-side call means a browser-side key unless the provider offers a safe mechanism, and the README's example passes an optional key inline. Treat that path as a prototyping convenience or as something for keys you are willing to expose, and use request for anything else.

Installing Deep Chat and sending a first message

The README gives a single install command for the generic package. If you are in a React project it points you at a separate package instead, which is worth knowing before you start, because the two are not the same import.

npm install deep-chat

npm install deep-chat-react

After installing, the README says to add the element to your markup. The exact syntax varies by framework and the README links to a frameworks page rather than reproducing every variant, so the plain element below is the baseline.

<deep-chat></deep-chat>

At this point the window renders but has nothing to talk to. To connect it, the README shows the request attribute carrying a JSON object with a url key that points at your endpoint.

<deep-chat request='{"url":"https://service.com/chat"}'/>

What you should see after this is a working input box that posts to your URL, plus whatever your service returns rendered as a message. If nothing appears, the first thing to check is the response shape, since the README is explicit that the service must handle the formats Deep Chat uses. The repository also ships an llms.txt file intended as a reference for configuring the component with a code assistant, and the README includes a prompt that points an assistant at it.

Where the component gets in the way

The request contract is the main constraint. If your backend already returns a format you cannot change, you are writing an interceptor or a handler, and the README does not describe how far those can bend the payload. That is a documentation gap worth testing early rather than late.

Browser-side direct connections carry the key exposure problem described above, and the README does not present a mitigation. There is also no conversation store: the component can keep messages in browser storage, which the release notes describe as storing messages locally without a backend message integration, but that is per-browser and not a shared history. A multi-user product that needs to resume a conversation on another device will not get that from the component.

Finally, the feature list is broad, covering webcam capture, microphone recording, speech to text and speech to speech. Each of those pulls in browser permissions and provider support that the README does not enumerate per browser. If voice is central to your product rather than a nice extra, budget time to verify it in your target browsers before you commit to the component.

Deep Chat versus building on a headless chat SDK

The nearest alternative approach is a headless conversation library, where you get message state, streaming and tool-call plumbing as hooks or functions and render the interface yourself. The difference is where the work sits. A headless library asks you to build the transcript, the input, the scroll behaviour and the attachment UI, and in exchange it does not constrain your endpoint format or your markup.

Deep Chat inverts that. You get the window for free and you adapt your backend to its contract, or you use an interceptor. That is a good trade when the chat is one panel in a larger application and the visual result matters more than control over the transport. It is a poor trade when the conversation state is the product, because the component deliberately does not own it. There is also a middle option the README itself points at: the example servers in the repository, which show what a compatible endpoint looks like. Reading one of those before writing your own is faster than inferring the format from the attribute examples.

Maintenance, licence and the cost of staying current

The licence is MIT, which permits commercial use and modification, and the repository carries a LICENSE file at the top level. As with any MIT dependency, the obligation is essentially attribution, but the practical question for a component that renders user-visible UI is different: if you fork the styling, you own the merge cost on every release.

The release cadence visible in the repository is steady. 2.5.1 landed on 2026-08-27, 2.5.0 on 2026-07-19, and 2.4.2 on 2026-01-31, and the last push to the default branch was on 2026-09-14. The 2.5.1 notes are titled as deprecating the OpenAI Assistants API, which is the pattern to watch: provider-side changes arrive as component updates, and a pinned older version will eventually break against a provider that moved. Budget for periodic upgrades rather than a one-time install, and read the release notes before bumping, because features such as the directConnection providers have been added incrementally across minor versions.

Editorial conclusion

Adopt Deep Chat when the chat window is a small part of a larger product and you already have, or are willing to write, an HTTP endpoint that follows its request and response shape. Skip it if you need server-side conversation state, a hosted dashboard, or retrieval over your own documents, because none of those are in the README. Before committing, open the Connect page and the server template examples together and confirm your endpoint can return the Response format, including the streamed variant if you want tokens to appear as they arrive.

Frequently asked questions

Official sources

1. License: MIT
2. OvidijusParsiunas/deep-chat on GitHub
3. Project website
4. README
5. Releases