> ## 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.

# Reading publish status

> Interpret draft / live / changed status, per-target chips, and per-environment publish outcomes.

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:

<ResponseField name="Draft" type="not yet published">
  The product has never been published to any target. It exists only in
  MerchantOps.
</ResponseField>

<ResponseField name="Live" type="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.
</ResponseField>

<ResponseField name="Changed" type="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.
</ResponseField>

<Tip>
  You can read this same status from an agent with the
  [`get_product_publish_status`](/tools/mcp) MCP tool, which returns the
  draft / live / changed state plus the per-target chips described below.
</Tip>

## 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 live on production and changed 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:

| Field         | Meaning                                                      |
| ------------- | ------------------------------------------------------------ |
| Status        | `success`, `failed`, or `skipped`                            |
| Response code | The status or result code from the destination               |
| Attempts      | How many tries it took (more than one means it was retried)  |
| Duration      | How long the publish call took                               |
| Error         | A short failure summary, present when the status is `failed` |
| External ID   | The record's ID in the destination system, when one exists   |

## Succeeded vs failed vs skipped

<AccordionGroup>
  <Accordion title="Succeeded">
    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.
  </Accordion>

  <Accordion title="Failed">
    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`.
  </Accordion>

  <Accordion title="Skipped">
    The record was intentionally not published — for instance a connector chose
    to skip it. Skips are recorded as outcomes too, so they don't silently
    disappear.
  </Accordion>
</AccordionGroup>

## 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** — all records succeeded.
* **Partial** — some records succeeded and some failed. Review the failed
  records' error summaries, fix the underlying data, and publish again.

Publishing runs as a background [job](/getting-started/concepts), so you can
watch progress and see per-record errors on the **Jobs** page while a batch is
in flight.

<Note>
  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](/publishing/vtex)). A warning
  doesn't turn a `success` into a `failed`; it flags follow-up work.
</Note>

## Next steps

<CardGroup cols={2}>
  <Card title="Publishing overview" icon="rocket" href="/publishing/overview">
    How batches, targets, and scheduling fit together.
  </Card>

  <Card title="Build your own connector" icon="plug" href="/publishing/connectors">
    Report outcomes from your own target and see them here.
  </Card>
</CardGroup>