Product Feed

1. 1

   Export the right rows

   Generate the file from your store or ERP with Meta's columns, one row per purchasable variant, with your SKU in id. Leave out items you cannot sell instead of sending them with bad data.

2. 2

   Host it and schedule the fetch

   Publish the file at a stable HTTPS URL (password protection is supported), then add it as a data source in Commerce Manager or with POST /{CATALOG_ID}/product_feeds, choosing an hourly, daily or weekly schedule.

3. 3

   Choose replace or update

   A complete file should run as a replace, so products you drop disappear. A partial file — only prices, or only changed items — must run as an update or a supplementary feed, or everything missing from it can be removed.

4. 4

   Push urgent changes through the API

   Between runs, send stock-outs and price changes with the Catalog Batch API's items_batch endpoint, then check the returned handle with check_batch_request_status until it reports finished.

5. 5

   Read every upload's errors

   Each run records errors and warnings: missing required fields, prices that do not parse, images Meta cannot fetch, policy rejections. Review them in Commerce Manager or through the feed's uploads edge, and fix the source rather than patching items by hand.

File formats

CSV, TSV, XML (RSS or Atom), Google Sheets

Scheduled fetch

Hourly, daily or weekly from a URL

Required columns

id, title, description, availability, condition, price, link, image_link, brand

Price format

Number + ISO 4217 code, e.g. 1299.00 INR

id column

Becomes product_retailer_id; up to 100 characters

Between runs

Catalog Batch API: POST /{CATALOG_ID}/items_batch

Batch size

Up to 5,000 requests per call; Meta suggests under 3,000

Run modes

Replace (complete file) or update (partial file)

• Running a partial file as a replace

  A prices-only or changed-items file uploaded as a replace can remove every item it does not list, and product messages break overnight. Use an update run or a supplementary feed for anything less than the full catalogue.

• IDs that change between exports

  A platform migration or export setting that rewrites id creates new items and orphans the old ones: saved product messages fail and order webhooks carry IDs your warehouse cannot match. Pin id to the SKU.

• Prices without a currency code

  1299 or Rs. 1,299 does not parse; 1299.00 INR does. Use a dot for decimals, no thousands separators, and the same format for sale_price.

• Image URLs Meta cannot fetch

  Images behind a login, blocked by a firewall or bot rule, or redirecting to an error page fail the item. Serve them from public HTTPS URLs and test them from outside your own network.

• A schedule slower than your stock

  A weekly feed for fast-moving stock means customers order what sold out days ago. Match the schedule to how often stock changes, and push stock-outs through the batch API in between.

A WhatsApp catalogue is only as accurate as its last sync. When the feed lags, customers add sold-out items to carts, see yesterday's prices and order products the business no longer stocks — and each of those carts turns into a support conversation that starts with an apology. A reliable feed with stable IDs, a schedule that matches how fast stock moves and someone watching its errors is what lets product messages and the in-chat cart be trusted, by customers and by the team that packs the orders.

• Generate the feed from the same database your checkout uses, not from a spreadsheet someone edits by hand.
• Keep one row per purchasable variant and group variants with item_group_id.
• Alert when a scheduled run fails or its item count drops sharply, not only when someone notices missing products.
• Mark sold-out items out of stock instead of deleting them, so their IDs and links keep working — and a back-in-stock alert can fire the moment the feed flips them back.
• Keep products the WhatsApp Commerce Policy does not allow out of the feed, rather than waiting for them to be rejected.