Solutions · Online commerce
We connect the assistant to the store catalogue through its public gateway, put it on the channels where customers already write, and give it one rule it cannot break: do not state a price that is not published in the store. When it goes beyond its role, it hands the conversation to a human, with evidence.
Already builtIt can be checked from the outside, without asking us. Our catalogue point delivered to a distributor responds 200 and says “154 results”, and his public shop interface, queried directly, returns the `x-wp-total: 154` header — the same figure, two independent sources, 06.09.2026. The second implementation is the catalogue function in the assistant platform: `storeCatalog.service.js` plus three built-in tools the agent can call during the conversation. The reservation we state before contract: the WhatsApp template messages do not exist in the platform code, so we do not promise any proactive message outside the 24-hour window; and the catalogue path sits on a development branch that is not merged into the trunk — it is delivered for the shops we connected, not switched on by default for everyone.
A store assistant does not break because it does not understand the question. It breaks because it answers from a copy of the catalogue. Someone exported the products once, pasted them into a file, and since then the assistant has been reading an old photograph of the store: the price from three weeks ago, the stock from before the weekend. It works perfectly until the first price change and until the first sold-out product — and then it is wrong with conviction, which is worse than staying silent. In commerce this is not a nuance error: the customer comes to the store with the price the bot told them.
Our choice is simple and has consequences: the catalogue is not copied, it is read. For WooCommerce stores, the Store API interface is public — so the connection is made with the site address, without a consumer key and without a secret. When the customer asks about a product, the agent calls a tool, the tool asks the store, the store replies with the current price and availability. What appears in the conversation is what is in the store, not what was there when the integration was made.
The cost of this choice is visible in code, not hidden: the catalogue is loaded paginated, up to thirty pages of one hundred products each, kept in a ten-minute temporary memory per site, and normalised into a single form, read without changes by all consumers — including the product carousel in messaging, which needs a numeric price, and the widget on the page. Ten minutes is the compromise: a price change made now is visible in at most ten minutes, not instantly. We state the figure so you can challenge it.
The rest of the limits do not come from us, but from channels, and it is more honest to know them before: Meta rejects free text outside the 24-hour window from the customer's last message, Instagram has no product carousels at all, and a photo sent by the customer is marked in the conversation, not attached automatically to an order. Each of these sentences is cited below with file and line.
What it covers
The agent has three built-in tools on top of a shared catalogue service: `store_catalog_search` for search, `store_catalog_match` for matching a customer's wording to a specific product, `store_catalog_product` for the full sheet. They are not tools written separately for each store — they are a platform function. The practical difference: when we fix something in matching, it is fixed for all connected stores at once.
The tool result comes from your store, not from a file from us. The temporary memory is ten minutes per site, and the catalogue is traversed paginated — up to 30 pages of 100 products each. The consequence you must accept: a price change appears in the conversation with a delay of at most ten minutes. The consequence you gain: there is no scenario in which the agent repeats for months a price taken out of the store.
Six channels have their own code in the platform: Messenger, Instagram Direct, Telegram, the widget on the page, a local classified ads platform, and WhatsApp via Cloud API on Graph v22.0. This is not a single “chat” renamed six times: each channel has its own formatting rules and its own failure modes, and we also check the ugly case — an expired page token silently stops the channel if it is not monitored.
The Store API is public, so we do not ask for your `consumer_key` and `consumer_secret`. This is not a convenience, it is a risk decision: some of the hand-written tools that this path replaced held store keys written in clear text in the database. The new path replaced 109 hand-written tools, of which 28 were HTML scrapers — that is, integrations that broke at the first store theme change.
On Messenger, the carousel is shown only when three conditions are met at the same time; if one is missing, the reply stays text, it does not break. On Instagram there is no product carousel — Meta does not have generic templates on Instagram, so nobody can deliver that there, whatever the offer says. It is the kind of sentence we prefer you to hear from us before the contract.
Outside the 24-hour window from the customer's last message, Meta rejects free text with error 131047, and the message remains marked as failed in the platform. Template messages — the only legitimate way to write first after the window — do not exist in the platform code: a search by the `template` type returns zero results, only the `text` type is sent. So: abandoned cart recovery on WhatsApp at 48 hours is something we cannot promise today.
The Meta webhook really resends the same message: deduplication is done by message identifier, with 120 seconds of memory. And the customer who writes “hello”, “do you have”, “the black model” on three lines receives a single reply to everything they wrote, not three partial replies — messages are gathered into a 15-second buffer. In commerce this matters more than it seems: three partial replies to a single intention look exactly like a robot.
The conversation thread has an explicit `bot` or `human` state. The handover log knows three actions: handover by a human, return to bot, automatic reactivation. Separately, the thread has a response time compliance state — `ok`, `warning`, `breached` — so it is visible which conversation was left without a human reply, not just how many there were.
It does not take payment. It does not create the order in the store if the store does not have a write path — reading is public, writing is not. It does not attach the photo sent by the customer to an order: the received photo is marked in the conversation, that is all, and PDF generation does not exist in the platform. And it does not repeat a customer's previous order without authorised access to their history. Each of these can be built, but as a separate task, not as a tick in the offer.
Traseul
The first check, not the last: we request the catalogue from outside and count what comes back. If the store is on WooCommerce with Store API active, the integration does not need keys. If not, we move to authentication — and then the key becomes something that is managed, with everything that implies. We deliver the result of this check in writing, including when the answer is that it cannot be done.
Meta connection is done through Embedded Signup. For each channel we check not only the first successful message, but also what happens when the token expires or when the store does not respond. We deliver the connected channels and the written list of behaviour for each failure mode.
Each tool has a written description for the model, typed parameters and its own execution time limit — 15 seconds by default. The agent's role explicitly states what it is not allowed to claim: unpublished price, delivery time, availability it has not read. We deliver the agent configuration and the list of tools attached to it — not all the platform's tools, only those it needs.
We start with handover to a person configured and with query logging enabled, so that it is visible which fragments the agent used and with what scores. From there, the similarity threshold and the number of fragments per question are adjusted. We deliver a conversation report with the adjustment decisions, not just a started assistant.
The data
The rules differ from one industry to another. These are the ones that apply in online retail.
A case
The situation
A distributor in Chişinău sold through a WooCommerce shop and answered product questions on messaging channels. The obvious integration — a product export placed in the agent's knowledge base — would have worked until the first discount campaign.
What we built
We connected the catalogue through the shop's public interface, which does not require keys, and placed three tools on top of it that the agent calls in conversation: search, match and product sheet. The results are normalised into a single form, read the same by the messenger carousel and the page widget, so that there are not two truths about the same price.
What came out
The check can be done from the outside, without taking our word for it: our catalogue endpoint responds 200 and reports 154 results, and the shop's public interface, queried directly, returns the `x-wp-total: 154` header. The same figure, two independent sources, on the same day.
What the case does not say
The figure is for that day, 06.09.2026, and changes when the distributor adds products — that is the idea. It is not a performance metric and says nothing about sales; it only says that the agent reads the real catalogue.
Questions
Because it has nowhere to get it from. The price comes from your shop’s response at the moment of the question, kept in temporary memory for at most ten minutes. We do not have a copy of the catalogue from which it could read. You can check it yourself: ask the agent about a product, change the price in the shop, wait ten minutes, and ask again.
What the shop says. Availability comes from the same response as the price. What it does not do — and this is a decision, not an oversight — is invent a restock date. If you want the agent to suggest alternatives when a product is missing, that is a rule we write explicitly in its role and test, not something that happens by itself.
Not by reading the catalogue. Store API public is a read-only gateway; writing an order requires an authenticated route to the shop, so it is a separate piece of work, with keys that are managed. What it does today: takes the customer to the correct product, with the correct price, and gives them the link or hands the conversation to a person.
On WhatsApp, no, outside the 24-hour window. Meta rejects free text with error 131047, and template messages do not exist in the platform code. On Telegram and Messenger, within each channel’s rules, there are scheduled automations that resume conversations left without a reply, with visible counters for how many were sent and how many were skipped.
No. Meta does not have generic templates on Instagram, so the carousel does not exist there for anyone. On Messenger it does, but it requires three conditions at once; when one is missing, the reply remains text. We prefer you to hear that now, not in the third week of implementation.
The first stage changes: instead of connecting the address, we check what public interface your platform has and whether it responds quickly enough for a conversation. If it has none, either we write an authenticated connector — and then we discuss who manages the key — or we say that a live catalogue cannot be done honestly and stay with a periodically updated knowledge base, marked as such.
The photo is marked in the conversation and stays there for the person who takes over. It is not automatically attached to an order and no document is generated from it — there is no code for that. An agent who claimed to have logged the order from the photo would be lying, and that would be found out at delivery.
They get a single reply, to everything they wrote. Messages are collected in a 15-second buffer before being sent to the model. Separately, if the Meta platform resends the same message — and it does — deduplication on the message ID, with 120 seconds of memory, prevents the second reply.
A person from your team, and the handover is visible in the system: the thread moves from the `bot` state to `human`, the handover log records who and when, and the response-time compliance state shows whether the thread was left hanging. Without this mechanism, “hand over to an operator” is a promise no one can check months later.
Tell us about your process. Together we decide what is worth building, what we can connect, and how we check the result.