> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mercurjs.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Handle product requests

> Walk a vendor's product submission and a follow-up edit through the operator review pipeline — confirm, decline, or send back.

Because Mercur's catalog is [shared](/rc/learn/products), vendors never mutate products directly. New products and edits arrive as **product changes** — reviewable requests the operator confirms, declines, or sends back for revision. This tutorial plays both roles: the vendor submitting, and the operator reviewing.

<Info>
  **Nothing touches the live product while a change is pending.** A `ProductChange` bundles ordered actions (`UPDATE`, `VARIANT_ADD`, `ATTRIBUTE_UPDATE`, …) that are applied only on confirmation. Declining or canceling leaves the product exactly as it was — and confirmed changes are never deleted, so the same records double as the product's audit trail.
</Info>

## What you'll build

One complete review cycle: a vendor submits a new product, the operator requests a revision, the vendor resubmits, the operator publishes. Then a smaller edit request on the now-live product.

## Review outcomes

The review queue on the admin product detail offers three outcomes:

| Action              | Effect                                                                                               |
| ------------------- | ---------------------------------------------------------------------------------------------------- |
| **Confirm**         | The product is published into the shared catalog                                                     |
| **Reject**          | Status becomes `rejected`; the product stays out of the catalog                                      |
| **Request changes** | The submission returns to the vendor with a reason (`requires_action_by` / `requires_action_reason`) |

## Run the review cycle

<Steps>
  <Step title="Submit a product as the vendor">
    In the Vendor Portal, create a product. Vendor-created products enter the catalog with status **`proposed`** — visible only to their creator, not to other sellers or the storefront.

    Behind the scenes the platform records a `ProductChange` with a `PRODUCT_ADD` action and `created_by` set to the submitting member. That attribution is what keeps the seller's unpublished submissions in their own product list.
  </Step>

  <Step title="Request changes as the operator">
    In the Admin Panel, open the product and choose **Request changes** with a note — say, "add product dimensions". Use the external note for the vendor-visible message; internal notes stay operator-only.
  </Step>

  <Step title="Revise and resubmit as the vendor">
    Back in the Vendor Portal, the product page shows the revision request and the operator's note. The vendor updates the product and resubmits. As the operator, **Confirm** this time — the product's status flips to `published` and it enters the shared catalog for every eligible seller.
  </Step>

  <Step title="Request an edit on the live product">
    Now that the product is published, edits also flow through review. As the vendor, change the product's description. This creates a new `ProductChange` in `pending` with an `UPDATE` action — the live product is unchanged until the operator confirms. Confirm it and watch the description update.
  </Step>
</Steps>

<Note>
  Any seller may propose changes to any published product — the shared catalog is collaborative. Selling-eligibility restrictions limit who may *sell* a product, not who may *suggest improvements* to it.
</Note>

## Verify

1. After step 1, the product is `proposed`: visible in the submitting vendor's list, absent from other vendors' lists and the Store API.
2. After **Request changes**, the vendor sees the revision note; the change is flagged `requires action`.
3. After the final **Confirm** in step 3, the product is `published` and appears in the Store API.
4. During step 4, the storefront still shows the old description while the change is `pending` — and the new one after confirmation.
5. The product's change history lists every change with who requested it, who reviewed it, and when.

## FAQ

<AccordionGroup>
  <Accordion title="Do all edits require operator review?">
    No — some low-risk edits are **auto-confirmed**: they still create a change record for the audit trail but apply immediately without waiting. Structural changes (variants, attributes, status) go through review.
  </Accordion>

  <Accordion title="Can the vendor withdraw a pending request?">
    Yes — a pending change can be **canceled** by its requester, recorded with the same audit fields (`canceled_by`, timestamp). Once confirmed or declined, the outcome is final; a new change is needed for further edits.
  </Accordion>

  <Accordion title="What's the difference between rejecting and requesting changes?">
    **Reject** is terminal for a submission — the product is marked `rejected` and stays out of the catalog. **Request changes** keeps the change alive and hands it back to the vendor with a reason; it's the "revise and resubmit" path.
  </Accordion>
</AccordionGroup>

## Next steps

<CardGroup cols={2}>
  <Card title="Product Requests & Approvals" href="/rc/learn/product-requests">
    The full ProductChange data model, actions, and lifecycle.
  </Card>

  <Card title="Master products & offers" href="/rc/resources/tutorials/master-products-and-offers">
    What happens after publication — sellers listing against the shared record.
  </Card>
</CardGroup>