Skip to main content
Every master product has a status that decides who can see it and whether it’s for sale. Mercur uses that status as a review gate: stores submit products as proposed, and an operator decides whether each one joins the published catalog.

​
The four statuses

The status lives in the status field of Medusa’s Product model. Mercur re-exports the values as ProductStatus from @mercurjs/types. The model default is draft.

​
Review transitions

Mercur ships one workflow per review step. Each one reads the product, checks its status with validateProductsStatusStep, records a confirmed ProductChange, and emits an event. A Status transitions table: createProductsWorkflow creates a product as proposed, then confirmProductsWorkflow, rejectProductWorkflow, and requestProductChangeWorkflow move it to published, to rejected, or keep it proposed, with a product_change audit table behind. A Status transitions table: createProductsWorkflow creates a product as proposed, then confirmProductsWorkflow, rejectProductWorkflow, and requestProductChangeWorkflow move it to published, to rejected, or keep it proposed, with a product_change audit table behind. The three review workflows run only on proposed products. A product in any other status fails with a NOT_ALLOWED error that lists each product id and its current status.

​
Starting status

The status a product starts in depends on who creates it. createProductsWorkflow passes the status you give it to Medusa, which falls back to draft.
  • Vendor API: defaults to proposed; a store may also send draft
  • Admin API: uses the request’s status, or draft when it has none
  • Your own code: whatever you pass, or draft
The vendor rule comes from the product_request feature flag, which is on by default. Turn it off with MEDUSA_FF_PRODUCT_REQUEST=false and stores can create products in any status, including published.
.env
The same flag controls whether store edits to existing products wait for review. See status and auto-confirm.

​
Changes outside the review workflows

Mercur ships no workflow that moves a draft to proposed, or a published product back. Those changes go through a regular product update. The admin API runs Medusa’s updateProductsWorkflow for that, which accepts any status.
A direct status update skips the proposed check, writes no STATUS_CHANGE record, and emits none of Mercur’s product events. Use the review workflows when you need the audit trail.