The seller catalogue

The problem#

A marketplace catalogue looks like a store catalogue with an extra seller field. The difference runs deeper: a product has an owner who is not the operator, it may exist in parallel in somebody else system, and it goes through moderation before becoming visible.

Each of those three is simple on its own. Together they decide whether you can connect a seller shop a year from now without rewriting the catalogue.

Minimum version#

• A product belongs to a seller and cannot exist without that relationship.
• A product has a state: draft, awaiting approval, published, withdrawn.
• Variants are separate records, even when a product has one variant today.
• The category decides which information is required before publication.

What not to build yet#

• A canonical catalogue where listings from many sellers attach to one shared product. That is a product in its own right and only makes sense once duplicates are a real problem.
• Barcode matching and global deduplication.
• A form generator with dozens of technical fields. Require what blocks publication and leave the rest optional.
• Versioning every product edit. Price history yes, full edit history only once there is a dispute.

Plan ahead#

Three identifiers instead of one#

If there is even a plan to connect seller shops, a product needs room for three things at once: your own identifier, which source system it came from, and the identifier in that system. Putting all of it in one general-purpose field works until the same seller connects a second shop.

The same applies to the variant. Mapping at product level is not enough, because stock synchronisation happens on the variant.

Source of truth as a decision, not a side effect#

For every field that can arrive from outside, it must be settled who wins: the platform or the source system. Usually price and description stay with the platform and stock stays with the source. What matters is that this is recorded in the model rather than emerging from the order of writes.

Compliance data as fields, not prose#

Information required by regulation should be fields you can filter on and check for completeness. Pasted into a description it cannot be enforced, and it is exactly what blocks publication.

Triggers#

• the first seller asks whether they can pull products from their own shop;
• the same product shows up under two sellers and a buyer notices;
• the first category with documentation requirements;
• product moderation starts taking more time than approving sellers;
• a seller asks for a bulk change to prices or stock.

Next stage#

After the first trigger: identifier mapping and a one-off import. After the second: only then a conversation about a shared catalogue, and more likely as listing groups than full canonicalisation. After the fifth: bulk file import, before you build anything real time.

Common mistakes#

What works in practice#

The most later work was saved by separating the platform variant identifier from the identifier in the source system. When a second integration arrived, the mapping was already at the right level and nothing had to be reconstructed.

The opposite happened with deferring the decision about which information should hard-block publication. While missing data was only a warning, incomplete listings reached buyers and came back as work to redo on a catalogue that already existed.

Checklist#

• A product cannot exist without a seller.
• Variants are separate records from day one.
• Product and variant have room for an external identifier along with its source system.
• For every field arriving from outside, the source of truth is settled.
• Information required by regulation is stored as fields, not inside a description.
• A missing required field blocks publication.