WhatsApp Catalog API: Build the Workflow After the Product Tap

The WhatsApp Catalog API can put a product in a conversation, but it does not by itself create a reliable order operation. The useful design question starts after the product tap: which identifier follows the customer, who owns the enquiry, when is stock checked, what turns an incoming order into a fulfillment task, and how does the team recover when reality differs from the catalog?

This guide answers that operational question. It uses Meta's current catalog-message and webhook objects as the technical boundary, then turns them into a practical workflow a commerce team can test. The central rule is simple: treat the catalog as a product-discovery surface and each webhook as evidence of customer intent—not as proof that stock is reserved, payment is complete, or fulfillment has begun.

What the WhatsApp Catalog API actually provides

Meta's official collection documents two useful interactive message shapes. A single-product message uses type: interactive, an interactive subtype of product, a catalog_id, and a product_retailer_id. A multi-product message uses the product_list subtype, one catalog_id, and sections containing product items identified by product_retailer_id (single-product request, multi-product request).

Meta also documents catalog templates with a CATALOG button. These are templates that open the business catalog in WhatsApp; they are not a replacement for product, inventory, order-management, or payment systems (catalog template request). Choose among these message types according to the customer's task, not according to which format looks most impressive.

The inbound side is equally important. A product enquiry can arrive when a person replies to a product message or uses “Message Business” from a product detail page. Its webhook context can include referred_product.catalog_id and referred_product.product_retailer_id (product-enquiry webhook). An order object can include catalog_id, product_items, quantity, item price, currency, and each item's product_retailer_id (messages object reference). Those fields identify what the customer selected. Your systems must still decide what can be promised and what happens next.

Build one catalog-to-order operating contract

A dependable workflow begins with one written contract across marketing, customer service, commerce operations, and engineering. It should define the meaning and owner of five records:

• Customer — wa_id, phone, or internal contact_uuid: Keep identity and conversation history connected
• Catalog — catalog_id: Identify the product source used in the message
• Product — product_retailer_id: Map the WhatsApp item to the merchant's stable SKU
• Interaction — outbound message ID and inbound webhook ID: Reconstruct the sequence and deduplicate events
• Work item — enquiry or order ID plus state and owner: Move intent through validation, recovery, and completion

Do not overload one status with several meanings. “Order received” should not also mean “paid,” “reserved,” or “dispatched.” A useful minimum state model is received → validating → reserved → confirmed → fulfilled, with explicit exits such as needs_customer, out_of_stock, cancelled, and failed. If another commerce system owns payment or fulfillment, store its reference beside the messaging record rather than pretending WhatsApp is the system of record.

Use a seven-stage workflow after the product tap

1. Check eligibility before sending. Confirm that the contact can receive the intended message, the product is active, the retailer ID resolves to one current SKU, and the chosen message type fits the task. A single-product message is usually clearer when the conversation already identifies an item. A multi-product message helps when a small, relevant set must be compared. A catalog template fits re-engagement or discovery only when the template and recipient are eligible.

2. Record what was sent. Store the customer, catalog_id, every product_retailer_id, the message ID, language, price snapshot if relevant, and campaign or workflow source. This is the audit trail for later questions such as “Which price did the customer see?” and “Why was this item offered?”

3. Classify the response without losing context. A product enquiry should enter a queue with the referred catalog and product already attached. Free-text replies still need the parent-message context when available. Never make the agent ask the customer to identify a product your webhook already identified.

4. Validate before promising. Resolve the retailer ID against the current product system. Check sellability, price, currency, stock or capacity, delivery or pickup rules, and any variant the message did not capture. This is where a stale catalog becomes a controlled exception instead of a broken promise.

5. Reserve and confirm deliberately. If the business reserves stock, create that reservation in the system that owns inventory and give it an expiry. Only then tell the customer what is held, for how long, and what action completes the purchase. If reservation is impossible, state that clearly and avoid language that implies certainty.

6. Treat an order webhook as a request for processing. Validate each item, quantity, currency, and current total; deduplicate the webhook; then create or update the order in the commerce system. Return mismatches to a human-owned exception queue. An order payload is not, by itself, evidence of payment settlement or physical fulfillment.

7. Close the loop. Write the final outcome back to the conversation timeline: confirmed, substituted, cancelled, collected, dispatched, or failed. Notify the customer through an eligible message path, retain the responsible owner, and record why any substitution or cancellation occurred.

A realistic example: garden-centre pickup

Suppose a customer asks about a two-litre rosemary plant. The team sends one single-product message whose product_retailer_id maps to herb-rosemary-2l. When the customer replies, the enquiry webhook identifies the same product. The workflow attaches the conversation to the correct contact and routes it to the pickup queue.

Before anyone promises collection, the inventory service checks the exact SKU at the requested branch. If it is available, the system creates a 90-minute reservation and the agent confirms the branch, quantity, price, and expiry. If the customer submits a catalog cart, the order handler verifies the item again, deduplicates the webhook, and opens a pickup work item. Collection is complete only when the store's operational system records the handoff.

If the catalog is stale and the two-litre plant is unavailable, the workflow does not silently swap in a smaller pot. It flags out_of_stock, suggests a specific alternative only after checking it, and leaves the original choice visible in the conversation. The value of this design is not more automation. It is a clean, recoverable promise.

Choose the message type by decision cost

Use a single-product message when the customer has already named a product, an agent is following up on a precise enquiry, or one recommended item needs a clear next action. It minimizes comparison effort and makes the referred-product context easier to interpret.

Use a multi-product message when the customer must compare a small set that shares a meaningful constraint: compatible spare parts, three sizes in stock, or a short collection for a known budget. Avoid turning every catalog section into a storefront dump. More options increase the chance that price, stock, and ownership change before the team responds.

Use a catalog template when a policy-compliant template is the right way to reopen discovery. The handoff after the tap still needs the same identifier mapping, eligibility check, owner, inventory validation, and exception path. The template changes the entry point, not the operating contract.

Design failure controls before launch

The highest-risk failure is an unstable product_retailer_id. Treat it as a durable integration key, not a display label. If a merchant changes internal SKUs, use an explicit mapping or migration; do not reuse an old identifier for a different product.

Next, make webhook handling idempotent. Store the event or message identifier and make repeated delivery safe. Place unresolvable products, invalid quantities, currency mismatches, missing contacts, and downstream timeouts into named exception states. Each state needs a queue, an owner, a response target, and a permitted customer message.

Also design for conversation-window boundaries. DripTell's current developer page notes that product sends can return a 422 response when the 24-hour customer-service window is closed (DripTell developer API). A production workflow therefore needs an eligible template route or a human decision instead of blind retries.

Finally, separate transport success from business success. A delivered message can lead to no enquiry. An order event can fail inventory validation. A confirmed order can still miss pickup. Dashboards and alerts should preserve those distinctions.

Measure the path, not just message volume

Useful measures follow the customer's state transition: product-message-to-enquiry rate, time to a named owner, percentage of enquiries with a resolvable retailer ID, inventory-validation success, reservation success and expiry, order exceptions by reason, time from order receipt to confirmation, and completed pickup or fulfillment rate. Segment by message type, catalog, product family, language, and workflow source.

Do not set an arbitrary benchmark before observing a clean baseline. First prove that events are complete and deduplicated. Then examine where qualified intent is lost. A lower enquiry rate may be acceptable if a precise single-product message produces fewer but better-matched requests. A high order count is not healthy if substitutions, cancellations, or uncollected reservations rise with it.

Map the workflow to DripTell

DripTell's published WhatsApp capability includes commerce catalogs, product messages, a shared inbox, routing, customer context, notes, and follow-up workflows (WhatsApp channel). Its API documentation shows /api/v1/send/product for single- and multi-product sends using catalog_id, product_retailer_id or products, and either phone or contact_uuid; it also documents catalog-cart orders in WhatsApp commerce history (developer API).

That makes a practical implementation path: keep the stable product key in the source commerce system, send the appropriate catalog message, retain message context on the contact, route the reply into the shared inbox, and use automation only for steps whose inputs and failure states are explicit. A person should own ambiguous product matches, stock conflicts, price changes, substitutions, and fulfillment exceptions.

Launch with a ten-case proof set

Before exposing the workflow broadly, test at least these cases: one valid single product; a valid multi-product section; a product enquiry; a cart with two quantities; a duplicate webhook; an unknown retailer ID; stale price or currency; out-of-stock after selection; a closed customer-service window; and a downstream order-system timeout. For every case, confirm the customer message, stored identifiers, owner, state transition, retry behavior, and final evidence of completion.

The launch decision should be based on whether the team can explain and recover every case—not whether the happy path looks polished. If you want to test one real catalog journey against DripTell's messaging, inbox, and automation boundaries, book a workflow demo with the SKU map, exception owners, and fulfillment system in view.