Batches
Changes publish in batches, not one record at a time. A batch groups a set of catalog or pricing records so they can be reviewed together, approved once, and published as a unit. Catalog batches carry product changes (names, descriptions, attributes, specifications); price batches carry price records. See Price batches for the pricing workflow. A batch moves through a lifecycle: it starts as a draft you can edit, goes to pending approval for review, becomes approved, and is then published to its target. What you can edit narrows as the batch advances:
The target stays editable at pending approval and at approved by design.
Approval does not require a target, so a batch can reach
approved without one;
setting the target then is the way to rescue it rather than rebuilding the
batch. The target locks as soon as publishing is attempted — from that point the
recorded outcomes are keyed to it, so it can no longer move.
Reviewing records inside a batch
A catalog batch can be approved as a whole — the confirmation says plainly that you are approving every product without per-product review — but the point of a batch is usually to look at the products first. Select records in the batch’s product list and choose Review to open the review panel. It takes over the page and walks the selection one product at a time, showing that product’s property values as the publish will send them. The version shown is the one pinned to the record, so you are reading exactly what will be published, not whatever the product looks like right now. Approve or reject each product as you go — there are keyboard shortcuts for stepping through, approving, and rejecting with a reason — and the batch’s counts update as you stamp them. The same selection toolbar can reject the selected records outright, with an optional reason, and remove them from the batch entirely. A record can also be rejected from its row without opening the panel.Rejected records block approval of the batch: approve refuses while any record
is rejected, and asks you to remove or reassign them first. Rejected records
also do not carry forward when the batch is promoted.
Choosing what reviewers see
Which properties the review panel shows is configuration, not a fixed list. Each product type can have its own set of visible properties, and an organization can set a default that applies to every type without one. If neither is set, the panel falls back to a sensible selection; operational and system properties (vendor identifiers and similar) are hidden by default so reviewers see the content fields first. Edit the list from the review panel’s field-configuration dialog; clearing a type’s own list returns it to the organization default.Publishing targets
A publishing target is a destination for a batch. A target is the combination of:the system
Which system the batch publishes to — for example a VTEX store. Identified by
a target key such as
vtex_catalog or vtex_pricing.which instance of the destination
Which instance of that destination — for example a QA store versus a
production store. A single organization can have several environments of the
same destination enabled at once (a QA target and a production target side by
side).
A target is optional at approval. A batch can be approved without a target —
its records go active in MerchantOps but the batch is never published. Use
that when you want MerchantOps to hold the approved change without sending it
downstream. A target is required only to actually publish. Set it on the draft
when you already know the destination — and if a batch reaches
approved
without one, you can still set it there.Scheduling by effective date
Every batch carries an effective date. Once a batch is approved and has a target, MerchantOps waits until that date arrives, then publishes the batch automatically — no manual “publish now” step. This lets you approve a price change or catalog update ahead of time and have it go live on schedule. Publishing runs in the background as a job you can track. A batch approved without a target stays active in MerchantOps and is never published — the scheduler skips it.Publishing manually
Waiting for the effective date is the normal path, not the only one.approved batches
Publishes an approved batch immediately, ahead of its effective date. The
effective date is not changed, and the batch will not publish a second time
when that date arrives. It is also how you retry a batch whose publish failed
or only partly succeeded. For a price batch with a future effective date,
this opens a confirmation you complete by typing
Yes — see
Price batches for what publishing early affects.
Publish now needs a target, a publish that is not already in flight, and, for
a price batch, any linked catalog batch to have published first.published price batches
Re-delivers a price batch that already published, after you have corrected the
underlying data. It re-drives the whole batch rather than only the failures.
Catalog batches have no separate republish action — re-running publish on a
partly published catalog batch re-attempts only the records that have not
published yet and skips the ones that already did, even if their product
changed since.
catalog batches
Unsticks a catalog batch that is wedged mid-publish because an outcome was
never reported, so it never finishes on its own. Resetting moves it to
partially published or failed, from which it can be published again. It is
deliberately refused for the first several minutes of a publish so a run that
is still legitimately working is never interrupted. Price batches have no
equivalent action — recover them with Publish now (failed or partial) or
Republish (already published).
Promotion between environments
When you keep the same destination in more than one environment (say, QA and production), you promote a published batch from one environment to the next rather than rebuilding it by hand. In both cases promotion creates a new draft batch aimed at the destination, requires the source to have published fully, requires the destination to differ from the source’s target and environment, and requires the destination target to be enabled. How the child gets its content differs by batch type.- Catalog batches
- Price batches
The child copies the source’s records — only the approved ones.
Records rejected on the source stay rejected there and do not carry forward.
Each copied record is re-snapshotted to the latest version of its
product at promote time, so fixes made between the two publishes are picked
up.The copies arrive pending, not approved, so the child goes through
review again before it can be approved and published.
Reading publish status
After a batch publishes, MerchantOps records an outcome per target and per environment for every record — so a single record can carry an independent QA result and production result without collision. At the product level, a draft / live / changed indicator plus per-target chips tell you where a product is published and whether its live data has drifted from what’s in MerchantOps. See Reading publish status for the full status model, andget_product_publish_status to query it from an
agent.
Next steps
Build your own connector
Run your own target adapter against the pull-based publishing API.
VTEX (reference connector)
See how MerchantOps publishes catalog and pricing to VTEX.
Reading publish status
Interpret draft / live / changed, per-target chips, and outcomes.
Price batches
Group, review, and schedule price changes for publishing.