No seller owns a product. There is no owner column. Creating a product adds a candidate to the shared catalog. The creator gets attribution, so their unpublished submissions appear in their own list, but no rights over the record after publication. What looks like ownership elsewhere is split into three things: selling eligibility, creator attribution, and the status lifecycle. See Products.
What you’ll build
You end with a published master product carrying offers from two sellers at different prices. Both offers are visible side by side through the Store API, each with its own calculated price.Product vs offer
Three concerns live in three places. Keep them separate as you build.Build the buy box
1
Publish a master product
As Seller A, create a product in the Vendor Portal, such as “Classic White T-Shirt” with a size variant. It enters as
proposed. As the operator, confirm it in the Admin Panel so it becomes published. The review flow is covered by the Product Edit module.The published product now belongs to the shared catalog. Note what it does not have: a seller price or seller stock.2
Create Seller A's offer
In Seller A’s Vendor Portal, create an offer against the product’s variant. Give it their own SKU, a price of $25, stock of 100, and one of their shipping profiles.
3
List the same product as Seller B
As Seller B, find the same published product in the catalog and create a competing offer on the same variant: a different SKU, $23, stock of 40. The
(seller_id, sku) pair is unique per seller, so both sellers can use whatever SKU scheme they like.Nothing about the master product changed. Two commercial listings now point at one catalog entry.4
Read the buy box from the Store API
The Store API exposes offers directly, each with its own calculated price. Fetch them by product id:Offers share the variant’s price set scoped by an offer rule. Each offer carries its own prices without duplicating the variant, and the storefront computes a
Terminal
calculated_price per offer. A buy-box storefront fetches the product once, then renders every seller’s offer against it.5
Check out against an offer
Add Seller B’s offer to a cart and place the order. The cart line item links to the specific offer purchased, and that link is preserved onto the order line item. Fulfillment, commission calculation, and payouts all resolve to Seller B, even though both sellers list the same variant.
Verify
Confirm the buy box behaves as expected.- Both offers appear in
GET /store/offers?product_id=...with differentcalculated_pricevalues. - Each seller’s Vendor Portal shows only their own offer. The Admin Panel lists both with store, pricing, and inventory.
- After the checkout in step 5, the order lands with Seller B. Seller A’s offer and stock are untouched.
- Reducing Seller B’s offer stock does not affect Seller A’s availability. Inventory is per offer.
FAQ
How do I restrict who may sell a product?
How do I restrict who may sell a product?
The operator manages the
product_seller allowlist. A product with assignments is visible and sellable only for those sellers, while a product with no assignments is open to every seller. Eligibility limits selling. It does not limit who may propose edits to the shared record.Can two sellers use the same SKU?
Can two sellers use the same SKU?
Yes. SKU uniqueness is per seller (
seller_id + sku). Seller A and Seller B can both use TSHIRT-WHITE-M. A single seller cannot list the same SKU twice.Who fulfills, refunds, and gets paid when several sellers list the same variant?
Who fulfills, refunds, and gets paid when several sellers list the same variant?
Always the seller whose offer was purchased. The offer link travels from cart line to order line, so fulfillment, returns, commission, and payout all resolve through it. The variant alone is never enough to identify the seller.
Next steps
Offers
The offer data model, relationships, and checkout links.
Order Groups
What happens when a cart spans both sellers: the multi-vendor split.