> ## Documentation Index
> Fetch the complete documentation index at: https://docs.merchantops.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Publishing overview
> How MerchantOps publishes approved catalog and pricing changes to your storefront and other targets.
Publishing is how approved product and pricing changes leave MerchantOps and
land in the systems that run your storefront. This page explains the model —
batches, targets, approval, scheduling, promotion, and status — for
merchandisers reviewing changes and developers wiring MerchantOps into their
stack.
Publishing is a **generic connector pattern**: MerchantOps holds the approved,
versioned records and hands them to a **target**. Some targets ship with
MerchantOps (see [VTEX](/publishing/vtex)); others you
[build yourself](/publishing/connectors) against a pull-based API. The concepts
below are the same regardless of the destination.
## 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](/pricing/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).
Each destination + environment pair is configured once as an **integration**
under **Settings › Publish Targets**, and a batch points at one of them.
**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.
Set the effective date to a future moment to stage a coordinated launch;
set it to the present to publish as soon as the batch is approved.
## 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.
Promotion does not cascade a cancellation: cancelling a source batch does not
cancel a batch already promoted from it. Each batch in the chain is
independent, and the UI shows the relationship so you can decide what to do.
## 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](/publishing/publish-status) for the full status
model, and [`get_product_publish_status`](/tools/mcp) to query it from an
agent.
## Next steps
Run your own target adapter against the pull-based publishing API.
See how MerchantOps publishes catalog and pricing to VTEX.
Interpret draft / live / changed, per-target chips, and outcomes.
Group, review, and schedule price changes for publishing.