Live Catalog Queries for Ecommerce Chatbots: Architecture Guide

When a shopper asks whether a product is available, the answer is only as reliable as the source and the moment it was read.

“Real-time inventory chatbot” is often used to describe several different architectures: an imported catalog refreshed on a schedule, a local copy updated by webhooks, or a request-time query to the commerce platform. These approaches have different latency, reliability, cost, and failure modes.

This guide explains those tradeoffs, how product data differs from RAG knowledge, and how to test vendor claims. For a broader introduction, start with our AI chatbot for ecommerce guide.

Why Catalog Freshness Matters#

A store catalog changes throughout the day:

• a variant sells out
• a merchant changes a price
• a product is archived
• a sale begins or ends
• an image or description changes
• a new option is published
• an inventory system adjusts available quantity

A chatbot working from yesterday's copy may show an unavailable item, quote an old price, or recommend a product that is no longer published. The answer can sound confident because language fluency and data freshness are separate concerns.

Fresh access also does not repair inaccurate upstream data. If Shopify, an ERP, or a warehouse system has the wrong quantity, a chatbot can retrieve the wrong quantity quickly. Checkout and the commerce platform remain the final authority for sellability.

“Real-Time” Is Not One Architecture#

Ask vendors what happens between a merchant changing a product and the chatbot seeing that change. Their answer normally fits one of the following patterns.

Architecture 1: Scheduled Batch Import#

The chatbot periodically copies product records into its own search or knowledge index.

How it works#

1. An integration exports products and variants.
2. The chatbot transforms and indexes those records.
3. Shopper searches run against the copied index.
4. A scheduled job repeats the process.

Advantages#

• predictable query performance
• search does not depend on the commerce API for every request
• imported data can be enriched or precomputed
• useful for platforms with restrictive query APIs

Risks#

• changes between imports are not represented
• failed jobs can leave the index stale
• large catalogs may take time to refresh
• deleted or unpublished records require careful cleanup
• “last updated” may describe the job start rather than successful completion

Batch imports can work well when the catalog changes slowly and the delay is acceptable. The key is transparency: merchants need the refresh interval, last successful import, failure alerts, and behavior while an import is incomplete.

Architecture 2: Webhook-Driven Local Index#

The commerce platform sends an event when a product, variant, or inventory record changes. The chatbot updates its local copy in response.

How it works#

1. The merchant makes a change.
2. The platform emits a webhook.
3. The receiving service validates and queues the event.
4. A worker updates or removes the local record.
5. Future searches use the revised index.

Advantages#

• changes can propagate faster than a periodic full import
• most shopper searches still use a fast local index
• only changed records may need processing
• full reimports can run less often

Risks#

• events may be delayed, duplicated, missed, or delivered out of order
• endpoint downtime can create gaps
• schema or permission changes can break processing
• inventory may be split across several event types
• reconciliation is still required

A robust webhook architecture needs idempotency, retries, dead-letter handling, observability, and periodic reconciliation against the commerce platform. “Webhook-based” does not automatically mean perfectly current.

Architecture 3: Request-Time Commerce Query#

The chatbot queries the commerce platform when the shopper asks a product question.

How it works#

1. The shopper asks for a product or constraint.
2. The assistant selects a product-search action.
3. The application validates the query.
4. The integration requests matching products from the commerce API.
5. Structured results are returned to the shopper.

Advantages#

• avoids waiting for a separate catalog-index refresh
• respects the commerce platform's current published state
• removes webhook reconciliation for the queried fields
• makes the commerce platform the explicit source of truth

Risks#

• shopper latency includes the upstream API call
• rate limits and API outages affect product search
• the platform's search syntax may limit semantic matching
• broad queries may require ranking rules
• upstream records can still be incomplete or wrong

Request-time queries reduce one category of staleness; they do not guarantee perfect inventory accuracy or zero latency. The application needs timeouts, safe failure copy, rate-limit handling, and monitoring.

Architecture Comparison#

Dimension	Scheduled batch	Webhook-driven index	Request-time query
Search source	Local copy	Local copy	Commerce platform response
Typical freshness	Bound by schedule	Bound by event delivery and processing	Bound by upstream state at request time
Query dependency	Local search service	Local search service	Commerce API
Main operational risk	Stale or failed import	Missed or out-of-order event	API latency, outage, or rate limit
Search flexibility	High after indexing	High after indexing	Depends on platform query capabilities
Reconciliation needed	Yes	Yes	Less for queried data, but upstream still needs governance
Best fit	Stable catalogs	Frequently changing catalogs with strong event infrastructure	Authoritative product checks and compact integrations

Hybrid designs are common. A local index may support semantic discovery, followed by a request-time availability check before presenting a product as purchasable. Another system may query current product data but cache low-risk fields briefly to reduce latency.

The correct architecture depends on how often data changes, the platform's APIs, acceptable delay, catalog scale, and how costly a wrong answer would be.

Product Data Is Not the Same as RAG Knowledge#

RAG retrieves relevant text and gives it to a language model for a grounded answer. It works well for relatively stable, explanatory content:

• shipping and return policies
• warranty terms
• size-guide methodology
• care instructions
• product manuals
• compatibility documentation

Commerce catalog data is structured and operational:

• product and variant identifiers
• publication status
• price
• options
• availability
• cart state
• fulfillment status

You can index product descriptions for semantic discovery, but a retrieved paragraph should not be the final authority for current price, stock, cart contents, or an order. Those facts should come from the responsible commerce system.

This distinction is an important evaluation criterion in our best ecommerce AI chatbot comparison.

How Denser Handles Shopify Product Requests#

Denser uses different sources for different jobs.

When a shopper asks what the store sells, requests a product, asks about availability, or wants a recommendation, the released Shopify integration queries Shopify at request time. The appserver returns structured product results, including product and variant information used by the storefront cards.

For questions about shipping, sizing, warranties, returns, or product documentation, Denser can retrieve relevant passages from merchant-connected websites and documents.

The division is deliberate:

Request	Denser source
Product search and available variants	Shopify query at request time
Current native cart	Shopify storefront cart
Eligible order status	Shopify order data after verification
Policy and documentation	Denser knowledge sources
Unsupported exception	Configured human-support action

Product cards are built from structured application data rather than asking the model to invent a price, product URL, or variant identifier. Cart commands are validated before they run against Shopify's same-origin Ajax Cart API.

Denser does not claim warehouse-bin visibility, multi-location routing, back-in-stock subscriptions, preorders, cancellations, exchanges, address changes, discounts, or return transactions in the current Shopify integration.

Merchants can review the full workflow on the Shopify AI chatbot solution page and in the Shopify setup documentation.

What Happens When the Live Query Fails?#

A commerce-aware chatbot needs a defined failure state. The model should not substitute an answer from memory or an old policy page when an authoritative product action fails.

A safe failure path:

1. does not present an unverified price or availability claim
2. tells the shopper that current product information could not be checked
3. offers the product page, retry, or support route where appropriate
4. records the action outcome without logging sensitive data
5. lets operators distinguish a zero-result search from a technical failure

This behavior is more trustworthy than a graceful-sounding guess.

Questions to Ask a Chatbot Vendor#

Use concrete questions instead of asking whether inventory is “real time.”

Source and freshness#

• Where does product search run?
• Is the catalog copied, event-updated, or queried at request time?
• Which fields are current and which are cached?
• How can I see the last successful refresh?
• How are unpublished and deleted products removed?

Variants and availability#

• Does search work at the product or variant level?
• Can it distinguish size, color, material, and location?
• What happens if a variant sells out after results are shown?
• Does the cart reject an unavailable item?

Reliability#

• What happens during an API outage?
• Are webhook failures retried and reconciled?
• How are rate limits handled?
• Can the chatbot differentiate no results from a failed request?

Safety#

• Can the model produce prices or URLs outside structured results?
• Which service validates a cart action?
• What permissions does the integration request?
• Are product queries or cart contents logged?

Measurement#

• Can I see zero-result searches?
• Are action latency and failures reported?
• Can I segment failures by store, product, and integration state?
• Can I test a new catalog configuration before exposing it to every shopper?

How to Test Catalog Freshness#

Run the following test in a development store or with a safe product:

1. Search for a known product and record the result.
2. Change a harmless field such as the title or availability in the commerce platform.
3. Wait only as long as the vendor documents.
4. Repeat the same query.
5. Test a specific variant and a broad category query.
6. Unpublish the product and verify that it disappears.
7. Restore it and confirm the result returns.
8. Disconnect or restrict the integration and observe the failure response.

Then test concurrency. Add the last available unit to one cart and ask from another session. The chatbot should not treat a prior search result as a reservation. The cart or checkout must remain authoritative.

Prepare for Peak Events#

Before a launch, promotion, or holiday:

• test featured products and every important variant
• verify temporary prices and promotional rules
• confirm sold-out behavior and alternatives
• inspect API limits and monitoring
• test the product-source failure state
• verify cart reconciliation
• check the human-support destination and staffing
• remove expired campaign knowledge afterward

Catalog architecture cannot compensate for poor merchandising data. Complete product attributes, consistent variant names, and accurate upstream inventory remain essential.

Frequently Asked Questions#

Does a request-time query guarantee inventory accuracy?#

No. It reduces delay from a copied catalog, but still depends on the commerce platform, connected inventory processes, and a successful API response. Cart and checkout remain authoritative.

Is a request-time query the same as RAG?#

No. A request-time commerce query retrieves structured operational data. RAG typically retrieves relevant text for a grounded language answer. A chatbot may use both in one conversation.

Are webhooks real time?#

They can propagate changes quickly, but delivery and processing are asynchronous. Delays, duplicates, missed events, and out-of-order events require retries and reconciliation.

Should every ecommerce chatbot use request-time queries?#

No. Batch or webhook-fed indexes may provide better semantic search, lower query latency, or support platforms with limited APIs. Some systems combine local discovery with a live availability check.

How does Denser search Shopify products?#

Denser queries Shopify when the shopper makes a product request. It returns structured product results and uses Shopify's storefront cart for supported cart actions.

Can Denser track Shopify orders?#

Yes, for eligible orders. Guest shoppers provide an order number and the email used at checkout; signed-in shoppers can access supported recent-order flows. Failed verification does not reveal order details.

The Bottom Line#

“Real-time inventory chatbot” is not a sufficient architecture description. Ask where the data lives, how it becomes searchable, what happens during failure, and which system validates the final purchase.

Scheduled imports, webhooks, and request-time queries can all be valid. The best choice is the one whose freshness, reliability, and operational costs match the store. What matters most is that the chatbot knows which source is authoritative—and declines to guess when that source is unavailable.