Supplier Product Setup: Variants, the Three Fulfilment Types, and the Warranty Field That Blocks Your Listing

Three things about this form surprise nearly every new supplier, and all three are enforced by the server rather than suggested by the interface.

• A product has no price. Price lives on variants, and the price a buyer sees is the cheapest active variant.
• You cannot save a product with zero variants. One is the minimum, and it needs a name, a price and a stock number.
• Leaving the warranty field empty does not give you a default week. It gives you a rejected submission.

Everything else follows from those. What follows is the form in the order the server validates it.

Simple Mode or Advance Mode, and what the choice costs you

From your product list, Add New opens the create form at /supplier/products/add. It starts in Simple Mode and there is a toggle to Advance Mode.

Simple Mode shows seven fields: category, subcategory, product name, unit price, base stock, an accounts box, and an image. It is quick, and it makes two decisions for you. It forces the fulfilment type to inventory, and it creates a single variant behind the scenes. If pre-uploaded stock is what you sell, that is the correct shape and you are done.

Advance Mode is the rest of the form: fulfilment type, provider, full description, warranty, the variant editor, checkout options, FAQs and SEO. It also requires the description to be translated to English before it will submit. Anything that is not straightforward inventory needs this mode.

Where price actually lives

There is no price field on a product, in the form or in the data. What you set is the price of each variant, and the figure that appears on the storefront is the cheapest active one. This matters in a way that catches people out: deactivate your dearest variant and nothing visible changes, deactivate your cheapest and the whole listing appears to jump in price.

The variant editor sits under Product Variants (Subproducts) and its button is Add Subproduct Variant. The fields, with the labels the form actually uses:

• Variant Name, optional. Left empty it falls back to the source name.
• Price, required, and the only place a price exists.
• Minimum Purchase Quantity, defaulting to 1. This is a floor on the order, not a stock figure.
• Stock, shown for manual and auto types, where it is a number you maintain.
• Base Stock, shown for inventory only, where it is added to real stock for display.
• Short Description, optional, shown to buyers choosing between variants.

There is no field called "Min Base". If you were looking for one, you probably wanted Minimum Purchase Quantity or Base Stock, and they do opposite things.

Use variants when the same goods come in bands that price differently: registration year, region, whether a mailbox is included. Think in multiples of your own cheapest row rather than in figures, because the cheapest row is what buyers see first and everything above it reads as a premium against it. One caution from the shelf data: an age premium is not a market-wide constant here. Split by seller, some sellers charge several times their own baseline for a stated registration year and others charge less than their own baseline for the same claim, so the multiple you can hold is yours to establish rather than one to copy from the shelf.

Three fulfilment types, and one of them is invisible to most suppliers

The Product Type selector in Advance Mode is the decision the rest of the listing hangs on. Its three options, with the platform's own descriptions:

• Inventory, "Auto-fulfill from uploaded accounts". You upload credentials in advance, stock is whatever is unsold, and orders fill themselves with no involvement from you.
• Manual, "Manually upload accounts after order". Stock is a number you set. An order waits in processing until you deliver, by hand or through the API.
• Auto, "Managed via auto API". Stock and delivery both come from an external integration.

The auto option is not merely disabled for most accounts, it is not rendered at all. It appears only for admins and for suppliers carrying the trusted flag, and choosing it adds a required Source URL field.

For scale: across all 34,729 product records on the site, auto accounts for 29,707, inventory for 3,236 and manual for 1,786. The two types most guides describe are the two smallest.

The warranty field will refuse your listing, and the empty box is the trap

This is the single most common reason a create fails for a new supplier, and the reason is counter-intuitive.

The field is labelled Warranty (Hours). Leave it blank and the platform does not fall back to a generous default. It falls back first to your shop's own default warranty if you set one, and failing that to a site fallback measured in fractions of an hour. Then a second check runs: any supplier without the trusted flag must meet the site's minimum listing warranty, currently four hours, or the submission is rejected with a warranty-below-minimum error.

So the blank box produces a value far under the floor, and the floor rejects it. Type a number. Four hours is the current minimum, twelve hours is the median across every live listing on the site, and a week and above is rare outside proxies.

The same rule applies retroactively. If the floor is raised, live listings underneath it are soft-delisted rather than deleted: they stay in your catalogue with the active flag cleared, and raising the warranty brings them back. If your listings quietly stopped appearing, this is the first thing to check.

What happens when you press Publish

The two buttons are Publish Product and Save Draft. On publish, the server runs a sequence you cannot see:

1. Subscription check. Creating products requires an active supplier subscription.
2. Variant validation. At least one, each with a name, a numeric price and a numeric stock. Manual variants also have a per-variant stock ceiling.
3. Type permission. Manual and inventory for everyone, auto only if you are trusted.
4. Listing cap. A base allowance plus an increment per supplier level, plus any bonus slots you have earned. Trusted suppliers are uncapped, and growth services never count against this at all.
5. Warranty floor. As above.
6. Approval. A site-wide auto-approve switch is checked first, then your own auto-approve flag, and otherwise the product lands as pending. That site-wide switch is currently on, so most new listings go straight to approved. Do not build a process on that; it is a setting and it can be turned off.

A pending product is also an inactive one, so it will not appear anywhere until it is approved. If you uploaded inventory as part of the create, that upload runs as a background job rather than inline, so stock may take a moment to appear even on a successful save.

Two fields you cannot set, and one you can but nobody has

Buyers sometimes ask suppliers to switch a listing to manual delivery, or to deliver by file rather than by list. Neither is available.

Delivery type is not on the form. It exists in the data model with instant and manual as its two values, but there is no input for it anywhere in the supplier interface, and every one of the 34,729 product records on the site is set to instant. Manual delivery, as a buyer-facing promise, does not exist here.

Account format does have a control, the List and File radio pair under Upload Inventory, but every product record on the site is stored as list. The file path is available and, on the current evidence, unused.

Managing stock after launch

For an inventory product, stock is derived rather than declared. It is the count of rows sitting in the unsold state, so uploading raises it and selling lowers it, and there is nothing to keep in sync by hand. Paste credentials one per line, or upload a text file with one per line. A common convention is to separate the mailbox, the password and any two-factor secret with pipes, but nothing on the platform parses the line: it is stored verbatim, and whatever your listing description promises is what the buyer will expect to find in it.

The inventory model declares five states, but only three of them ever appear. Across 3.58 million rows the counts are sold 2,444,661, available 1,137,180 and reserved 22, the last covering rows held for an order in flight. Disabled and replaced are declared, and can be filtered on, but neither has a single row and nothing in the codebase writes either one. So when a replacement is issued under an after-sales ticket, and more than six thousand tickets have resolved that way, it does not leave a marked row behind. Count your stock on the three states you will actually see.

Base Stock is a display number added on top of real stock, so a base of a thousand on top of fifty real rows shows fifteen hundred and fifty. Only the fifty are actually purchasable. It is a bulk-buyer signal, not inventory, and overstating it converts into failed carts rather than orders.

For a manual product, stock is a number you type, and it drops as orders come in. It is a promise rather than a measurement, so it needs your attention in a way an inventory count does not.

One counting caveat if you use variant sales figures to decide what to restock: the per-variant sold counter only ever goes up. It is never decremented for a refund or a replacement, so it is a lifetime gross figure and not a net one.

Which type to pick, on the evidence

The honest comparison is not the one usually drawn, because the two live types differ far less on speed than the labels suggest.

Question	Inventory	Manual	Auto
Where stock comes from	Counted from unsold rows	A number you type	An external integration
Who delivers	Nobody, it is automatic	You, after the order	Your API integration
Who can select it	Any supplier	Any supplier	Trusted suppliers and admins
Completed orders on the site	28,708	6,552	48,070
Typical time to completion	Under a second	Under thirty seconds	Under a minute
Slowest tenth	Effectively none	Around nine hours	Around nine minutes

That manual median of under thirty seconds is not a typo and it is not the platform being fast on your behalf. It is what happens when the suppliers doing volume on manual listings poll the order API on a short interval rather than watching a dashboard. The tail is where the difference lives: about one manual order in forty takes more than a day, against effectively none on inventory.

So pick manual when the goods genuinely have to be produced per order, and pair it with the API from day one. Pick inventory when you can prepare stock in advance, which is most of the time and is also the only type Simple Mode will give you.

The short version

1. Advance Mode unless you are selling straightforward pre-uploaded stock.
2. At least one variant, with a price, because the product itself has none.
3. Type the warranty in hours. Blank is a rejection, not a default.
4. Inventory if you can prepare ahead, manual if you cannot, and wire the API in the same week if you choose manual.
5. Base Stock is a display number. Sold counts never go down. Replaced rows are neither sales nor stock.

Once listings are live, order processing through the API is covered in the manual orders API guide, the approval queue in the product approval guide, and what the tiers change in the seller levels guide.