Skip to main content
Because Mercur’s catalog is shared, 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.
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.

​
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:
ActionEffect
ConfirmThe product is published into the shared catalog
RejectStatus becomes rejected; the product stays out of the catalog
Request changesThe submission returns to the vendor with a reason (requires_action_by / requires_action_reason)

​
Run the review cycle

1

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

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

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

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

​
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

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

​
Next steps

Product Requests & Approvals

The full ProductChange data model, actions, and lifecycle.

Master products & offers

What happens after publication — sellers listing against the shared record.