AI Chatbot WooCommerce Integration: Answers From Your Live Catalog and Orders

Five shopper questions and the WooCommerce data behind each one

Nearly every conversation on an online store falls into a few patterns. Designing the integration starts by mapping each pattern to the exact data it needs, because that decides which endpoints, permissions and caches come into play.

The first two answers must be live. The last can come from a search index of product content, provided anything factual in the recommendation, price and availability above all, is re-read from the store before the bot says it.

Consumer keys, permission scopes and the Store API

WooCommerce gives outside systems two separate doors, and choosing the right one for each job is most of the security design.

The authenticated REST API

The API under /wp-json/wc/v3/ covers products, variations, orders, customers, coupons and refunds. Access uses a consumer key and secret generated in WooCommerce’s advanced settings, tied to a WordPress user, with Read, Write or Read/Write permission. Over HTTPS the pair travels as basic authentication. We create a dedicated key for the bot’s backend, linked to a dedicated user, and start with Read. Write permission is added only for a named job, such as adding an order note when a customer asks about a return, and the backend exposes that one action to the bot instead of handing the model a general-purpose API.

The Store API

The Store API under /wp-json/wc/store/v1/ is the public API that the block-based cart and checkout use. It works inside the shopper’s own session, so it is how a chat widget running in the browser can put a chosen variation into that shopper’s real cart. Cart-changing requests need the nonce WooCommerce issues for the session. It cannot list orders or browse customer records, which is precisely why it is safe to call from the front end.

The rule that follows: consumer keys stay on the server, and the browser only ever touches the Store API. A write-scoped key sitting in front-end JavaScript would let anyone with developer tools open edit your orders.

Syncing the catalog: webhooks, cron and High-Performance Order Storage

Product descriptions, specifications and categories go into a search index so the bot can find relevant items for open-ended questions. Keeping that index current relies on WooCommerce webhooks: topics for product created, updated and deleted post a JSON payload to our endpoint whenever a product changes. Each delivery carries an X-WC-Webhook-Signature header, a base64 HMAC-SHA256 of the body computed with the webhook’s secret, which our receiver checks before trusting anything in it.

Three details trip up most setups:

• Webhooks run on a queue. WooCommerce delivers them through Action Scheduler, which by default runs on WP-Cron. On a site where WP-Cron fires only when someone visits, or was switched off without a real server cron replacing it, product updates arrive late or in clumps. We inspect the scheduled actions list during setup and recommend a proper server cron when it is missing.
• Repeated failures disable a webhook. After a run of failed deliveries WooCommerce marks the webhook disabled, and nothing warns the index that it stopped updating. A nightly reconciliation job pages through products by modification date and repairs anything the webhooks missed.
• Orders may not live where old code looks. Newer stores use High-Performance Order Storage, which keeps orders in dedicated tables instead of the posts table. Custom scripts that query posts for orders silently come back empty. We read orders only through the REST API or WooCommerce’s own order functions, which work under either storage mode.

Prices and stock are deliberately never trusted from the index. When the bot is about to state either, it fetches that product or variation live. The REST API returns at most 100 items per page, so a full resync of a large catalog is paced across many requests and scheduled outside your busy hours.

Order status without handing out anyone else’s order

Where-is-my-order is the most requested feature and the easiest one to get dangerously wrong. Order numbers are usually sequential; a bot that answers for any number it is given would let a stranger walk through your customer list by counting upward.

How we gate it:

1. Logged-in customers are recognized from their WordPress session. The widget passes a short-lived signed token for the current user to our backend, which lists only that customer’s orders.
2. Guests supply the order number and the billing email, the same pair WooCommerce’s own order-tracking form asks for. Both must match before anything is shown, and repeated mismatches from one session trigger a cooldown.
3. Minimal disclosure. The bot reports status, items, shipping method, and tracking number and carrier when your tracking extension stores them. Shipping address, phone and card details are never repeated back, verified shopper or not, and requests to change them go to a person.

Tracking deserves its own warning: WooCommerce core does not store tracking numbers. They come from whichever shipping or tracking extension you run, usually as order meta, and each one stores them differently. We find where yours writes them during scoping and map that exact field.

Order statuses also need translating. In WooCommerce, Processing means paid and waiting to be fulfilled, which confuses shoppers who read it as already shipping. The bot maps every status, including custom statuses your store has added, to a plain sentence you approve.

Helping someone buy, and exactly where the bot stops

Adding to cart from chat earns its keep on products with variations that are awkward to pick on the page. The widget calls the Store API in the shopper’s session to add the chosen variation, then shows the updated cart. For simple products a plain add-to-cart link can be enough. Either way, the shopper completes checkout; the bot never touches payment details and never places an order.

Coupons are a business decision before they are a technical one. The options we build, from most to least conservative:

• The bot mentions only coupons you already publish on the site.
• The bot can offer one pre-created code in a defined situation, such as a first-order code for a hesitant new shopper.
• The backend creates single-use codes restricted to the shopper’s email, with an expiry date, when a rule you set is met. The model can ask for one; server code decides whether it is issued.

Refunds, cancellations and address changes stay with staff. The bot records the request as a private order note or a ticket, tells the customer a person will follow up, and stops there.

Extensions that change what a correct answer looks like

Few stores run plain WooCommerce. Each of the following changes the integration, so we inventory them before quoting:

Tax and shipping totals are the other trap. They depend on the address, the cart contents and your zone rules, so the bot does not calculate them. It explains how shipping works for your zones and lets the cart produce the real figure.

Page caching, nonces and a checkout that stays fast

Stores lean heavily on caching, and chat integrations collide with it in predictable ways. A full-page cache can serve a product page whose embedded nonce belongs to an earlier visit; the widget’s cart calls then fail for some shoppers and work for others, which is maddening to debug. We fetch a fresh nonce when the chat opens instead of relying on one baked into cached HTML, and exclude the bot’s own endpoints from page and CDN caching.

The widget itself loads after the page becomes interactive and stays off the checkout page unless you want it there, because checkout is where a stray script costs the most. We measure product and cart pages before and after installation so any change in load time is visible to you rather than assumed.

How EVOTECH rolls it out, starting on a staging copy

1. Start with a free consultation by phone or video to hear what your support inbox gets asked and which extensions run the store.
2. Audit the store: WooCommerce and extension versions, order storage mode, cron health, caching layers, and where tracking data lives.
3. Put the scope in writing. The quote is fixed-scope and lists the questions the bot will handle, the write actions it may take, and what stays with staff.
4. Build on staging: a copy of the store with test orders in every status, a payment gateway in test mode, and your real extension set. Order lookups are attacked with wrong emails, other customers’ order numbers and guessed numbers before launch.
5. Launch and review. We read transcripts with you after go-live, and gaps in product content, which show up quickly, are fixed in the catalog itself.

That last point often matters most: questions the bot cannot answer are usually questions your product pages never answered either. If the storefront needs work on that side, our web design team can help. Stores weighing a platform move can compare this with our Shopify chatbot integration, and the content side of the same site, blog posts and service pages, is covered under AI chatbot WordPress integration.

Related services

Frequently asked questions