Handling WooCommerce Product Variations in Chatbots

Product variations are where many WooCommerce chatbots stop being useful. A customer may ask for a blue, medium shirt, but the chatbot must identify the parent product, resolve the exact attribute combination, verify availability, show the correct price, and add the correct variation to the cart. Treating a variable product as a simple product can result in incorrect pricing, unavailable items, or orders containing only the parent product without its selected attributes.

Understand the WooCommerce product model

WooCommerce stores a variable product as a parent product with one or more child variation records. The parent product usually contains the general description and available attribute definitions. Each variation has its own variation ID, attributes, SKU, price, stock status, dimensions, image, and other operational data.

For example, a T-shirt might have these attributes:

Color: blue, black, and white
Size: small, medium, large, and extra large

The combination of Color: blue and Size: medium maps to one specific variation ID. The chatbot should not infer that ID from the product name or from the order in which variations are returned. It should retrieve and store the actual attribute-to-variation mapping.

Use structured product data as the chatbot’s source of truth

For an authenticated integration, agencies can retrieve variations through the WooCommerce REST API, such as GET /wp-json/wc/v3/products/{product_id}/variations. The response includes the variation ID, attributes, pricing, stock fields, image data, and SKU. A chatbot integration should normalize this response into a compact structure that is easy for the conversation layer to use.

{
  "product_id": 482,
  "name": "Performance T-Shirt",
  "attributes": {
    "pa_color": ["blue", "black"],
    "pa_size": ["small", "medium", "large"]
  },
  "variations": [
    {
      "variation_id": 913,
      "attributes": {
        "attribute_pa_color": "blue",
        "attribute_pa_size": "medium"
      },
      "price": "29.00",
      "in_stock": true,
      "sku": "TS-BLU-M"
    }
  ]
}

Attribute keys matter. Global attributes generally use taxonomy-based names such as attribute_pa_color, while custom product attributes may use names such as attribute_size. The integration should preserve the keys returned by WooCommerce rather than converting every attribute to a display label.

Design a variation-selection conversation

The chatbot should collect only the attributes needed to identify a purchasable variation. A practical conversation flow is:

Identify the parent product from the customer’s request.
Load the product’s current variation data.
Ask for the first unresolved attribute, preferably using buttons or quick replies.
Filter the available variations after each selection.
Ask only for attributes that remain ambiguous.
Display the selected variation, price, stock status, and relevant image.
Request confirmation before adding it to the cart.

Suppose a customer says, “I want the blue shirt.” If blue exists in three sizes, the chatbot should respond with the available sizes rather than selecting a default. If the customer says, “medium,” the system can resolve the pair blue + medium and retrieve the matching variation ID.

When a selection produces no valid variation, the chatbot should explain the problem clearly. For example, “Blue is available in small and medium, but not large” is more useful than “That option is invalid.” This also prevents the conversational model from inventing a combination that does not exist.

Filter combinations instead of guessing

A reliable resolver represents each variation as a normalized set of attribute values. It then filters the set after each customer choice.

function findMatchingVariations(variations, selected) {
  return variations.filter(variation =>
    Object.entries(selected).every(([key, value]) =>
      variation.attributes[key] === value
    )
  );
}

const matches = findMatchingVariations(variations, {
  attribute_pa_color: 'blue',
  attribute_pa_size: 'medium'
});

The resolver should distinguish between three states:

No match: the selected combination is unavailable or invalid.
Multiple matches: another attribute must be collected.
One match: the variation can be presented for confirmation.

Do not rely on the language model alone to perform this matching. The model can interpret “navy” as a likely request for “blue,” but application code should validate the normalized value against WooCommerce data before selecting a variation.

Handle stock and pricing at the right time

Variation information can become stale between the initial product lookup and checkout. Store a variation ID in the conversation state, but revalidate the variation immediately before adding it to the cart or creating an order.

Check at least:

Whether the variation is published and purchasable.
Whether it is in stock and whether backorders are allowed.
The current price, including sale pricing.
Any required dimensions, downloads, or other product-specific fields.
Whether the requested quantity exceeds the available stock.

The chatbot should show the current price after the final variation is selected. A parent product’s displayed price may be a range, so it should not be presented as the confirmed price of a specific variation.

Add the selected variation to the cart correctly

The cart request must include the parent product context and the selected variation attributes in the format expected by the chosen WooCommerce integration. For a custom server-side endpoint, the application can validate the variation ID and attributes before calling WooCommerce. For a WooCommerce REST API order, a line item can reference both the parent product and the variation.

{
  "line_items": [
    {
      "product_id": 482,
      "variation_id": 913,
      "quantity": 1
    }
  ]
}

If the integration uses the Store API or a custom cart endpoint, follow that endpoint’s current request schema for variation attributes. Some implementations require attribute pairs such as attribute_pa_color=blue and attribute_pa_size=medium in addition to the product or variation identifier. Do not assume that a variation ID alone is sufficient for every cart implementation.

After the cart operation, read the resulting cart or order line item and confirm the selected attributes. This catches mapping errors before the customer reaches payment.

Keep conversational state separate from order state

Conversation state can contain a product ID, selected attributes, candidate variation IDs, and a timestamp. It should not be treated as proof that an item is still available. At checkout, WooCommerce remains the authority for price, stock, taxes, and cart contents.

A useful state object might look like this:

{
  "product_id": 482,
  "selected_attributes": {
    "attribute_pa_color": "blue",
    "attribute_pa_size": "medium"
  },
  "resolved_variation_id": 913,
  "resolved_at": "2025-01-15T14:30:00Z",
  "quantity": 1
}

Use a short cache lifetime for variation data, and invalidate cached data when products or inventory change. For larger stores, webhooks or scheduled synchronization can update a searchable catalog, while the final cart or order request still performs live validation.

Plan for edge cases

“Any color” requests: ask for a specific value when the customer is ready to purchase, unless the store has an explicit default-selection rule.
Attribute synonyms: map terms such as “navy” or “midnight blue” only when the store’s catalog defines that relationship.
Default attributes: treat WooCommerce defaults as suggestions, not confirmed customer choices.
One-of-a-kind combinations: explain when a previously available variation has gone out of stock.
Different variation images: update the product image when the selected variation provides one.
Quantity changes: recheck stock when the customer changes quantity in the conversation.
Localized labels: keep internal attribute keys stable while displaying translated names to customers.

Test the complete variation path

Agency QA should cover the entire path from natural-language selection to the final cart or order. Test valid combinations, unavailable combinations, missing attributes, sale prices, backorders, stock changes during the conversation, and products with custom attributes. Inspect the resulting WooCommerce cart or order to confirm the parent product, variation ID, attribute values, quantity, price, and SKU.

For analytics, record the product ID, resolved variation ID, selected attributes, and whether the selection succeeded. Avoid logging payment details or unnecessary personal data. Variation-level analytics can reveal which sizes, colors, or configurations customers request most often, even when those selections do not convert.

Table of contents :