WhatsApp Product Catalog Messages: Sharing Products in Chat

The first catalog integration I built took two days of coding and three weeks of waiting. The code worked on day two. What took the rest of the time was getting the catalog itself into a state worth showing: product names that matched what customers call them, images that were not screenshots, prices that were actually current, and stock numbers that updated before a customer added a sold-out item to a cart.

That ratio is the honest shape of this work. The messaging is easy. The catalog is the project.

Three message types, three different jobs

WhatsApp does not have "a product message". It has three, and picking the wrong one is why a lot of teams conclude catalog messaging does not work.

A multi-product message holds at most 30 products across up to 10 sections, with a required header and a body capped at 1024 characters. That is not a limitation to work around, it is a signal about the intended use. Meta's own guidance in the share-products documentation says these messages work best when you guide a customer to a relevant subset rather than asking them to browse everything. Thirty well-chosen products beat three hundred uploaded ones.

Free-form now, template later

This is the part that decides your architecture, so get it straight before you write code.

Inside the customer service window, catalog, single-product and multi-product messages are interactive messages. Meta's documentation is explicit that these require no template and no pre-approval: they are generated in real time, which means the price and stock a customer sees are the ones in your catalog at that moment. That last sentence is the reason to use them. A static template that names a price is a price you have to remember to update.

Outside that window you need a template. Catalog templates exist (a button that opens the catalog) and so do multi-product templates, which carry a product selection and sit in the marketing category. Both go through review, and both cost marketing rates when sent. If you have not dealt with template rejection before, the causes are depressingly consistent and I have written them up in why WhatsApp templates get rejected. The step-by-step approval path is in the message template approval guide.

Practical consequence: design your flows so the expensive, review-dependent path is the exception. A customer who asked a question ten minutes ago should get a free-form product card, not a marketing template.

What the cart can and cannot do

Most of the disappointment I hear about WhatsApp commerce is a misunderstanding of the cart, so here is the behaviour from Meta's documentation, unvarnished.

• The cart belongs to a chat thread on a specific device. It does not follow the customer to WhatsApp Web or a second phone. The product messages themselves sync across linked devices; the cart does not.
• It has no expiry. It sits in the thread until the customer sends it, and then it clears.
• Up to 99 units of any single item. There is no cap on how many distinct items can be in one cart.
• No edits after sending. A customer who wants to change an order sends a new cart.
• You cannot send a cart to a customer. Carts only flow one way. If you want to propose an order, you send products and let them build it.
• Stock changes are handled for you. If an item sells out after it is in a cart, it is removed and the customer sees a notice that items were updated.

If your checkout flow assumes a server-side cart you can inspect, price, discount and abandon-email, this is not that. What arrives is a message containing what the customer selected, and the next steps are yours to design: confirm availability, quote delivery, take payment on your own checkout.

Where it actually earns money

Meta published a figure from its own testing: businesses saw an average 7% conversion of multi-product messages to carts received. Note what that number does and does not say. It is a platform-level observation from Meta's testing, not a BNex result, not a benchmark for your store, and not a promise. It says one thing usefully: a well-targeted product message produces carts at a rate worth measuring, which means you should measure yours before and after rather than arguing about it.

The variance behind that average is entirely in the targeting. A message pushing a random 30 items to a full list performs like a banner ad. The flows that work are narrow:

• Re-order. "The same as last time?" plus the last order's items. For wholesalers and food, this is the highest-value message you can send, and it needs no browsing at all.
• Back in stock, to people who asked about that specific item.
• A shortlist after a question. Customer asks which of three models suits a small office; the agent replies with a three-product message instead of three photos and a paragraph.
• Cart recovery. The cart cleared when they sent it and payment never completed — send the same items back with a note, inside the window if you can.

Nowhere in that list is "broadcast the catalog to everybody". That is how a number gets throttled, and quality limits do not negotiate. The tier structure and what actually triggers a downgrade are covered in how WhatsApp messaging limits actually work.

The catalog is where the work is

Interactive messages pull live from your catalog, which is both the feature and the trap. Every field you got sloppy about becomes visible in a customer's chat.

1. Upload inventory to Meta and connect the catalog to the WhatsApp Business Account. Both are prerequisites; a catalog sitting in a shop platform that was never connected to the WABA sends nothing.
2. Use the retailer ID as the join key. Meta calls it the Content ID in Commerce Manager, and product_retailer_id in the API. If your SKUs drift between your system and the catalog, product messages reference items that do not exist and the message silently renders incomplete.
3. Write product titles for a phone screen, not a spreadsheet. "SKU-4471-BLK-M" is a warehouse label. Nobody buys from it.
4. Keep price and stock current. Since interactive messages are generated in real time, an out-of-date feed is now a visible mistake rather than a stale web page nobody loaded.
5. Keep the catalogue small and honest. If a product is discontinued, remove it. A catalog full of dead items teaches customers to stop opening it.

Mistakes I see repeatedly

Sending the entire catalog when the customer asked about one thing. The catalog message is not a shortcut for thinking. Use it when browsing is the actual intent.

Treating the product message as a substitute for a person. It is an input to a conversation. The message that answers the price question should be followed by someone who can answer the delivery question.

Building the template path first. Teams spend a week on a multi-product template, get rejected twice on the button URL, and never ship the free-form flow that would have worked on day one.

Ignoring the delivery and read webhooks. A product message that fails to deliver looks identical to one that was ignored if you only read the send response. This is the same failure that makes order updates unreliable, and it is covered in WhatsApp API for ecommerce order updates.

Assuming the price in WhatsApp is the price at checkout. If your checkout recalculates tax and shipping, say so in the message body or the customer will feel tricked at the last step.

What to build first

If you are starting from nothing, do not build a storefront in a chat window. Build one flow that moves a real number: re-order for your existing customers, or a shortlist reply for whoever answers enquiries. Get the catalog clean for that subset of items only. Measure carts received. Then widen.

On the platform side, the cost question matters more than people expect, because a catalog message inside the window and a catalog template outside it are priced completely differently. The structure is in WhatsApp Cloud API pricing in 2026 and, if you want it in one place with the per-market detail, the pricing guide.

Where BNex fits

BNex is built around the inbox your team already answers from: conversations, contacts and campaigns in one place on your own verified number, so the product question and the product message land in front of the same agent. It does not replace the work above - your catalog still has to be clean and your catalog IDs still have to match - but it removes the seam where a message and its follow-up live in two different tools.

If you are planning a catalog or product-message flow and want a second opinion on which of the three message types fits your case, message me on WhatsApp at wa.me/917358722745 with what you sell and how customers currently order. I will tell you which one I would build first.

Related Reading