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:| Status | What you can edit |
|---|---|
| Draft | Name, description, effective date, target, notes |
| Pending approval | Effective date and notes only |
| Approved / publishing / published | Locked |
| Cancelled | Locked (terminal) |
Publishing targets
A publishing target is a destination for a batch. A target is the combination of: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 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).
Approval requires a target. A batch can’t be approved until a target is
chosen — MerchantOps needs to know where the change is going. Set the target on
the draft (before submitting it for review); attempting approval without one is
rejected.
Scheduling by effective date
Every batch carries an effective date. Once a batch is approved, 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.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. Promotion:- Creates a new draft batch aimed at the next environment.
- Copies only the approved records from the source batch. Records that were rejected on the source stay rejected and do not carry forward.
- Re-snapshots each record to the latest version of its product at promote time, so any fixes made between the two publishes are picked up automatically.
- Requires the destination target to be enabled for that environment.
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.