# AI bot that knows my inventory: what actually has to connect

> By Lawrence Dauchy, Founder, DFYe. Published 2026-08-10. 10 min read. Guides.
> Source: https://dfye.com/blog/ai-bot-that-knows-inventory/
> Language: en

A stock number is the most perishable fact on your site. A bot quoting a stale one does more damage than a bot that declines.

**TL;DR.** An AI bot that knows your inventory needs a live lookup against your store rather than an indexed page, because stock is the most perishable fact you publish. There are four levels: nothing, a cached number, a live lookup, and a live lookup with a reservation. Most shops need the third. Variants and multiple locations are where implementations quietly break, and a stock answer should be phrased as a reading taken now, never as a promise.

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](https://platform.openai.com/docs/guides/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](https://woocommerce.github.io/woocommerce-rest-api-docs/) exposes products
and variations with their stock quantities;
[Shopify](https://shopify.dev/docs/api/admin-rest) exposes inventory levels per location;
and on WordPress generally the [REST API](https://developer.wordpress.org/rest-api/)
covers everything around them. The free WordPress plugin ecosystem, measured against the
[plugin API](https://api.wordpress.org/plugins/info/1.2/), 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](/blog/ai-chatbot-website/); for what the
interface around all of this should do, see
[making a widget that fits your site](/blog/ai-widget-website/). What our own version
can reach is on [works with](/works-with/), with the detail in [the docs](/docs/).

## Quick answers

### 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.

## Sources

- [WooCommerce REST API documentation](https://woocommerce.github.io/woocommerce-rest-api-docs/)
- [Shopify: Admin REST API](https://shopify.dev/docs/api/admin-rest)
- [WordPress REST API handbook](https://developer.wordpress.org/rest-api/)
- [OpenAI: function calling](https://platform.openai.com/docs/guides/function-calling)
- [WordPress.org plugin API, the install figures](https://api.wordpress.org/plugins/info/1.2/)

---
*Published by [DFYe](https://dfye.com/). Free to read, index, quote and cite with attribution and a link.*