Loading…
A website chat widget is the one channel with no platform in the middle — no approval, no window, no template — and the rules that replace them are about your site: which domains it runs on, how a visitor is remembered, and what the tag is allowed to load.
The whole install is one script tag before </body>. It names your site key and carries async, so the browser fetches it after the page has painted and never blocks your content. The file is small — a test holds it under 20 KB compressed and fails the build if it grows — and it draws the launcher, the panel and the messages itself. Nothing else is fetched until a visitor opens the chat.
The widget renders inside a shadow root, which is the browser's way of keeping two sets of styles apart. Your site's CSS cannot restyle the chat by accident and the chat's CSS cannot leak into your page. The practical consequence is that it looks the same on a Shopify theme, a WordPress site and a hand-built page, and the colour and header you set in the product are the only things that change it.
If your site sets a Content-Security-Policy, two directives need to know about the chat: script-src for the tag itself and connect-src for the messages, both allowing zynqly.com. Without them the browser blocks the widget silently, and the console is the only place that says why.
Every request the widget makes carries the page's origin, and the server checks it against the domains saved for that site. A tag copied onto another domain gets a refusal, not your chat. That is what makes a site key safe to sit in public HTML: the key alone is not enough to use it.
Leave the list empty while you are testing and the widget works anywhere, which is convenient for a staging copy. Fill it in before launch. A domain covers the subdomains under it, so listing example.com also allows shop.example.com; listing the shop does not allow the rest.
There is no login. The first time the widget runs on a browser it makes up an id, keeps it in that browser's local storage, and asks the server for a signed token that stands for that visitor. The conversation is attached to the id, so somebody who comes back next week on the same browser opens the same thread and sees their history.
The same person on their phone and their laptop is two visitors, and a cleared browser or a private window is a new one — the widget has nothing else to go on. Two things join a visitor to a name: the email the widget asks for after their first message, if you switch that on, and an identify call your site can make once somebody is logged in, passing their name and email. Either one names the lead the conversation created.
There is no 24-hour window. You can reply to a website conversation whenever you like, without a template and without anybody's approval, and the reply is waiting the next time that visitor opens the chat on that browser. What replaces the window is presence: a reply to somebody who has left the page is a reply they may never see.
That is what business hours are for. Set the days and the range you actually answer in, and outside them the widget shows visitors your away message — an email address, a phone number, when you are back. Their message still lands in the inbox; the away message is honest about the wait rather than a substitute for the answer.
The messages, the visitor's id, and a name and email if they gave one — that is the record on our side. The page a visitor is on is read to check the domain, not built into a browsing history.
On the visitor's side there is the id and its token, both in local storage for your site's origin, and nothing set as a cookie. If your privacy policy lists the tools that keep data in a visitor's browser, this is one of them; it is also all of it.
Not measurably. The tag is async, so it loads after the page has painted, and the file is kept under 20 KB compressed. Nothing else is fetched until a visitor opens the chat.
They can copy it; it will not work. Every request carries the page's origin and the server refuses any domain that is not on your list. Fill the list in before launch — while it is empty the widget runs anywhere, which is only right for testing.
Not until they open the chat again on the same browser, where their thread and your reply are waiting. Nothing reaches a closed tab, which is why the widget can ask for an email after the first message — it gives you a way to follow up.
No. Identity is per browser: a phone and a laptop are two visitors, and a cleared browser is a new one. The email ask, or an identify call from your site when somebody is logged in, names the lead so you can tell they are the same person.