Skip to main content
Once you start publishing, MerchantOps tracks where each product is live and whether its live data still matches what’s in MerchantOps. This page explains the status indicators so you can tell at a glance what’s published, what’s drifted, and what failed.

​
Product-level status

Each product carries a top-level publish state:
​
not yet published
The product has never been published to any target. It exists only in MerchantOps.
​
published and in sync
The product has been published and its live data matches the current MerchantOps version — nothing has changed since the last successful publish.
​
published but drifted
The product was published, but its data in MerchantOps has changed since then. The live storefront is behind — publish an updated batch to bring it back in sync.
You can read this same status from an agent with the get_product_publish_status MCP tool, which returns the raw draft / live / changed values — the API’s names for Draft / Published / Modified — plus the per-target chips described below.
Variant-only edits do not show up here. Drift is detected by comparing a fingerprint of the product’s product-level values against what was last published; that fingerprint does not yet include variants. Change a variant’s size, color, or barcode and the product stays Live — both the product-level status and the per-target chips below miss it. Republish deliberately after editing variants.
A batch approved without a publishing target is shown as active in MerchantOps but is never published, so it produces no publish status. The affected products stay Draft at product level, and you’ll see no per-target chips or outcomes for them until the batch is published to a target.

​
Per-target chips

A product can be published to more than one target and environment — for example a QA VTEX store and a production VTEX store. MerchantOps shows a chip per target so you can see each destination independently: one product might be Published on production and Modified on QA at the same time. Each chip reflects the most recent outcome for that destination. A product isn’t simply “published” or not — it’s published per target, and the chips make that explicit.

​
Per-target, per-environment outcomes

Under the hood, every record in a batch carries an outcome for each target and each environment it was published to. Because outcomes are keyed by both the target and its environment, a single record holds an independent QA result and production result without one overwriting the other. A recorded outcome captures what happened on that publish:

​
Succeeded vs failed vs skipped

The record was accepted by the destination. For a catalog record that means the product/SKU was created or updated; for a price record, the price was set. The record shows success and drops out of any pending-publish queue.
The destination rejected the record or a permanent error occurred — for example a variant with no matching SKU in the store. The outcome carries an error summary and a response code. Transient problems (rate limits, temporary server errors) are retried automatically first; only a record that can’t be published after retries lands as failed.
The record was intentionally not published — for instance a connector chose to skip it. The skip is stored on the record, so it doesn’t silently disappear, but it is not counted toward the batch’s progress: only success and failed advance the published/failed counts.That matters if you build your own connector: a skipped record never reports as done, so a batch containing one does not reach a final rollup state. Report success or failed for every record — use failed with an error explaining the reason where you would otherwise skip.

​
Batch-level rollup

As records report outcomes, the batch tracks published and failed counts and, when every record is accounted for, reaches a final state:
  • Published — at least 95% of the batch’s records succeeded.
  • Partial — fewer than 95% succeeded. Review the failed records’ error summaries, fix the underlying data, and publish again.
The same 95% threshold applies to both catalog and pricing batches.
Published does not mean every record succeeded. A batch flips to Published once 95% of its records succeed, so up to 5% of a Published batch may have failed — on a 500-record batch that is as many as 25 records that are not live. Always confirm against the per-record outcomes (open the batch and filter its records by outcome) rather than trusting the batch badge alone.
Publishing runs as a background job, so you can watch progress and see per-record errors on the Jobs page while a batch is in flight.
Batches sent to a self-built (poll) target do not roll up today. Their per-record outcomes are recorded and shown normally, but the batch itself stays in its publishing state instead of reaching Published or Partial, and the batch_final_status returned to the connector is always null. Batches sent to a built-in connector such as VTEX are unaffected. See build your own connector for how to track completion in the meantime.
Some connectors surface warnings alongside outcomes — non-fatal issues that didn’t fail the publish but need attention, such as a brand or category that doesn’t exist in the destination yet (see VTEX). A warning doesn’t turn a success into a failed; it flags follow-up work.

​
Fixing a partial batch

Partial (or Failed) means some records didn’t make it. Fix the underlying data — the product, variant, or price record the errors point at — and then re-drive the batch:
A catalog Republish skips records that already published successfully — they are not re-sent, even if the product changed since. To push a corrected product that already published, put it in a new batch.
Republishing a catalog batch and pricing Publish now / Republish all require approval permission (catalog_batch:approve and pricing:approve respectively).

​
Next steps

Publishing overview

How batches, targets, and scheduling fit together.

Build your own connector

Report outcomes from your own target and see them here.