proposed product from a custom route, a subscriber, or a scheduled job. Each one checks the status, records who reviewed the product, and emits an event.
Before you begin
You need the following in place:- A product in
proposedstatus, such as a store submission - The id of the operator or system acting, for the audit record
NOT_ALLOWED error for any product that isn’t proposed.
Review a product
1
Publish it
confirmProductsWorkflow publishes one or more products in a single run. internal_note is stored on each audit record for operators.src/api/admin/reviews/publish/route.ts
proposed, the run fails and none of them change.2
Or reject it
rejectProductWorkflow handles one product. message is stored as the change’s external_note, the note the store can read.rejected and leaves the store’s product list.3
Or ask for a revision
requestProductChangeWorkflow keeps the product proposed and records a CHANGE_REQUESTED action with your message.external_note.Run a review from a subscriber
Review products automatically by running a workflow when they’re created. This subscriber publishes products from one trusted store.src/subscribers/auto-publish-trusted.ts
PRODUCT_ADD record to find the submitter, then publishes. product.created fires twice for each product created through Mercur’s workflow, so the second run fails the proposed check. Catch that error, or check the status first.
React to the outcome with hooks
Each review workflow exposes a hook that runs after the status change. Use it for side effects that must happen inside the same run.src/workflows/hooks/product-rejected.ts
product.published, product.rejected, or product.change-requested instead.
Next steps
- Event reference for payloads
- Status lifecycle for every transition
- Request a revision for edits to published products