Meta product catalog: setup, fields, and feed monitoring
Learn what a Meta product catalog is, how feeds and APIs populate it, which fields and variants matter, and how to keep Facebook and Instagram data accurate.
A Meta product catalog is where your product facts become usable across Meta's commerce surfaces. The catalog can look healthy while a price is stale, a variant opens the wrong page, or a feed upload leaves many items rejected. The operating work happens between your source systems and Commerce Manager. You need a clear catalog, feed, and API boundary, stable fields and variant IDs, and checks that keep Facebook and Instagram data aligned with what shoppers can buy.
What a Meta product catalog is
Meta's catalog documentation describes a catalog as a container for product information and inventory. In practice, it is the item store you manage in Commerce Manager. A catalog holds product records that Meta can use across its technologies, including shopping and advertising surfaces.
A feed is the file or scheduled data source that supplies those records. An API is the programmatic path for creating, updating, or deleting items and for checking upload status. Commerce Manager is where you configure the catalog, sources, permissions, product sets, and diagnostics. You may see the same input called a Facebook product catalog feed or an Instagram Shopping feed. Those names describe the destination, not a separate product-data model.
Your source may be a storefront, enterprise resource planning (ERP) system, product information management (PIM) system, digital asset management (DAM) system, or supplier feed. Keep the boundary clear:
| Layer | What it does | What it is not |
|---|---|---|
| Product source | Owns facts such as stock keeping unit (SKU), price, inventory, copy, and approved media | A Meta catalog |
| Feed | Sends a snapshot or update file to Meta | A master product database |
| API | Sends item changes and reads processing state programmatically | A guarantee that an item is eligible or visible |
| Meta product catalog | Stores the items and makes them available to selected Meta surfaces | A replacement for your commerce or inventory system |
A reliable operating path looks like this:
storefront, ERP, PIM, DAM, or supplier data
→ normalized product and variant records
→ primary feed or API updates
→ Meta product catalog
→ Facebook and Instagram shopping surfaces
The distinction matters because a successful file fetch only proves that Meta reached the source. It does not prove that every row parsed, that every item has usable data, or that a shopping surface will show it.
Choose how products enter Commerce Manager
Create or select an online-products catalog in Commerce Manager, assign it to the right business portfolio, and choose a data source. Meta's catalog setup documentation lists the current screens and permissions. The labels can change, so use the live instructions for exact clicks.
The durable choices are these:
| Source path | Best fit | Operating responsibility |
|---|---|---|
| Manual entry | A small catalog, a pilot, or a few one-off products | Someone must update every changing field and record the change. |
| Scheduled data feed | A store or pipeline that can publish CSV, TSV, or XML at a URL or upload location | Generate a complete file, set a cadence, and monitor each fetch and processing result. |
| API or partner integration | Large catalogs, frequent inventory changes, or engineering-owned workflows | Handle credentials, rate limits, retries, partial failures, and item-level status. |
Meta supports one-time and scheduled feed uploads. Its current setup documentation lists hourly, daily, and weekly schedules. Scheduled feeds are useful for regular changes, while the Feed API reference documents programmatic feed configuration, upload sessions, and status checks. A partner connection can reduce setup work when it already owns a reliable product record. It should not become an excuse to run several ungoverned sources for the same item.
Before the first full load:
- Select the product type and business portfolio deliberately. Catalog type affects the data contract and cannot be changed casually later.
- Decide which system owns each field. Your commerce platform or ERP often owns price and inventory. A PIM or approved content workflow may own titles and attributes. A DAM may own media.
- Publish a representative test set. Include a normal item, a multi-variant item, an out-of-stock item, a sale-price item, and a localized item when those cases exist.
- Compare the processed records with the source before releasing the full catalog.
The goal is a repeatable output, not a feed file that only one operator knows how to repair.
Build each product record around the sellable item
Meta's data feed specifications for catalogs define required fields by product type and destination. For ecommerce products, start with the fields below. Treat the specification as the authority for accepted values and limits because Meta can change them.
| Field | What to send | Why it matters |
|---|---|---|
id | A unique, stable identifier for the item | Joins updates to the same item. Use the sellable variant ID when variants differ. |
title | A specific product name | Gives shopping surfaces a clear label. Include the attributes needed to distinguish the item. |
description | Factual, plain-text product information | Supplies context beyond the title. Keep it consistent with the landing page. |
availability | A value from Meta's accepted availability vocabulary | Prevents an unavailable item from being represented as purchasable. |
condition | The item's condition, such as new, refurbished, or used | Separates materially different offers. |
price | A number plus an ISO currency code, such as 148.00 USD | Gives Meta a typed price instead of an ambiguous symbol or locale format. |
link | An absolute URL to the product or variant page | Gives the shopper a page for the exact offer represented in the row. |
image_link | A publicly reachable main product image | Lets the surface render the item and should represent the same variant. |
brand, mpn, or gtin | At least one valid identifier field. mpn is a manufacturer part number; gtin is a global trade item number. | Helps identify the product and supports downstream matching. Never invent an identifier. |
inventory | Quantity when the selected commerce surface requires it | Adds a quantity signal for surfaces that support inventory-based selling. |
google_product_category | A category mapping when the selected surface or use case requires it | Adds channel taxonomy without replacing your internal category. |
Use Meta's field names exactly, including underscores and casing. Column headers should use US English. Keep category-dependent fields separate from the universal ecommerce core. For example, inventory and google_product_category matter for some commerce or checkout configurations, but they are not a reason to pretend every catalog has the same requirements.
A small variant record might look like this:
id: JKT-001-NVY-M
item_group_id: JKT-001
brand: Northline
title: Northline commuter jacket, navy, medium
description: Recycled-nylon commuter jacket with a water-resistant shell.
availability: in stock
condition: new
price: 148.00 USD
link: https://shop.example/products/jkt-001?variant=navy-m
image_link: https://cdn.example/products/jkt-001-navy-m.jpg
color: navy
size: MThis is an illustrative record, not a complete CSV header. In a real CSV, TSV, XML, or API payload, keep the exact schema and syntax required by the chosen source path.
Model variants and identifiers explicitly
A product family, a sellable variant, and a seller offer are different objects:
| Level | Example | Values that usually belong here |
|---|---|---|
| Product family | Northline commuter jacket | Shared name, brand, description, and category |
| Variant | Navy, medium jacket | SKU, option values, variant image, variant URL, price, and availability |
| Offer | Northline's US offer in USD | Seller, market, currency, price, stock state, and fulfillment context |
Make the variant the unit of the feed row whenever price, stock, image, URL, or identifiers can differ. Use a stable id for each variant and keep it stable across updates. Do not recycle an old ID for a new color or size. Do not derive identity from a title that may be edited.
Where your catalog type supports variant grouping, use item_group_id or the equivalent field to connect variants to their family. Send color, size, and other option fields from the current Meta specification. Do not ask Meta to infer a relationship from a title such as “jacket, navy, medium.”
The landing page must resolve to the same choice. A row for navy medium should open navy medium, show its image, show its price, and show its stock state. A generic product page that defaults to black large creates a data mismatch even when every feed column is populated.
If your website or app sends product IDs in shopping events, use the same catalog id for the corresponding item. A feed ID that differs from the event ID can break the link between the item a person viewed and the item represented in the catalog. Catalog's guide to product data APIs covers the broader identity and variant model without tying it to one destination.
Keep price, availability, images, and links accurate
A catalog row is a promise about an offer. Reconcile the row with the page and checkout path before publishing it.
- Price and currency: Send the numeric amount and currency together. Use a period for decimals and keep the feed, product page, structured data, and checkout aligned. Treat a sale price and its effective dates as one change. Remove or expire the sale value when the promotion ends.
- Availability and inventory: Map source statuses to Meta's accepted values. Do not translate a backordered, discontinued, or channel-restricted item into
in stockwithout an explicit business rule. If a surface usesinventory, update the quantity from the system that actually owns sellable stock. - Links: Use an HTTPS URL that resolves to a purchase-ready page. Avoid a link that requires a login, lands on an unrelated product, or drops the selected color and size. Check redirects, locale handling, and canonical product selection.
- Images: Keep the image URL reachable without a session and make sure the asset represents the row. Publish the new asset before changing the feed URL, and keep the old asset available until the replacement can be retrieved. Follow Meta's current image format, size, and content rules.
- Identifiers: Preserve the merchant SKU and manufacturer identifiers in your canonical record. Validate
gtinandmpnformats when present. A missing identifier is safer than a fabricated one. - Country and language: Treat market, language, currency, and URL as part of the offer. A US price and an EU landing page are not one localized record. Use Meta's country and language feed options when the catalog serves different markets.
- Categories and duplicates: Map your controlled internal category to Meta's destination taxonomy. Check that every row has one unique ID and that the same variant is not emitted twice under different keys.
These checks are product-data quality work, not campaign optimization. Catalog's guide to product data quality goes deeper on completeness, validity, uniqueness, and freshness across channels.
Use primary and supplementary updates deliberately
A primary feed is the catalog's main source. It should contain the complete set of products that the catalog owns, including additions and removals. A replace-style primary update can remove items that disappear from the next complete snapshot, so alert on unexpected row-count drops before the update runs.
A supplementary feed is an overlay for items that already exist in a primary source. Meta's Feed API documentation states that supplementary feeds can update catalog items, but cannot create or delete them. Use one for a narrow, governed change such as a channel label or a targeted price and availability update. Keep the full product lifecycle in the primary source.
For fast-moving inventory, a scheduled file may be too slow. Meta documents the Catalog Batch API as a programmatic option for targeted updates. Use it when your team can own the request, retry, and status workflow. Do not let a batch endpoint become a second product database.
A dependable freshness loop has six steps:
- Detect a source change in price, availability, inventory, content, or media.
- Normalize the value and validate it against the product and variant contract.
- Publish a complete primary snapshot or an item-level update with a version and timestamp.
- Record the feed ID, upload session, API request, or batch handle.
- Check processing results and catalog diagnostics. Keep warnings and fatal errors tied to the source version.
- Reconcile expected IDs, processed IDs, and a sample of live landing pages.
Set cadence by risk. Price, availability, and inventory need event-driven updates or the most frequent reliable schedule your source supports. Titles and attributes can follow approval. Images should change after asset approval and URL checks. Full reconciliation should run often enough to catch missed events, deletions, and source drift.
Monitor processing and catalog issues
Treat delivery, processing, and visibility as separate states:
| State | What it proves | What to do next |
|---|---|---|
| Fetched or uploaded | Meta received the file or request | Check the upload session and row or item counts. |
| Parsed or processed | Meta read the structure and attempted item updates | Inspect item-level warnings, errors, and omitted fields. |
| Accepted item | The item exists in the catalog with usable data | Compare it with the source and the landing page. |
| Eligible or visible surface | A selected destination can use or show the item | Keep monitoring freshness and destination-specific issues. |
Meta recommends checking upload errors and warnings in Commerce Manager's Diagnostics after each upload. The Feed API supports querying recent upload sessions, sampling errors and warnings, and generating a fuller error report. A fatal error means Meta cannot ingest the item. A warning can cause a field to be omitted while other fields continue processing. Read the upload and error guidance with the current field specification.
Use a small incident table for triage:
| Symptom | Inspect first |
|---|---|
| Feed fetched, item missing | Primary-feed completeness, omitted IDs, duplicate IDs, and unexpected deletions |
| Price or stock is wrong | Currency, sale fields, source timestamp, landing page, and checkout state |
| Wrong color, size, or image | Variant ID, group ID, option values, variant URL, and image URL |
| Image rejected or blank | URL response, access controls, redirects, format, and whether the asset matches the item |
| Many rows rejected | Header spelling, delimiter, encoding, required fields, and accepted value lists |
| Feed processed, surface still empty | Item eligibility, account permissions, market settings, policy, or destination availability |
Record the source version, product ID, variant ID, upload time, processing result, error text, and owner. This turns “the Meta feed is broken” into a fixable data change. A green scheduler job is not enough if the last successful price update is two days old or if a row now points to a 404 image.
How Facebook and Instagram use a product catalog
One catalog can support more than one Meta surface. Depending on the business, product type, country, and current eligibility, catalog items can appear in:
- Facebook or Instagram shop experiences;
- Instagram product tags and other shoppable content;
- collection and catalog-based ads that select products from the catalog;
- product sets used to choose a subset of items for a destination or campaign.
The catalog supplies the item facts and relationships. The surface decides how those facts are rendered. A title, image, price, availability, and link can all be correct in the catalog while a business still lacks access to a particular shop or checkout feature. Meta's own field documentation notes that checkout fields apply only to sellers who can use that commerce flow. Do not promise native checkout, product tagging, or reach for every business or region.
Keep the operational question narrow: when a shopper sees a product on Facebook or Instagram, does the item match the offer you can sell now? The answer depends on the feed or API, the catalog processing state, the destination settings, and the account's eligibility. It does not come from campaign settings alone.
Keep Meta as a destination, not your product truth
Meta is one channel output. Your source systems still need a canonical model for products, variants, offers, media, market, and timestamps. If two systems disagree about a price or variant ID, a feed only moves the disagreement downstream.
Catalog helps teams build the layer before that handoff. We structure and normalize product data, preserve variant relationships, keep live, normalized records synchronized, validate changing fields, expose machine-readable product objects to AI shopping surfaces, and measure what those surfaces do with the data. The same controlled records can produce a Meta-ready channel output alongside other destinations. Catalog works beside your storefront, ERP, PIM, DAM, and existing feeds rather than asking one destination to become the master catalog.
For the source-to-destination operating model, see product data integration. For a destination-specific comparison of source, processing, and visibility states, see our Google Merchant Center feed guide.
FAQ
Is a Meta product catalog the same as a product feed?
No. The catalog is the managed container of item records. A feed is one input that creates or updates those records. An API, manual entry, or partner integration is another input path.
Can one catalog serve Facebook and Instagram?
Often, yes. A catalog can support multiple Meta technologies, so teams usually avoid maintaining separate product datasets for Facebook and Instagram. Surface availability, product eligibility, market rules, and checkout options still vary.
How often should a Meta catalog feed update?
Set the cadence from field risk. Refresh price, availability, and inventory as often as they change. Refresh content and media after approval. Use a frequent scheduled feed or an API update when a slower file would leave the catalog out of sync with the offer.
Why did my feed upload succeed while products are missing?
Upload success proves transport. Inspect the upload session, item-level processing errors, warnings, unexpected ID changes, primary-feed omissions, and destination diagnostics. Then compare a missing item's catalog record with its landing page.
Does every variant need its own catalog ID?
Give each sellable variant its own stable ID when price, stock, image, URL, or identifiers differ. Use a supported group field to connect variants to their family. Keep the variant URL and image aligned with the option values in that row.
If Meta is one of several destinations your team needs to keep current, see how Catalog works as a product-data layer for AI commerce.
