Most sellers who ask about WhatsApp catalog setup are picturing a shop. They imagine customers tapping into a storefront, browsing shelves, and arriving at checkout. That is not what a WhatsApp catalog is, and the gap between the mental model and the mechanism is where the disappointment comes from — a catalog gets built, nobody sees it, and the seller concludes WhatsApp does not work for selling.
A WhatsApp catalog is a structured inventory hosted by Meta. It has no address a customer can navigate to and no browse path of its own. It exists so that messages can reference it: a message that shows one product, a message that shows a list of them, a message that shows the catalog as a whole. The catalog is the noun; the product message is the verb. Sellers who understand that build a conversation flow that puts products in front of people. Sellers who do not build a catalog and wait.
This guide covers the whole path: what you upload and how it connects to your WhatsApp Business Account, the four product message formats and the limits Meta actually documents for each, how the cart behaves and where it stops behaving, the one API call that turns commerce on for your number, what a submitted order looks like on your side, and the policy review that runs quietly over every item you add. If you are still deciding between the free app and the platform, the WhatsApp Business app versus the API comparison is the right place to start, because several rules below apply to only one of them.
What You Are Actually Building
Meta supports two item categories in a catalog, and the distinction matters more than it looks. Products are physical or digital goods with attributes like price, SKU and images. Services are offerings such as appointments, consultations or subscriptions. A salon, a clinic and a tutor are all first-class catalog users, not awkward fits — which is worth knowing in markets where a large share of WhatsApp commerce is booking rather than shipping.
Each item carries a name, a description, a price, images and an availability state. Those five fields are the whole substance of what a customer sees inside a product message, so they are not administrative metadata to fill in quickly. The description is the only place a customer learns what a thing is before they add 99 of them to a cart, and the image is doing the entire job a product photograph does on a website, on a phone screen, inside a chat thread, next to your last text message.
The inventory itself is uploaded to Meta either through Meta Commerce Manager, which is the manual and spreadsheet route, or through the Commerce API for sellers with a system of record worth syncing from. Whichever route you take, the catalog then has to be connected to your WhatsApp Business Account. That connection is the step that turns a Meta catalog into a WhatsApp catalog, and it is the step most often missing when product messages fail with a catalog error.
The Four Ways to Put a Product Into a Conversation
Once a catalog is connected, Meta gives you four message formats. They are not interchangeable, and choosing the wrong one is the most common WhatsApp catalog setup mistake after skipping the connection step entirely.
| Format | What the customer sees | Documented limit | Best used for |
|---|---|---|---|
| Catalog message | A thumbnail of your full catalog | No product count limit — it points at the catalog, not at items | An opening move when you have no idea what the customer wants |
| Single product message | One product with its image, price and description | One item, referenced by its retailer ID | Answering “do you have this?” and closing a specific sale |
| Multi-product message | A curated list, grouped into sections | Up to 30 products across all sections | A shortlist after you have asked one qualifying question |
| Product carousel message | Horizontally scrollable product cards | Card count not stated in Meta’s overview documentation | Visual categories where side-by-side comparison helps |
The 30-product ceiling on multi-product messages is a ceiling for the entire message, not per section. Ten sections of five products each does not get you 50. In practice the number you should send is far lower: a customer is scrolling a list inside a chat, not scanning a grid on a laptop, and thirty options in that context is a way of asking someone to do your merchandising for you. Five to eight products chosen after one clarifying question convert better than the maximum, every time.
The structural rules the API enforces
Each format has header and body rules that will reject your payload if you get them wrong:
- The interactive
typeisproductfor a single product,product_listfor a multi-product message, andcatalog_messagefor the catalog thumbnail. - A header is required for
product_listand cannot be set at all forproduct. That asymmetry catches people who build one payload and parameterise the type. - The body is optional for
productand required for every other interactive type — so a multi-product message with no explanatory text is not a minimal message, it is an invalid one. - Products are referenced by
product_retailer_id, and the message as a whole references thecatalog_id. Multi-product messages carry asectionsarray. - Section titles are capped at 24 characters, and sections become required once a message has more than one of them. Twenty-four characters is short: “Ready to ship this week” already fills it.
If you have already built interactive buttons or lists, the mental model transfers directly — these are the same interactive message envelope with a commerce payload inside. Our guide to WhatsApp interactive messages covers the button and list variants, whose own limits (10 sections, 10 rows combined) are tighter than the product ones and are worth knowing before you pick a format.
Turning Commerce On: One Endpoint, Two Booleans
Here is the step that is genuinely easy to miss, because it lives in the API rather than in Commerce Manager where the rest of your WhatsApp catalog setup happened. Cart availability and catalog visibility are properties of your business phone number, and you read and write them at:
| Method | Endpoint | Purpose |
|---|---|---|
| GET | /{Version}/{Phone-Number-ID}/whatsapp_commerce_settings | Read current state |
| POST | /{Version}/{Phone-Number-ID}/whatsapp_commerce_settings | Change it |
Both live on https://graph.facebook.com and both need an Authorization: Bearer header. The two fields are is_cart_enabled and is_catalog_visible. A GET returns a data array containing an id and the two current boolean values; a POST returns a success boolean and nothing more.
Read the settings back, always
Two practical notes. First, Meta does not document default values for either field, which means you should GET before you assume rather than reasoning about what a new number probably starts with. Second, that thin success response is not confirmation of the state you wanted — it confirms the write was accepted. Read the settings back after every change. On a shared number where several people can administer commerce, the GET is the only source of truth about what your customers can currently do.
is_catalog_visible set to false is a legitimate configuration, not a broken one. A seller who wants to control exactly which products appear, in which conversations, may deliberately hide the browsable catalog and drive everything through single and multi-product messages. That is a merchandising decision, and it is a good one for a small seller with a long tail of items that are not worth showing.
How the Cart Actually Behaves
The cart is where WhatsApp commerce stops resembling e-commerce, and the differences are all documented rather than surprising — if you have read them.
| Behaviour | What Meta documents | What it means for you |
|---|---|---|
| Units per item | Up to 99 units of each single catalog item | Fine for retail; a real constraint for wholesale |
| Distinct items | No limit on the number of distinct items | Large mixed baskets are possible |
| Scope | Unique to a customer and business chat thread on a specific device | Phone and desktop are two separate carts |
| Expiry | No expiration date until it is sent | A cart can sit for weeks and still arrive |
| After sending | No edits can be made | Every change becomes a conversation, not a cart action |
A sent cart is frozen — and that is a feature
That last row is the one to design around. On a website, a customer who wants a different size edits their basket. On WhatsApp, a sent cart is frozen, so the customer types “actually make that the large” and a human has to reconcile it. This is not a flaw; it is the whole reason conversational commerce works for sellers whose orders need judgement. But it does mean the order lands in a queue that has to be staffed, which is why sellers running any volume put orders into a shared team inbox rather than a personal handset.
The device-scoped cart deserves a mention in your own copy. A customer who starts a cart on their phone and finishes on a laptop has not lost their order to a bug — they are looking at a different cart. Saying so in the thread costs a sentence and saves a support ticket.
What Happens When an Order Arrives
When a customer sends their cart, the order reaches you as an inbound webhook event rather than as a text message. Practically, the payload identifies the catalog it came from and carries the line items, each keyed by the same product_retailer_id you used to build the message, with quantities and prices attached; multi-product interactions surface a product item object in the webhook. Meta’s exact field names for order payloads have moved with the documentation reorganisation this year, so wire this against the current reference rather than against a tutorial — including any blog post, this one included.
The design point matters more than the field names. An order is an event in a conversation, not a row in an order table. Nothing about receiving it creates a record, charges a card, reserves stock or notifies anyone. Whatever your system does next — write to a spreadsheet, raise an invoice, ping a fulfilment channel — is entirely yours to build. Sellers who assume WhatsApp is handling the order because the cart arrived neatly formatted are the ones who lose orders during a busy week.
Two consequences follow. First, confirm every order in the thread, explicitly, with the total and the fulfilment expectation, because the customer has no order-status page to check. Second, keep the confirmation on the same conversation record as the browsing that preceded it, so the person handling a dispute later can see what was actually shown. If your volume is spiky, automating around seasonal spikes is worth doing before a sale weekend rather than during one.
The Cloud API Gap That Catches Migrating Sellers
This one is documented, counterintuitive, and reported as a bug several times a week somewhere in the world: Cloud API messages do not display a shopping cart icon in the chat thread header. The free WhatsApp Business app does. So a seller who validated demand on the app, watched customers tap the cart icon happily for months, and then migrated to the platform can find that behaviour simply gone.
The consequence is strategic, not cosmetic. On the app, the interface does your discovery for you. On the Cloud API, your messages are the only entry point into your catalog. If a conversation never contains a catalog message, a product message or a product list, that customer may have no route to your products at all.
So a Cloud API seller has to build discovery deliberately: a catalog message in the greeting flow, a product message as the answer to any question about a specific item, a multi-product message after any qualifying question. This is more work than the app, and it is also better selling — a curated shortlist chosen in response to a stated need outperforms a passive icon. But it has to be designed, and the design is the thing sellers forget to port when they migrate. If you are weighing that migration, the app-versus-API decision guide lays out what else changes at the same time.
Catalog Review and the Commerce Policy
Every item added to a catalog connected to a WhatsApp Business Account is automatically reviewed. Policy-violating items are flagged and the business is directed to the WhatsApp Commerce Policies. Customers can also report products, which sends them for review. Disapproved items can be appealed in Meta Commerce Manager.
The restricted list is wider than most sellers expect
The restricted categories run wider than most sellers expect. Firearms, alcohol and tobacco, drugs, medical and healthcare products, endangered species, live animals other than livestock, hazardous goods and materials, real or virtual currency, body parts and fluids, fraudulent or deceptive goods, real money gambling and gaming, adult products and services, dating services, multi-level marketing, and payday loans and related financial products are all restricted. Meta states plainly that a business selling prohibited goods or services through catalogs may be prohibited from using some or all of the WhatsApp Business Services.
Read “medical and healthcare products” carefully if you sell supplements, devices, or anything wellness-adjacent — that category catches far more small sellers than firearms ever will. And note the escalation path: this is not a per-item content warning, it is a policy that can reach your access to the platform. A catalog full of borderline items is a slow-building risk to the number your whole business runs on, which is the same machinery behind WhatsApp Business account restrictions generally.
Sellers based in India have an additional obligation: they must comply with online selling laws, and Meta exposes a Business Compliance API for surfacing the required seller details. If you sell into India from elsewhere, or operate an Indian entity, treat that as a checklist item during WhatsApp catalog setup rather than a later compliance clean-up.
Keeping the Catalog Honest About Stock
Catalog edits propagate to customers, and they do it silently. Meta documents that price, title, description and image changes update as soon as the customer’s client learns about the change. Availability is harsher: if a customer has already added a product to a cart and that item becomes unavailable, the item is removed from the cart.
Nobody is told. A customer who built a five-item cart on Tuesday and sends it on Friday may send four items at prices they never agreed to, with no message explaining either change. For a small seller that produces the two worst kinds of order conversation: the one where the customer is angry about a price they did not see, and the one where an item they wanted has vanished without explanation.
Three habits that prevent the two worst order conversations
Three habits fix most of it. Batch catalog edits outside your busy hours. Re-state the total and the line items in the thread before you treat an order as confirmed. And when you remove an item from availability, search your open threads for it rather than waiting for the carts to arrive short — a job that takes seconds in a shared inbox with search across every conversation, and is effectively impossible on a personal phone. Sellers running a genuine catalog operation usually reach this conclusion at the same time they outgrow one person answering one phone.
Opt-In Still Applies to Everything You Send
A catalog does not create permission. Product messages sent business-initiated are still messages, subject to the same template rules, the same 24-hour service window and the same consent expectations as any other outbound. Sending an unsolicited catalog to a list you scraped is the fastest route to the quality problems above.
Inside the service window, replying to a customer question with a product message is free-form and needs no template. Outside it, you are in template territory, with the review path that implies. That is not a small distinction for a seller planning a promotion, and it is worth reading the current opt-in rules and how template approval works before you build a campaign around your catalog rather than after Meta rejects one.
The pricing model is the other half of that plan. Product messages are priced as messages, and the conversation categories that decide cost have not changed because a catalog is attached — the 2026 pricing breakdown applies unchanged to anything you send with products inside it.
A Rollout Order That Works for a Small Seller
The sequence below front-loads the cheap steps and defers the expensive ones until demand is proven.
- Build the catalog in Commerce Manager with real photographs, honest descriptions and accurate availability. Start with your top 20 sellers, not your whole range.
- Connect the catalog to your WhatsApp Business Account. Confirm the connection before you write a line of integration code.
- If you are on the free app, sell that way for a few weeks. Watch whether customers order through chat at all before you build anything.
- Moving to the Cloud API? GET
whatsapp_commerce_settingsfirst, then POST your intendedis_cart_enabledandis_catalog_visiblevalues, then GET again to verify. - Add a catalog message to your greeting flow, so every new conversation has an entry point into your products.
- Write one qualifying question, then answer it with a multi-product message of five to eight items, not thirty.
- Handle the order webhook: log it, confirm it in the thread with the full total, and route it to whoever fulfils.
- Re-run the catalog against the restricted categories list before you scale. It is far cheaper to remove three items now than to appeal a flagged catalog later.
Steps 3 and 5 are the ones that get skipped. Skipping step 3 means building an integration for demand you have not yet proven. Skipping step 5 means your beautifully built catalog is invisible to every customer who does not think to ask.
When a Catalog Is the Wrong Tool
Catalogs suit sellers with a stable, photographable range at fixed prices. They suit service businesses selling defined appointments. They are a poor fit when every order is quoted individually, when your range changes faster than you can maintain it, or when your items are configured rather than chosen — in which case a well-built WhatsApp Flow collects a structured brief far better than a product list ever will.
A neglected catalog is worse than none. A customer who taps into a product message and finds last season’s prices has learned something about your business that no marketing recovers. If you cannot commit to maintaining it, sell in the thread with photographs and quote each order — that is a legitimate model, and the sellers doing it well in markets like the UAE are not less sophisticated for it.
The Short Version
WhatsApp catalog setup is two things people conflate: uploading inventory to Meta and connecting it to your WhatsApp Business Account, then designing the messages that reference it. The first is administration. The second is the actual work. Products and services are both first-class item types. Multi-product messages cap at 30 items across all sections with 24-character section titles, and you should send closer to six. Headers are required for product_list and forbidden for product; bodies are required everywhere except single product messages. Cart and catalog visibility are two booleans on whatsapp_commerce_settings with no documented defaults — read them before you trust them. Carts hold 99 units per item, are scoped to one device, never expire, and cannot be edited once sent. Catalog edits reach customers silently and unavailable items vanish from carts already built. Cloud API numbers get no cart icon in the chat header, so your messages are the discovery. And every item is reviewed against a restricted list that is wider than most sellers assume. None of that is hidden — but all of it is much cheaper to design around than to discover during your first busy week.