Title: Sohaychat – AI Chatbot & Support Agent for WooCommerce
Author: Mithun Biswas
Published: 18 de Julio de 2026
Last modified: 20 de Septiembre de 2026
---
Buscar plugins
# Sohaychat – AI Chatbot & Support Agent for WooCommerce
Por [Mithun Biswas](https://profiles.wordpress.org/bhoot/)
[Descargar](https://downloads.wordpress.org/plugin/sohaychat.1.4.0.zip)
* [Detalles](https://cl.wordpress.org/plugins/sohaychat/#description)
* [Reseñas](https://cl.wordpress.org/plugins/sohaychat/#reviews)
* [Instalación](https://cl.wordpress.org/plugins/sohaychat/#installation)
* [Desarrollo](https://cl.wordpress.org/plugins/sohaychat/#developers)
[Soporte](https://wordpress.org/support/plugin/sohaychat/)
## Descripción
Sohaychat adds an AI chat widget to your WordPress site that answers visitor questions
from the articles you publish. You write articles in the built-in Knowledge Base,
and the chatbot looks up the best matches before it replies — so it stays on-topic
and uses your real content instead of guessing.
**On a WooCommerce store, the chatbot shops with your visitors.** It searches your
catalog, pulls up a product with its size and colour options, reads live stock and
prices, answers shipping, returns, and refund questions from your store’s own pages,
and adds, changes, or removes items in the shopper’s cart — without them leaving
the conversation. Signed-in customers can also ask where their own order has got
to. Every cart change comes with an Undo button, and every price and stock status
is read from your store rather than invented. On sites without WooCommerce, none
of it appears.
Every conversation is saved in a built-in inbox under **Sohaychat Conversations**—
your team can read, search, filter, assign, and reply from one place.
#### Why site owners pick Sohaychat
* **Answers from your own content** — the chatbot reads the articles you publish
in your Knowledge Base. It doesn’t make up product details or invent prices.
* **Sells, not just supports** — on a WooCommerce store the chatbot searches your
catalog, checks stock and prices, and fills the shopper’s cart inside the conversation.
Signed-in customers can ask after their own orders instead of opening a ticket.
Declares HPOS and Cart-Checkout-Blocks compatibility. On sites without WooCommerce
the shopping tools stay hidden and everything else works the same.
* **No coding to set up** — paste an OpenAI or Google Gemini API key, publish a
few articles, click “Sync All Articles”. The widget appears on every page.
* **A real inbox for your team** — every conversation is saved. Search, filter
by status, assign one to a teammate, or reply yourself.
* **Predictable costs** — set a daily token cap and the plugin stops calling your
AI provider for the rest of the day once you hit it. A runaway loop or a hostile
bot can’t drain your account overnight.
* **GDPR-friendly out of the box** — conversations are stored on your own site,
in your own database. A chat belonging to a signed-in visitor, or carrying an
email address the visitor gave you, flows through WordPress’s built-in **Export/
Erase Personal Data** tools; a chat from someone who shared nothing has no email
to match on and is erased by deleting it from the **Conversations** inbox. See**
Privacy** below.
#### What’s included
* A **chat widget** that drops into every page (you can hide it on pages you don’t
want it on).
* **WooCommerce shopping tools** (WooCommerce 7.0 or later) — catalog search and
browse, product and variant lookup, live stock and prices, shipping/returns/refund
answers, add, change, or remove in the shopper’s cart, and order status for signed-
in customers. Each result renders as a card in the chat rather than a wall of
text.
* A **Knowledge Base** section in the WordPress admin, with a “Sync All Articles”
button.
* A **Conversations admin** where you can read, search, filter, assign, reply,
pin, and close chats.
* **Quick replies** — saved answers your team can drop into a reply from the lightning-
bolt button in the composer, or by typing `/` in an empty draft. Search them,
pick one with the arrow keys, and edit it before sending. Managed under **Sohaychat
Quick replies**.
* **Collect customer details** — decide what a visitor has to share before someone
from your team joins their chat: require them to sign in, ask for a name and
email, or ask for nothing. Set it under **Sohaychat Settings**, with an optional
marketing opt-in whose wording you write yourself. The chatbot still answers
everyone in every mode.
* **Email visitors when you reply** — answer a chat the visitor has already closed
and Sohaychat can email them your reply, with a one-click link to stop further
emails. Off by default.
* An **AI Settings** screen for picking the AI provider and model, writing the
welcome message, and setting daily spend caps.
* A **Diagnostics** screen that shows today’s token usage and the most recent plugin
log entries.
* **Fast page loads** — the chat code only downloads when a visitor actually opens
the chat, not on every page view.
* **Your API keys are encrypted** in the database and never shown in the admin
UI after you save them.
#### You’ll need
* A WordPress site running version 6.6 or later, on PHP 8.1 or later.
* An account and API key with **OpenAI** or **Google (Gemini)**. You pay that provider
directly for the model usage — Sohaychat does not resell access. A typical small
support site stays in single-digit dollars per month. If you use the Knowledge
Base, you need an OpenAI key regardless of which provider answers the chat —
see **External services**.
* Optional — WooCommerce 7.0 or later, if you want the shopping tools. Everything
else works without it.
#### External services
Sohaychat sends data to an AI provider to generate chat answers, and to OpenAI to
index and search your Knowledge Base. Without an account and API key for at least
one provider, the plugin has no upstream model to call and the chat widget cannot
answer questions.
**Which service receives your visitors’ messages depends on the provider you select**
under **Sohaychat AI Settings**:
* **OpenAI** (https://openai.com) — the default.
* **Google (Gemini)** (https://ai.google.dev) — optional alternative.
**Knowledge Base indexing and search always go to OpenAI**, whichever provider answers
the chat. If you select Google and switch the Knowledge Base on, keep an OpenAI
key saved as well; without one the chatbot answers without consulting your articles.
**What is sent, and when**
* **When a visitor sends a chat message** — the message text and recent conversation
history are forwarded over HTTPS to the selected provider and processed by the
model configured under **Sohaychat AI Settings**. That is `https://api.openai.
com/v1/responses` for OpenAI, or `https://generativelanguage.googleapis.com/v1beta/
models/*:streamGenerateContent` for Google.
* **When you publish or update a Knowledge Base article** — the title and body
are sent in the background to OpenAI Files and Vector Stores (`https://api.openai.
com/v1/files`, `/v1/vector_stores`, `/v1/vector_stores/*/files`) so the chat
can retrieve them. The sync runs in the background, not while you click Save.
This happens on OpenAI regardless of which provider answers the chat.
* **When the chatbot looks something up in your Knowledge Base** — the visitor’s
question is sent to `https://api.openai.com/v1/vector_stores/*/search` to find
matching articles, and the matched article text is then sent on to whichever
provider is generating the reply.
* **On a WooCommerce store, when the chatbot uses a shopping tool** — the answer
it looks up is sent back to the model so it can reply, in the same conversation
as the message that prompted it. Depending on the tool, that is: product names,
descriptions, prices, sale prices, stock status, categories, tags, option names
and values (size, colour), product page and image URLs; the text of the store
pages you have set as Terms, Privacy, Refunds and Returns, plus any Knowledge
Base articles matched to a shipping, returns or refund question; and the contents
of the shopper’s cart — the items in it, their quantities and options, and the
cart totals. This happens only on stores running WooCommerce, and only for the
tools the chatbot actually calls in that conversation.
* **On a WooCommerce store, when a signed-in customer asks about their own orders**—
the order number, its status, the date it was placed, the order total, and the
names, quantities and line totals of what was in it are sent to the model so
it can answer. Up to ten orders at a time. This happens only for a visitor signed
in to a WordPress account, and only for that account’s own orders: the customer
is taken from the current login, and there is no way to ask the chatbot about
anybody else’s.
**What is _not_ sent.** No postal address, phone number, or payment or transaction
detail is ever sent to your AI provider — not from the cart, not from an order,
not from anywhere else. The cart data describes the basket, not the shopper, and
carries no name or email address either. The order lookup is deliberately narrow
for the same reason: a customer asking where their order is needs its status, date
and contents, so billing and shipping addresses, phone numbers, the customer’s own
email address, payment methods and transaction ids are all left out of what the
model is given. Sohaychat never sends WooCommerce customer records or anything from
your checkout.
**Where it goes**
All requests go over HTTPS to `api.openai.com` and, if you select Google, `generativelanguage.
googleapis.com`. The plugin does not contact any other external service — no analytics,
no telemetry, no third-party fonts or CDN assets, and no phone-home for updates.
Updates come from WordPress.org.
**How your API keys are handled**
The API key you enter for a provider under **AI Settings** authenticates that provider’s
requests. Keys are encrypted at rest (AES-256-GCM) in your WordPress database, masked
in the admin UI after the first save, and excluded from the WordPress REST API.
A key is only ever sent to the service it belongs to. Saving a key for a provider
you have not selected stores it but does not use it — that is what lets you switch
back without re-entering it.
**Your responsibilities**
Before activating the plugin, please review the terms of the provider you select—
OpenAI’s [Terms of Use](https://openai.com/policies/terms-of-use) and [Privacy Policy](https://openai.com/policies/privacy-policy),
and if you use Gemini, Google’s [Gemini API Additional Terms of Service](https://ai.google.dev/gemini-api/terms)
and [Privacy Policy](https://policies.google.com/privacy). Note that Google applies
different data-handling terms to free-tier and paid API keys; read the terms for
the tier you are on. Because Knowledge Base indexing runs on OpenAI either way,
a site with the Knowledge Base switched on shares data with OpenAI even when Gemini
answers the chat. Site owners are responsible for obtaining the appropriate legal
basis (consent, contract, legitimate interest, etc.) to share visitor messages with
these services under GDPR, CCPA, and other applicable privacy regimes in the jurisdictions
they operate in. On a WooCommerce store that basis needs to cover the shopping tools
too — what a visitor has put in their cart is information about that visitor, even
though no name or address is attached to it, and an order a signed-in customer asks
about is information about a named account. If you ask visitors for a name and email
before they can reach your team, or switch on the reply emails described under **
Privacy**, the basis needs to cover those as well. If you would rather any of it
never left your site, the shopping tools can be switched off individually in code;
see the FAQ below.
#### Privacy
Conversations and messages are stored in custom database tables on your own site.
For **signed-in visitors**, the plugin registers WordPress’s personal-data exporter
and eraser, so the standard **Tools Export Personal Data** and **Tools Erase Personal
Data** flows include their Sohaychat conversations, matched on their account email.
**Details a visitor gives you in the chat.** If you ask visitors for a name and
email before they can reach your team (**Sohaychat Settings Collect customer details**),
what they type is stored on that conversation — along with whether they accepted
your marketing opt-in, when they accepted it, and the exact wording they were shown
at the time. Those details go into a personal-data export and are removed by an
erasure request, for guests as well as registered users. Because the widget never
verifies an address typed into it, an export keeps two groups apart: conversations
owned by the requester’s account, and conversations that merely carry their email
address. The second group is labelled as unverified, because it may contain somebody
else’s chat.
**Chats from visitors who shared nothing** aren’t tied to an email address, so those
email-based tools can’t locate them. To erase a specific guest conversation, open
it under **Sohaychat Conversations** and delete it (available to users with the
AI-settings capability); it leaves the inbox immediately and is permanently purged
after the retention window — 30 days by default, filterable in code. A visitor can
also delete their own chat from the widget, and every soft-delete follows the same
purge path.
**Emails to visitors.** With **Email visitors when you reply** switched on (**Sohaychat
Settings**, off by default), a reply your team sends to a chat the visitor has already
left is emailed to the address on that conversation. It is the only mail Sohaychat
sends to somebody who is not staff. The email goes out from your own site through
WordPress, not through any third-party service, and carries a one-click link that
stops further emails about that conversation.
**On a WooCommerce store**, the chatbot’s shopping tools read your catalog, your
policy pages, and the visitor’s own cart. What they find is sent to your AI provider
so the model can answer, and it is also saved with the conversation — that is what
lets the product card or cart summary still be there when the visitor scrolls back.
So a stored conversation on a WooCommerce store can contain a snapshot of what that
visitor had in their cart at the time. A signed-in customer who asks about their
own orders leaves the same kind of trace: the order numbers, statuses, dates, totals
and item names the chatbot was given in order to answer. Both are covered by the
same export, erase and retention paths as the rest of the conversation — erasing
the chat erases them with it. No postal address, phone number, or payment detail
is involved in either — see **External services** for the exact list.
See the **External services** section above for what gets sent, and to which service.
## Capturas de pantalla
[⌊The chat launcher sitting in the bottom-right of the site, respecting iOS safe-
area-inset above the home indicator.⌉⌊The chat launcher sitting in the bottom-right
of the site, respecting iOS safe-area-inset above the home indicator.⌉[
The chat launcher sitting in the bottom-right of the site, respecting iOS safe-area-
inset above the home indicator.
[⌊The expanded chat panel mid-conversation, streaming an answer grounded in a Knowledge
Base article.⌉⌊The expanded chat panel mid-conversation, streaming an answer grounded
in a Knowledge Base article.⌉[
The expanded chat panel mid-conversation, streaming an answer grounded in a Knowledge
Base article.
[⌊Shopping in the chat — a product search returning live catalog results, each card
carrying the store's own price, stock, and "Add to cart".⌉⌊Shopping in the chat —
a product search returning live catalog results, each card carrying the store's
own price, stock, and "Add to cart".⌉[
Shopping in the chat — a product search returning live catalog results, each card
carrying the store’s own price, stock, and “Add to cart”.
[⌊Adding to the cart from the chat, with the running cart, totals, an Undo button,
and a link straight to checkout.⌉⌊Adding to the cart from the chat, with the running
cart, totals, an Undo button, and a link straight to checkout.⌉[
Adding to the cart from the chat, with the running cart, totals, an Undo button,
and a link straight to checkout.
[⌊Sohaychat → Conversations — the admin SPA listing recent conversations with filter,
search, and assignee controls.⌉⌊Sohaychat → Conversations — the admin SPA listing
recent conversations with filter, search, and assignee controls.⌉[
**Sohaychat Conversations** — the admin SPA listing recent conversations with filter,
search, and assignee controls.
[⌊A single conversation opened in the admin, showing message history and the reply
composer.⌉⌊A single conversation opened in the admin, showing message history and
the reply composer.⌉[
A single conversation opened in the admin, showing message history and the reply
composer.
[⌊Sohaychat → AI Settings → Spend protection — daily per-visitor and site-wide token
caps with the live usage readout.⌉⌊Sohaychat → AI Settings → Spend protection —
daily per-visitor and site-wide token caps with the live usage readout.⌉[
**Sohaychat AI Settings Spend protection** — daily per-visitor and site-wide token
caps with the live usage readout.
[⌊Sohaychat → Dashboard — conversation volume and trends, recent activity, recently
published Knowledge Base articles, and quick actions.⌉⌊Sohaychat → Dashboard — conversation
volume and trends, recent activity, recently published Knowledge Base articles,
and quick actions.⌉[
**Sohaychat Dashboard** — conversation volume and trends, recent activity, recently
published Knowledge Base articles, and quick actions.
## Instalación
1. From the **Plugins Add New** screen, search for **Sohaychat** and click **Install
Now**, then **Activate**. A new **Sohaychat** menu appears in your WordPress admin
sidebar.
2. Visit **Sohaychat AI Settings**, choose your AI provider, and paste that provider’s
API key into its field. (If you don’t have one yet, create an OpenAI key at platform.
openai.com or a Gemini key at aistudio.google.com/apikey.) Click **Save**. Keys
are stored encrypted — the field shows a masked placeholder from now on.
3. While still on **AI Settings**, pick the model you want to use, set a daily token
cap under **Spend protection**, and (optionally) write a welcome message that greets
visitors when they open the chat.
4. Add at least one article under **KB Articles Add New**. This is the content the
chatbot draws from. You can write as many as you like; longer-form support articles
work best.
5. Visit **Sohaychat KB Settings Dashboard** and click **Sync All Articles**. The
sync runs in the background — articles become searchable to the chatbot within
a minute or two.
6. Visit your site’s front-end. The chat launcher appears in the bottom-right corner.
Click it to open the chat and try a question your Knowledge Base can answer.
## FAQ
### Which AI provider should I pick, and can I switch later?
Sohaychat works with **OpenAI** or **Google (Gemini)** — choose one under **Sohaychat
AI Settings**. OpenAI is the default. You can switch at any time; each provider’s
key and model choice are stored separately, so switching back does not mean re-entering
anything.
One thing to know before choosing: the Knowledge Base indexes and searches your
articles through OpenAI whichever provider answers the chat. If you select Gemini
and use the Knowledge Base, keep an OpenAI key saved as well. Without one, the chatbot
still replies but stops consulting your articles.
### Do I need an account with an AI provider?
Yes. Sohaychat is a front-end for someone else’s models — without an API key the
plugin has no model to call and the chat cannot answer questions. The provider bills
you directly per token; Sohaychat does not resell access. The **Spend protection**
controls under **AI Settings** let you cap daily token usage to keep costs predictable.
### How much will it cost me?
Providers charge per token, and the per-token rate depends on the model you pick(
the cheaper models cost a fraction of a cent per chat reply). A small support site
typically stays in single-digit dollars per month. The **Spend protection** controls
under **AI Settings** let you cap daily token usage — once the cap is hit, the plugin
stops calling the provider for the rest of the day. The **Diagnostics** page shows
today’s usage so you can spot a runaway loop or a hostile bot before it costs you
real money.
### Will the chatbot make things up?
The chatbot is _grounded_ in the articles you publish — if it can’t find a matching
article, it tells the visitor it doesn’t know instead of inventing an answer. To
improve answer quality, publish articles covering the questions you actually get
asked, and write a fallback “Contact us” article so the chatbot can route off-topic
questions to your human support team.
### Where can I see what visitors are asking?
**Sohaychat Conversations** lists every chat — search them, filter by status, assign
a chat to a teammate, or reply yourself. Turn on human handoff and you also get
views for visitors waiting to talk to a person and for conversations your team has
handled. The **Diagnostics** page shows OpenAI errors if you’re investigating a
technical problem.
### Can a real person take over a chat from the assistant?
Yes. Turn on **Human handoff** under **Sohaychat Settings**, and your team can
step into any conversation. While someone is handling a chat the assistant stops
replying, and the visitor sees that person’s name and picture on the answers rather
than the AI marker. Hand it back and the assistant picks up again, with the whole
exchange still in front of it.
Visitors can ask for a person with a button above the message box, the assistant
can fetch one when it gets stuck, and you can simply jump in — replying to a conversation
takes it over.
The setting is off until you switch it on, because handing someone to a person who
is not there is worse than not offering it. Set the hours your team actually covers;
outside them the widget stops offering, and anyone who asks anyway gets a message
you write.
### Do I have to collect names and email addresses?
No — that’s your call, under **Sohaychat Settings Collect customer details**.
You can require visitors to sign in, ask them for a name and email, or ask for nothing
at all. Whichever you pick, the chatbot still answers everyone straight away: the
requirement applies only to reaching a person, so nobody meets a form before they
have been helped. A visitor who gave their details in an earlier chat is not asked
again.
Sites upgrading from an earlier version keep allowing anonymous chats, so nothing
changes for visitors already talking to you. New installs start on **Require customers
to sign in**, which is the one the settings screen marks as recommended — it identifies
people by their account rather than by an address they typed, which Sohaychat has
no way to verify.
The one exception is order lookups: the chatbot will only discuss a customer’s orders
with someone signed in, whatever you choose here.
### Will visitors know when we reply after they’ve left?
Only if you switch it on. **Email visitors when you reply**, under **Sohaychat
Settings**, emails your reply to a visitor who has already closed the chat — otherwise
your answer sits in a thread nobody is watching. It’s off by default, because it
is the only mail Sohaychat sends to somebody who isn’t staff.
It needs an address to write to, so it does nothing unless the visitor is signed
in or you’re asking for a name and email. It waits a couple of minutes first and
skips the mail entirely if the visitor came back and read the reply on screen, sends
at most one email per conversation every 15 minutes however fast your team types,
and puts a one-click link in every message that stops further emails about that
chat.
### How do I know when somebody is waiting to talk to us?
Four ways, so you don’t have to sit watching the inbox. A **Waiting for a Person**
view in **Sohaychat Conversations** lists them oldest first. The browser tab shows
a count, so a background tab still tells you. An email goes out when a request comes
in — to addresses you choose, or whoever the conversation is assigned to. And the
conversation itself carries a banner with a **Take over** button.
If nobody picks it up within the time you set (10 minutes by default), the assistant
takes the conversation back and tells the visitor honestly that nobody was available,
rather than leaving them waiting.
### Does human handoff slow my site down?
Only while it’s switched on, and only for visitors with the chat window actually
open — those windows quietly check for new replies. Nothing checks while the chat
is closed, while the browser tab is in the background, or after ten quiet minutes.
If your host is tight on resources, that background checking is the thing to weigh.
A developer can slow it down without touching the plugin’s code. The full arithmetic
is in the handoff documentation in the plugin’s GitHub repository.
### Will my visitors’ chats be visible to other admins?
By default, every WordPress administrator can read every conversation. The plugin
ships with five granular capabilities so you can delegate access — for example,
give a support agent the ability to read and reply to chats without granting them
access to AI Settings. See the developer questions below for an overview, and the
capability documentation in the plugin’s GitHub repository for the full matrix with
worked role-configuration examples.
### Does this slow down my site?
A tiny launcher (~8 KB) loads on every page. The full chat code only downloads when
a visitor actually clicks to open the chat, so most visitors never download it.
No third-party scripts, fonts, or trackers are loaded from external CDNs.
### Why don’t my translation or session-recording plugins see the chat widget?
The chat renders inside an isolated container so that your theme’s styling cannot
break the chat, and the chat’s styling cannot change your site’s fonts, colours,
borders, or spacing. That isolation is deliberate — it is what makes the widget
look and behave the same way on every theme.
The trade-off is that other plugins and scripts which scan your pages for content
do not look inside that container. In practice:
* **Translation plugins** (TranslatePress, Weglot, and similar) will not translate
the chat’s own wording. This does not affect your visitors’ answers — the chatbot
replies in the language the visitor writes in — and Sohaychat’s own buttons and
labels are translated through WordPress’s standard translation files.
* **Session-replay and heatmap tools** (Hotjar, Clarity, FullStory) record the
widget as a blank area.
* **Accessibility overlays** that restyle a page from the outside will not restyle
the chat.
Screen readers and keyboard navigation are unaffected — assistive technology reads
the accessibility tree, which the isolation does not hide.
The container is open rather than sealed, so a script that explicitly supports this
kind of isolation can still reach the chat’s content. Most third-party scripts do
not.
### What can shoppers do in the chat on a WooCommerce store?
On stores running WooCommerce 7.0 or later, a shopper can:
* **Search and browse your catalog** — “show me waterproof jackets under $100”,“
what’s new?”, “what’s on sale?” — results come back as product cards with photo,
price, and stock.
* **Look at one product in detail**, including its options, so they can pick a
size or colour without leaving the chat.
* **See live stock and prices**, read from your store at the moment they ask.
* **Ask about shipping, returns, refunds, and payment** — answered from your WooCommerce
store pages first, then from Knowledge Base articles you’ve tagged “policy” or“
faq”.
* **Manage their cart** — add an item, change a quantity, or remove a line, each
with an Undo button.
* **Ask about their own orders**, if they are signed in — “where’s my order?”, “
what did I buy last month?” — answered with the order’s status, date, total and
contents. Signing in is always required for this, whichever **Collect customer
details** option you pick, and a customer can only ever see their own orders:
the chatbot takes the customer from the current login and has no way to be pointed
at anybody else. Addresses, phone numbers and payment details are never part
of the answer.
The chatbot cannot take payment or place an order. When the shopper is ready it
hands them to your normal WooCommerce checkout.
### Does the plugin work without WooCommerce?
Yes. The chat widget, Knowledge Base, and Conversations inbox work on any WordPress
site — the shopping tools simply never appear. On stores running WooCommerce 7.0
or later they switch on by themselves, with no configuration. The plugin also declares
HPOS and Cart-Checkout-Blocks compatibility so stores don’t see an “uncertified
plugin” banner.
### Can I hide the widget on specific pages?
Uncheck **Show widget** under **Sohaychat AI Settings** to hide it everywhere.
To hide it only on certain pages or post types, see the developer questions below.
### Can I customize the welcome message and system prompt?
Yes. **Sohaychat AI Settings** has a Welcome Message field (max 280 characters).**
Sohaychat KB Settings Settings** has a Custom System Prompt field (max 4000 characters)
for the instructions the chatbot follows when it generates answers. The Custom System
Prompt field recognises `{site_name}` and `{current_date}` placeholders — they are
replaced with your site’s title and today’s date before the prompt is sent to the
model.
### Where can visitors read my Knowledge Base?
At **/knowledge-base/** on your site. The page lists your KB categories as cards
with an article count on each, a search box, and the articles filed under each category.
Clicking a card opens that category; searching stays inside the Knowledge Base rather
than dropping visitors into your site-wide search results.
These pages are public and indexable on purpose — support articles answer the questions
people type into search engines, and the chatbot cites the same URLs when it uses
an article to answer.
### Can I change the Knowledge Base URL?
Yes. **Sohaychat KB Settings Settings** has a **URL Base** field. Set it to `docs`,`
help`, `support` — whatever suits your site — and the index and every article move
together, from `/knowledge-base/getting-started/` to `/docs/getting-started/`.
Two things worth knowing before you change it. Links to the old addresses stop working,
including any a search engine has already indexed, so if the Knowledge Base has
been public for a while consider adding redirects. And a base that’s already taken—
by one of your pages, by another plugin, or by WordPress itself (`category`, `author`,`
tag`, and so on) — is refused with an explanation rather than accepted; pick another,
or move the page that’s using it first.
Category pages have their own **Category URL Base** field just below, defaulting
to `kb-category`. It has to stay separate from the base above — a value equal to
it, or sitting inside it, is refused, because the two would compete for the same
URLs.
You don’t need to re-save your permalinks afterwards. Sohaychat rebuilds the URL
rules itself.
### Can I change how the Knowledge Base pages look?
They’re deliberately plain, and they inherit your theme’s fonts, colours, and link
styling so they don’t look bolted on. If you want to go further, your theme can
replace any of it: copy `archive-kb.php`, `taxonomy-kb-category.php`, `search-kb.
php`, or any file from `parts/` out of the plugin’s `templates/` folder into a `
sohaychat/` folder in your theme, and Sohaychat will use yours instead. Block themes
that define their own Knowledge Base template keep it untouched. `docs/KB-ARCHIVE.
md` in the GitHub repository documents each template and what it receives.
### Where are my API keys stored?
Encrypted with AES-256-GCM in your WordPress database. The admin UI shows a masked
placeholder once you’ve saved a key, and the values are excluded from the WordPress
REST API. Each key is only ever sent to the service it belongs to.
### What happens to my data if I uninstall Sohaychat?
Uninstalling deletes the plugin’s own database tables (conversations, messages,
sync jobs, diagnostic logs), its settings, and the capabilities it added. **Your
Knowledge Base articles are kept** — they’re regular WordPress content, so removing
the plugin doesn’t delete them, and they’re still there if you reinstall. If you
want them gone too, delete the articles under **KB Articles** before you uninstall.
### Does Sohaychat work on WordPress Multisite?
Yes. Each site in the network keeps its own conversations, Knowledge Base, and settings—
nothing is shared across the network. Network-activate to enable Sohaychat everywhere(
each site sets itself up on first load) or activate it per-site. Uninstalling from
the network removes Sohaychat’s data from every site.
### For developers
The questions below cover code-level customization. Sohaychat exposes 61 filters
and 15 actions in total; the most-used ones appear here, and the full catalog lives
in `docs/HOOKS.md` in the plugin’s GitHub repository, alongside `docs/CAPABILITIES.
md` for the full capability matrix and `docs/KB-ARCHIVE.md` for the Knowledge Base
templates.
### How do I customize the plugin with code?
The most commonly customized filters:
* `sohaychat_should_render_widget` (bool) — per-request gate on the chat widget.
Combine with `is_singular()` / `is_product()` to scope the widget to specific
pages.
* `sohaychat_allowed_openai_models` / `sohaychat_allowed_google_models` (string[])—
allowlist of model slugs the proxy may call for each provider. Restrict to cheaper
models to cap spend.
* `sohaychat_default_ai_provider` (string) — which provider answers the chat when
no choice is saved in the admin.
* `sohaychat_provider_options` (array) — provider-specific request settings, such
as Gemini’s safety thresholds, thinking budget, or search grounding.
* `sohaychat_help_url` and `sohaychat_upgrade_url` (string) — override the admin-
header “Help” and “Upgrade” links for resellers.
* `sohaychat_admin_conversation_scope` — restrict which conversations a non-admin
operator can see.
* `sohaychat_tools` — the resolved tool list for the request. Remove an entry and
the chatbot is never told that tool exists, so it can neither call it nor send
its data to your AI provider.
Example — keep the WooCommerce catalog answers but never let the cart leave the
site:
```
add_filter( 'sohaychat_tools', function ( $tools ) {
unset( $tools['sohaychat-wc/get-cart'], $tools['sohaychat-wc/update-cart'] );
return $tools;
} );
```
The keys are the tool names: `sohaychat-wc/search-catalog`, `sohaychat-wc/lookup-
catalog`, `sohaychat-wc/get-product`, `sohaychat-wc/search-shop-policies-and-faqs`,`
sohaychat-wc/get-cart`, `sohaychat-wc/update-cart`, `sohaychat-wc/get-orders` for
a signed-in customer’s own orders, and `sohaychat-kb/get-information` for the Knowledge
Base lookup. Returning an empty array disables tool use entirely — the chatbot still
replies, just with no way to look anything up.
Example — hide the widget everywhere except the WooCommerce shop and product pages:
```
add_filter( 'sohaychat_should_render_widget', function ( $enabled ) {
if ( ! $enabled ) { return false; }
return function_exists( 'is_shop' ) && ( is_shop() || is_product() );
} );
```
The constants on `Bengal_Studio\Sohaychat\Sohaychat_Hooks` are the recommended form
for new code; the legacy literal form continues to work across releases.
### How do I delegate access to non-admin roles?
Five granular capabilities let you delegate parts of the plugin to non-admin roles:
* `sohaychat_manage` — AI Settings page, provider selection, API key entry, model
selection, and creating / editing / deleting quick replies. Implicitly grants
all four other plugin caps.
* `sohaychat_view_conversations` — Sohaychat menu, Dashboard + Conversations submenus(
read-only), and reading the quick replies the composer offers. Non-admin users
with this cap are scoped to “assigned to me or unassigned” conversations.
* `sohaychat_reply_conversations` — everything `sohaychat_view_conversations` grants,
plus operator reply, assignee changes, pin / unpin, close / reopen. Implicitly
grants `sohaychat_view_conversations`.
* `sohaychat_manage_kb` — KB Settings admin page and KB sync routes.
* `sohaychat_view_logs` — Diagnostics admin page (read-only). Clearing the log
buffer is escalated to `sohaychat_manage` for forensics integrity.
WordPress’s built-in `manage_options` capability implicitly grants all five, so
administrators keep working unchanged. Use Members, User Role Editor, or WP-CLI (`
wp cap add sohaychat_view_conversations`) to delegate caps to non-admin roles.
See `docs/CAPABILITIES.md` in the GitHub repository for the full matrix, every REST
route’s required cap, three worked role-configuration examples, and the conversation-
scope filter contract.
### How do I adjust rate limits or the daily OpenAI token budget in code?
Three independent limiter filters. The chat-message rate limit (`limit` requests
per rolling `window` seconds, per visitor):
```
add_filter( 'sohaychat_rate_limit_options', function ( $opts ) {
$opts['limit'] = 60;
$opts['window'] = 60;
return $opts;
} );
```
Behind Cloudflare or another reverse proxy, enable proxy-aware client-IP detection
so per-visitor limits key off the real visitor rather than the proxy:
```
add_filter( 'sohaychat_rate_limit_options', function ( $opts ) {
$opts['proxy_support'] = true;
return $opts;
} );
```
Enable `proxy_support` **only** when your site is reachable exclusively through
the trusted proxy, and that proxy overwrites the `CF-Connecting-IP` / `X-Real-IP`/`
X-Forwarded-For` headers on every request. On an origin that’s also reachable directly,
a visitor could forge those headers to sidestep per-visitor limits; the site-wide
daily token budget still caps total spend.
The public `/auth/guest-token` mint rate limit (separate so token-mint amplification
protection can be tuned independently):
```
add_filter( 'sohaychat_auth_rate_limit_options', function ( $opts ) {
$opts['limit'] = 5;
$opts['window'] = 60;
return $opts;
} );
```
The daily OpenAI token budget (caps also configurable under **AI Settings Spend
protection**; ceilings reset at UTC midnight; setting either value to 0 disables
that particular ceiling):
```
add_filter( 'sohaychat_usage_tracker_options', function ( $opts ) {
$opts['site_cap'] = 5000000;
$opts['actor_cap'] = 25000;
return $opts;
} );
```
The live readout on the Diagnostics page shows today’s usage so you can spot a runaway
loop before it 429s real visitors.
### Can I disable the KB search cache?
KB vector-search results are memoized in the `sohaychat_kb` object-cache group for
5 minutes by default. To shorten the window, lengthen it, or disable the cache entirely,
use the `sohaychat_kb_search_cache_ttl` filter (return 0 to disable):
```
add_filter( 'sohaychat_kb_search_cache_ttl', '__return_zero' );
```
KB sync events flush the cache automatically, so content updates don’t get masked.
### Why does the streaming response cut off behind my CDN?
The plugin sets `Cache-Control: no-cache`, `X-Accel-Buffering: no`, and clears output
buffers, but some CDNs still buffer Server-Sent Events. If your CDN supports it,
mark the chat REST route as bypassing the cache and disable transformations on the
response.
### Where can I see streaming/proxy errors?
**Sohaychat Diagnostics** shows the last 100 plugin log entries with timestamps
and context. Each entry also fires the `sohaychat_log_error` action for integration
with Sentry, Stackdriver, Query Monitor, etc.
## Reseñas
No hay reseñas para este plugin.
## Colaboradores & Desarrolladores
“Sohaychat – AI Chatbot & Support Agent for WooCommerce” es software de código abierto.
Las siguientes personas han contribuido a este plugin.
Colaboradores
* [ Mithun Biswas ](https://profiles.wordpress.org/bhoot/)
[Traduce “Sohaychat – AI Chatbot & Support Agent for WooCommerce” a tu idioma.](https://translate.wordpress.org/projects/wp-plugins/sohaychat)
### ¿Interesado en el desarrollo?
[Revisa el código](https://plugins.trac.wordpress.org/browser/sohaychat/), echa
un vistazo al [repositorio SVN](https://plugins.svn.wordpress.org/sohaychat/), o
suscríbete al [registro de desarrollo](https://plugins.trac.wordpress.org/log/sohaychat/)
por [RSS](https://plugins.trac.wordpress.org/log/sohaychat/?limit=100&mode=stop_on_copy&format=rss).
## Historial de cambios
#### 1.4.0
* New — quick replies. Save the answers your team types over and over, then drop
one into a reply from the lightning-bolt button in the composer or by typing `/`
in an empty draft; inserting fills the draft and never sends on its own. Managed
under **Sohaychat Quick replies**, shared across the site, with four starter
replies you can edit or delete.
* New — choose what a visitor must share before somebody from your team joins their
chat: sign in, give a name and email, or nothing. Set it under **Sohaychat Settings**.
The chatbot still answers everyone; the widget asks only when somebody asks for
a person, on its own screen, and not again if they gave their details in an earlier
chat. Upgrading sites keep allowing anonymous chats; new installs start on sign-
in.
* New — an optional marketing opt-in beside the name and email fields, with wording
you write yourself. What a visitor agreed to is stored with the exact wording
they were shown.
* New — order history in the chat. On a WooCommerce store, a signed-in customer
can ask the chatbot about their own orders — status, dates, contents. Signing
in is always required for this, whichever option you picked above: the chatbot
takes the customer from the current login and cannot be pointed at anybody else’s
orders. Addresses, phone numbers and payment details are never sent to the chatbot.
* New — email visitors when you reply. Answer a chat the visitor has already left
and Sohaychat can email them your reply. Off by default, under **Sohaychat Settings**.
It sends only when they aren’t still reading the chat, at most once per conversation
every 15 minutes, always with a one-click link to stop further emails about that
conversation. It needs an address, so it does nothing unless the visitor is signed
in or you are asking for a name and email; with it on, the name-and-email screen
tells visitors the details are so you can reply after they leave.
* New — **Sohaychat Conversations** shows visitors by the name they gave — in
the list, the customer panel and the dashboard — with their email and, where
they opted in, when they agreed to marketing. Visitors who shared nothing still
read as “Guest”.
* Changed — a visitor asked to sign in before reaching your team keeps their chat;
signing in used to clear the guest session and take the conversation with it.
* Changed — names, email addresses and marketing consent given in the chat are
included in a visitor’s personal-data export and removed by an erasure request,
including for visitors who were never registered users. An export keeps chats
owned by the requester’s account apart from chats that merely carry their email
address; the widget cannot verify a typed address, so that second group is labelled
unverified and may contain somebody else’s conversation.
* Changed — the plugin is now called **Sohaychat**, matching its address on WordPress.
org, and is listed as “Sohaychat – AI Chatbot & Support Agent for WooCommerce”.
Only the name changes: your settings, API keys, saved conversations and Knowledge
Base articles are untouched, the update installs over your existing copy, and
visitors see no difference.
* Changed — in **Sohaychat Conversations**, the search box now sits in the page
header and the sort control beside the “Inbox” title, giving the conversation
list its full height. The header shows the logo mark on its own.
* Changed — the header of the Dashboard, Conversations and Quick replies screens
now shows which version of Sohaychat is installed, and **Sohaychat Diagnostics**
lists it at the top of the health card along with the database schema version.
The WordPress footer is hidden on these screens, so until now the version was
only on the Plugins list.
* Removed — the `getInformation` alias for the Knowledge Base lookup tool. Since
1.1.0 every chat request offered the chatbot that tool twice, once under its
old name; only `sohaychat-kb__get-information` is offered now. Older conversations
keep their citations. If a **Custom System Prompt** under **Sohaychat KB Sync**
tells the assistant to call `getInformation`, change that to `sohaychat-kb__get-
information`.
* Fixed — a site on Google with the model left on **Use built-in default** got
a chat that failed on every message, because newly issued Gemini API keys can
no longer use `gemini-2.5-flash`. The default is now `gemini-3.6-flash`, Google’s
named replacement, and sites on the default pick it up with this update. If you
selected `gemini-2.5-flash` yourself, nothing changes — older keys can still
use it; if yours cannot, pick another model under **Sohaychat AI Settings**.
* Fixed — table cells in the Sohaychat admin screens now use the plugin’s own font
size and line height.
* Fixed — deactivating or uninstalling the plugin now clears every event it had
scheduled with WordPress’s cron; the per-article Knowledge Base sync and the
notification emails used to be left behind, doing nothing but never going away.
* Fixed — on a short or zoomed browser window, scrolling the page to reach the
bottom of the WordPress admin menu no longer pushes the Conversations workspace
off the top; the workspace stays under the admin bar and only the menu scrolls.
* For developers — four new filters: `sohaychat_quick_replies_max_body_length`
and `sohaychat_quick_reply_seed_defaults` for quick replies, `sohaychat_login_url`
for sites whose sign-in lives somewhere other than the WooCommerce My Account
page or `wp-login.php`, and `sohaychat_visitor_notification_body` for the wording
of the visitor reply email. Managing quick replies needs the `sohaychat_manage`
capability; reading them — all the composer picker does — needs only `sohaychat_view_conversations`.
This release also runs a one-time, automatic database update on upgrade.
#### 1.3.0
* New — a real person can take over a chat. When the chatbot isn’t enough, one
of your team can step into the conversation: the visitor sees that person’s name
and picture on the replies, new messages arrive without a page reload, and the
chatbot stays quiet until the chat is handed back. Switched off by default —
turn it on under Sohay Settings.
* Three ways a handoff starts — a “Talk to a person” button in the chat, the chatbot
asking for someone when it can’t resolve a question, and a “Take over” button
on the conversation. Replying to a conversation takes it over as well.
* Set the hours your team is around, week by week, in your site’s own timezone,
with your own message for visitors who ask outside them. A request nobody answers
goes back to the chatbot after a timeout you set, and the visitor waits out a
short cooldown before asking again.
* New “Waiting for a Person” and “Handled by a Person” views in Sohay Conversations,
each with a count. Waiting lists the longest wait first, so nobody jumps ahead
of someone who has waited longer.
* Four ways to notice a waiting visitor — the Waiting view, a count in the browser
tab, a banner on the conversation, and an email to addresses you choose (falling
back to whoever the chat is assigned to, then the site admin). One email per
conversation, and none at all if a colleague has already picked it up.
* New — the Knowledge Base has a real index. It now has a landing page of its own:
your categories as cards with an article count on each, a search box, and the
articles filed under each category. Category pages and Knowledge Base searches
get matching pages. Until now these addresses fell through to whatever your theme
does with an archive, which for most themes meant a bare reverse-chronological
list of titles.
* New — the Knowledge Base address is yours to choose. **Sohay KB Settings Settings**
has a **URL Base** field: set it to `docs`, `help`, `support`, whatever suits.
The index and every article move together and the URL rules rebuild themselves,
with no need to re-save your permalinks. A base already taken by one of your
pages, another plugin, or WordPress itself is refused with an explanation rather
than quietly breaking that address. Sites that never touch the setting stay on`/
knowledge-base/`.
* Your theme can replace any of the new Knowledge Base pages — copy a template
out of the plugin’s `templates/` folder into a `sohaychat/` folder in your theme
and Sohay uses yours instead. Block themes that already define their own Knowledge
Base template keep it untouched.
* Changed — Knowledge Base addresses no longer sit under your permalink prefix.
On sites whose permalinks start with a fixed prefix such as `/blog/`, the Knowledge
Base was being served from `/blog/knowledge-base/`; it now sits at `/knowledge-
base/`. Most sites, which use a prefix-free permalink structure, are unaffected.
If the old addresses are linked or already indexed, add redirects for them.
* Fixed — replies you type in **Sohay Conversations** were coming back labelled“
AI Draft” with the chatbot’s avatar, so your own message looked like machine
output. They now carry your name and picture, on both the admin thread and the
visitor’s.
* Fixed — PHP 8.4 was printing a deprecation notice on every request that loaded
the chatbot’s tools.
* Fixed — WordPress was printing a “translation loaded too early” notice above
every page, front end and admin alike, on sites with debugging switched on.
* Security — the message endpoint no longer takes a staff identity from the visitor’s
browser, so a crafted request can’t post a message that renders as coming from
a named member of your team, nor fake a “joined the conversation” event. The
chat endpoint also drops any instructions a crafted client tries to slip in alongside
your own chatbot instructions.
* For developers — eight new hooks for handoff (`sohaychat_handoff_available`, `
sohaychat_handoff_timeout`, `sohaychat_handoff_poll_intervals`, `sohaychat_handoff_notify_recipients`,`
sohaychat_handoff_rate_limit_options`, `sohaychat_handoff_requested`, `sohaychat_handoff_started`,`
sohaychat_handoff_ended`) and four for the Knowledge Base index (`sohaychat_kb_slug`,`
sohaychat_kb_category_slug`, `sohaychat_kb_reserved_slugs`, `sohaychat_kb_articles_per_section`).
This release also runs a one-time, automatic database update on upgrade.
Older releases are listed in changelog.txt.
## Meta
* Versión **1.4.0**
* Última actualización **hace 1 día**
* Instalaciones activas **Menos de 10**
* Versión de WordPress ** 6.6 o superior **
* Probado hasta **7.1.1**
* Versión de PHP ** 8.1 o superior **
* Idioma
* [English (US)](https://wordpress.org/plugins/sohaychat/)
* Etiquetas
* [AI](https://cl.wordpress.org/plugins/tags/ai/)[chatbot](https://cl.wordpress.org/plugins/tags/chatbot/)
[customer support](https://cl.wordpress.org/plugins/tags/customer-support/)[knowledge base](https://cl.wordpress.org/plugins/tags/knowledge-base/)
[woocommerce](https://cl.wordpress.org/plugins/tags/woocommerce/)
* [Vista Avanzada](https://cl.wordpress.org/plugins/sohaychat/advanced/)
## Calificaciones
Aún no se han enviado valoraciones.
[Tu reseña](https://wordpress.org/support/plugin/sohaychat/reviews/#new-post)
[Ver todas las reseñas](https://wordpress.org/support/plugin/sohaychat/reviews/)
## Colaboradores
* [ Mithun Biswas ](https://profiles.wordpress.org/bhoot/)
## Soporte
¿Tienes algo que decir? ¿Necesitas ayuda?
[Ver el foro de soporte](https://wordpress.org/support/plugin/sohaychat/)