An AI bot that knows your inventory needs a live lookup against your store, not an indexed copy of a product page. Stock is the most perishable fact you publish: a passage indexed at three in the morning states the stock level at three in the morning, and by the time somebody asks it may be wrong in the direction that costs you an order. This is the one place where the usual retrieval architecture, which is excellent for policies and specifications, is the wrong tool.
The connection itself is ordinary. Deciding what the bot is allowed to say about the number is the part worth thinking about.
What does knowing your inventory actually mean?
Four levels, and products use the same phrase for all of them. Work out which one you need before comparing anything, because the gap between level two and level three is most of the implementation cost.
| Level | What it can honestly say | What it needs |
|---|---|---|
| Nothing | What the product page says about availability | Only the page index |
| Cached | The figure as of the last sync | A scheduled pull from your store |
| Live lookup | The figure right now, for this variant | An API call at question time |
| Live plus hold | The figure, and it is yours for ten minutes | Checkout-level reservation logic |
Most shops need level three and are sold level two, because level two is much easier to build and looks identical in a demo. The difference only shows on a busy day, which is also the day it matters.
Level four is rarer than the marketing suggests and is usually a checkout feature rather than a chat one. A bot that implies a hold it cannot place has made a promise on your behalf.
How fresh does the number need to be?
As fresh as your stock moves, which is a question about your shop rather than about the technology.
| If your stock moves | A cached number is | What to do |
|---|---|---|
| A few units a week | Fine, even at daily sync | Cache, and keep it simple |
| Dozens a day | Misleading by lunchtime | Live lookup at question time |
| Last units, single pieces | Actively dangerous | Live lookup and careful wording |
The third row covers more shops than they realise. Anything selling one-off items, vintage, handmade, ex-display, has a permanent last-unit problem, and a stale yes on the only one in existence produces a cancelled order and an apology.
The useful test is one question: could a number from an hour ago already be wrong? If yes, cache is the wrong architecture regardless of how much easier it is. If no, do not build the live path; you are adding a failure mode to solve a problem you do not have.
Where does the number come from?
Your store’s own API, with your code in the middle, the same pattern as any other action a bot takes.
You expose one narrow operation, check stock for this variant, and describe it to the model using function calling. When a question needs a stock figure the model requests that operation by name, your code runs it, and the result comes back into the answer. The model never touches your store directly.
The underlying APIs are well documented and this is not novel work. WooCommerce exposes products and variations with their stock quantities; Shopify exposes inventory levels per location; and on WordPress generally the REST API covers everything around them. The free WordPress plugin ecosystem, measured against the plugin API, contains several products that will do the plumbing for you, and the question to ask each of them is which of the four levels above it implements.
Two implementation details are worth insisting on. Cache the lookup for a few seconds so a burst of questions about the same product does not hammer your store. And put a timeout on it, with a defined answer for what the bot says when the lookup fails, because your store will occasionally be slow and the alternative is a visitor watching a cursor.
What breaks with variants and multiple locations?
Precision, in both cases, and quietly enough that nobody notices for months.
Variants. A customer asks whether you have the blue one in medium. A bot that resolves only to the parent product answers about the product, which may have plenty of stock in other colours and sizes. The answer is confidently wrong and structurally invisible: the lookup succeeded, the number was real, and it described something the customer did not ask about. The fix is that the lookup must resolve to the specific combination, and the answer should name the combination it checked so the customer can catch a mismatch.
Locations. With more than one warehouse there is stock somewhere and stock available to this customer, and a total across locations is technically accurate and practically useless. Somebody asking whether an item can reach them this week is not asking about the sum. Decide which number the bot quotes, and if it is a total, say so.
Reserved and committed stock is the third trap. Many systems distinguish physical stock from what is already allocated to unfulfilled orders. Quoting the physical number overstates availability every time, and the gap is largest on exactly the popular items where it does most damage.
How do you test it before customers do?
With a list of deliberately awkward products, because the easy ones pass in every implementation and tell you nothing.
Pick six and check each by hand against your admin while the bot answers. One product with plenty of stock, which should be trivially right. One with exactly one unit left, which is where wording matters. One that is out of stock entirely. One with variants, where you ask about a specific colour and size combination. One that is made to order or has a lead time rather than a count. And one you have deliberately archived or unlisted, because a bot quoting stock for something a customer cannot buy is a particularly annoying kind of wrong.
Score two things on each. Is the number right, checked against your admin at the same moment rather than from memory. And is the wording honest about what the number is.
Then repeat the exercise after any change to your stock setup: a new warehouse, a returns process change, a migration. Inventory integrations do not break loudly. They drift, usually into overstating availability, and the only thing that catches drift is somebody checking a handful of products against the source of truth on a schedule nobody enjoys.
How should it phrase a stock answer?
As a reading taken now, never as a promise, and the wording does real work here.
“There are two left right now” is true, checkable and does not imply a hold. “This is available” implies something your shop is not enforcing, and a customer who reads it as a reservation and finds the item gone at checkout has been misled by a sentence nobody meant as a lie.
Three phrasings are worth standardising before launch. What it says when stock is healthy, which can be simple. What it says at low stock, which should carry the timestamp implicitly with words like “right now”. And what it says at zero, which is the one worth writing carefully, because an out-of-stock answer is an opportunity: when it is expected back, a notify option, or the nearest alternative you do have.
Also decide what it says when the lookup fails. “I cannot check stock at the moment, here is how to reach us” is a good answer. Falling back silently to the indexed page figure is a bad one, because it presents stale data with the confidence of live data and nobody can tell the difference afterwards.
When should it not quote a number at all?
Three cases, and the first two are common.
When your stock data is unreliable, do not publish it through a bot. A shop whose counts drift because returns are not processed promptly, or because a physical shop shares the same stock, will produce confident answers from wrong data, and a chatbot amplifies that because it is asked more often than the page is read. Fix the counts first.
When the customer’s real question is delivery, answer that instead. “Is it in stock” is usually shorthand for “can I have it by Friday”, and a bot that answers the literal question while ignoring the intended one has been unhelpful precisely. If you can reach stock you can usually reach dispatch timing too, and that is the answer they wanted.
And for made-to-order or lead-time products, a stock number is meaningless and quoting one is confusing. A lead time is the honest equivalent, and it comes from a page rather than an API, which makes it the easier problem. The same applies to anything sold as a service or a booking, where the useful answer is the next available slot rather than a count, and a bot that reports zero in stock for a service has answered a question nobody asked.
For the general pattern of connecting a model to a website, see what an AI chatbot for a website actually is; for what the interface around all of this should do, see making a widget that fits your site. What our own version can reach is on works with, with the detail in the docs.
What people ask next
How does an AI bot know my inventory?
Through a live lookup against your store at the moment somebody asks, not through the page index. Stock is the most perishable fact on your site, so a passage indexed last night carries a number that may already be wrong. The bot has to be able to call your shop, receive the current figure for the specific variant, and say it as a reading taken now.
Can a chatbot read stock from my product pages?
It can read whatever the page said when it was last indexed, which is exactly the problem. A page indexed at three in the morning states the stock level at three in the morning. For a shop selling a few units a week that is close enough; for anything moving faster it produces confident wrongness about the one fact that decides whether somebody buys.
How fresh does a stock number have to be?
It depends on how fast yours moves, and the honest test is whether a number from an hour ago could already be wrong. A few units a week means an hourly cache is fine. Dozens a day means anything cached is misleading by lunchtime. Last-unit items need a live lookup and careful wording, because that is where a stale number turns into a cancelled order.
What happens with product variants?
This is where most implementations quietly break. A customer asks whether you have the blue one in medium, and a bot that only knows the parent product answers about the product rather than the variant. The lookup has to resolve to the specific combination the customer described, and it has to say which combination it checked, because a right answer about the wrong variant reads as a lie.
Can the bot reserve stock for a customer?
Almost never, and it should not imply that it has. Availability at the moment of asking is a reading, not a hold: somebody else can buy the last one while your customer is still typing. Reservations are a checkout mechanism rather than a chat one, and a bot that says an item is available when it means there is one left right now has made a promise your shop cannot keep.
Does this work with multiple warehouses?
Only if you decide what the customer is being told. With several locations there is stock somewhere and stock available to them, and those are different numbers. The bot has to know which one it is quoting and, ideally, say so. A total across warehouses is technically accurate and practically useless to somebody asking whether it can reach them this week.
