Skip to main content
Skip to main content

Store-Scoped Products and Change Requests

A store-scoped product belongs to one client store. You still maintain it from the Products page, but each edit, archive or deletion becomes a change request that the store approves before it is applied.

  • product-createCreate products, including store-scoped ones.
  • product-updateEdit products; on a store-scoped product this raises a change request.
  • product-deleteArchive or delete products; on a store-scoped product this raises a change request.
  • item-change-requests-list-as-supplierSee the Change requests page under Products.
  • item-change-requests-show-as-supplierOpen a change request and its proposed changes.
  • item-change-requests-cancel-as-supplierWithdraw a change request the client has not decided yet.

Overview​

By default a product you publish is global: it is one record, you edit it freely, and it can be offered into every client store you are connected to. Each store decides which of your prices it accepts through its offer approvals, but the product data is yours.

A store-scoped product is created for one client store. It is useful when a client wants an item that exists only for them, such as a bespoke kit, a client-specific pack size or a private-label item, and wants to control what changes about it. Once a product is store-scoped:

  • It is visible and orderable only in that store. Its prices may only target that store, never another store and never all stores.
  • You cannot change or remove it directly. Each edit, new variant, archive or deletion you submit is recorded as an item change request for the store's client to review. The live item, and therefore ordering, stays exactly as it was until the client approves.
  • Approval applies your change exactly as a normal save would. Rejection leaves the item unchanged and tells you why.
  • The scope is permanent. A product cannot be changed from global to store-scoped, or back, after it is created.

Note

Prices are not part of a change request. A price you add to a store-scoped product goes through the store's offer approvals as usual; only the product data (name, description, codes, properties, images, documents, stock, options and variants) is reviewed as an item change request.

Creating a store-scoped product​

  1. Go to Products and select Add product
  2. On the Details step, open the Store scope field
  3. Pick the client store the product is for, then complete the remaining steps as for any other product

The Store scope list offers the stores you are connected to. Leaving it empty keeps the product global and available to every store you supply.

Because the product is store-scoped, saving does not create it straight away. The platform validates your product, records it as a create change request and confirms Submitted for client review. You are taken to the request itself, where you can follow its progress. The product appears in your catalogue only after the client approves the request; until then it does not exist and its identifier is not yet taken.

Store-scoped products cannot be created from CSV or JSONL files or the batch endpoint. Set the scope when you add the product in the portal, or send store_id when you create it through the API.

Recognising a store-scoped product​

On the Products page a store-scoped product carries a Store scoped badge under its name, and an Under review badge while it, or one of its variants, has a change request waiting on the client. Use the Scope filter to show only store-scoped products or only global ones.

Opening the product shows the same badges in the header (Store scoped and Awaiting client review) and a banner explaining that edits, archives and deletions are submitted to the store's client, with a link to your change requests. Variants show the badges of their parent product, since a variant of a store-scoped product is itself store-scoped.

Changing a store-scoped product​

You change a store-scoped product from the same places as a global one. What differs is the outcome: instead of saving, the platform records a change request and shows Submitted for client review. The item keeps its current data until the client approves.

What you doWhereChange request created
Edit the product's detailsEdit on the product's Details cardupdate for the product.
Edit a variant's detailsEdit on the variant's Details cardupdate for the variant.
Add a variantAdd variant on a complex productcreate for the variant. The variant exists once the client approves.
Archive or delete the productThe row menu on the Products page, or the product's Details carddelete for the product.
Archive or delete a variantThe variant's Details carddelete for the variant.

Removing an item needs a reason​

Archiving or deleting a store-scoped item opens a Request archiving or Request deletion dialog instead of the usual confirmation. Enter a Reason (up to 2000 characters) explaining why the item should go; it is shared with the client reviewing the request and is required. The item stays live and orderable until the client approves. An approved request archives the item; it disappears from the store but remains in your archives for reporting, and it cannot be restored from your side. Ask the client to approve a new product if it is needed again.

Editors that are hidden​

The Details card is the only editor on a store-scoped product. The separate cards for images, codes, properties, documents, stock and options have no edit controls, because the platform cannot turn those granular changes into a change request. Put everything you want changed into one edit of the product or variant details instead; the whole edit becomes a single request the client reviews at once.

For the same reason, CSV and JSONL imports and the batch endpoint refuse rows that target a store-scoped product, the mass-delete tools skip store-scoped products, and an archived store-scoped product has no Restore action.

Following your change requests​

Go to Products → Change requests. The page lists every request you have raised across all your stores, newest first, with tabs for Pending, Approved, Applied, Rejected and All. The pending and approved tabs show how many requests are waiting.

ColumnMeaning
ItemThe item type and identifier, for example Product KIT-ACME-001, with your reason underneath when you gave one.
TypeProduct or Variant.
ChangeCreate, Update or Delete.
StoreThe client store the request was raised in.
StatusSee Statuses.
SubmittedWhen you submitted it.
ResolvedWhen the client decided it, or when it was superseded or cancelled.

Narrow the list with the Change, Item type and Store filters, or by Submitted after and Submitted before dates.

Select a request to open it. The detail page shows the store, the timestamps, Your reason, and, once the client has decided, their resolution note. The Proposed changes table lists each field you changed with its old and new value, so you can see exactly what the client is reviewing. A deletion has no field-level changes.

Cancelling a request​

While a request is still open you can withdraw it with Cancel request, from the row menu or the detail page. The proposed change is discarded and the item keeps its current data. You do not need to cancel before submitting a corrected version; see One open request per item.

Statuses​

StatusMeaning
pendingWaiting for the client to decide. You can still cancel it or replace it with a new submission.
approvedThe client approved it but applying it failed, usually because the change no longer validates, for example a category that was removed since you submitted. The client can retry or reject it, or you can cancel it. You cannot submit a new request for the item until one of those happens.
appliedApproved and applied. The live item now carries your change, or has been archived.
rejectedThe client rejected it. Read their resolution note, then submit a new request if appropriate.
supersededYou submitted a newer request for the same item before this one was decided, so this one was retired.
cancelledYou withdrew it.

One open request per item​

An item only ever has one open (pending or approved) change request, and a new submission is treated as your latest word on the item:

  • Submitting again for the same product or variant supersedes its pending request. You do not need to cancel first.
  • A product-level submission also supersedes any pending requests on that product's variants, because an edit of the product carries its variants.
  • A variant submission does not supersede a pending product-level request. It is refused until you cancel or replace the product request, so that unrelated product edits you still want reviewed are not lost.
  • While a request is approved but not yet applied, new submissions for the item are refused until the client retries or rejects it, or you cancel it.

Using the API​

Everything above is available through the Supplier API, and the Store Scope reference lists every field and response.

  • Create with POST /api/suppliers/products and a store_id. The store must be one you are connected to. Every price in the payload must carry the same store_id.
  • Update and delete with the normal product and variant endpoints. Each accepts an optional reason, which is required on a delete.
  • When the item is store-scoped the response is 202 Accepted with change_request_pending: true, the change request that was recorded, and a message, instead of the saved item. A request that cannot be recorded, because the item has an approved request awaiting apply or a variant write conflicts with a pending product-level request, fails with 422 and an error on item.
  • The sub-resource endpoints for URLs, codes, properties, stock, options, translations and category attachment refuse write verbs on a store-scoped item with 422 and the message This item is store-scoped and can only be changed through an item change request.
  • GET /api/suppliers/products returns store_id and under_review on every row, and accepts store_scoped=1 or store_scoped=0 to filter by scope.
  • List, show and cancel requests with GET /api/suppliers/item-change-requests, GET /api/suppliers/item-change-requests/{uuid} and POST /api/suppliers/item-change-requests/{uuid}/cancel.
POST /api/suppliers/products
JSON
{
"product_identifier": "KIT-ACME-001",
"store_id": 42,
"type": "simple",
"name": "Acme calibration kit",
"brand": "Acme",
"manufacturer": "Acme",
"sku": "KIT-ACME-001",
"unit_size": "1",
"unit_label": "EA",
"codes": [
{ "code": "KIT-ACME-001", "type": "mpn" },
{ "code": "41110000", "type": "unspsc", "version": "26" }
],
"prices": [
{ "price": 199.0, "country": "GB", "currency": "GBP", "store_id": 42 }
]
}
202 Accepted
JSON
{
"change_request_pending": true,
"change_request": {
"uuid": "9c1f4a2e-6b7d-4d3a-9e1f-0a2b3c4d5e6f",
"item_type": "product",
"item_id": null,
"store_id": 42,
"command": "create",
"status": "pending",
"item_label": "Product KIT-ACME-001",
"submitted_at": "2026-09-20T09:14:02+00:00"
},
"message": "This item is store-scoped: the change has been submitted for client review and will be applied once the client approves it."
}

Frequently asked questions​

Can I make an existing global product store-scoped? No. Scope is set when the product is created and cannot be edited afterwards. Create a new store-scoped product instead.

Can one product be scoped to several stores? No. A store-scoped product belongs to exactly one store. Create one product per store if several clients need their own version.

Will the client be emailed about my request? No email is sent. The client reviews the queue under Approvals → Item Changes in their portal; if a request is urgent, tell them directly.

Does a rejected request block the item? No. The item keeps its currently approved data and remains orderable. Correct the change and submit again.

Why can't I edit the codes or stock card? Those editors save straight to the item, which a store-scoped item does not allow. Use Edit on the Details card; the fields you change there become one change request.