Half a million SKUs, and not a spreadsheet in sight.
Catalogs, variant families, bulk CSV in and out, and a full history on every product. The plumbing that decides whether a catalog is workable or merely stored.
The spreadsheet is the actual system of record. Everyone knows it.
There is a file. It has forty tabs, one person understands the formulas, and it is the only place where the relationship between a parent product and its variants is written down.
Every bulk change is a filter, a copy, a paste, and a re-upload — and every re-upload is a chance to overwrite something quietly.
None of this is a modelling problem. It is a tooling problem, and it is the reason catalog work feels more dangerous than it should.
Two ways to organise a catalog
Catalogs
Variant families
Getting thousands of rows in and out
The CSV path is deliberately first-class. Most catalogs will live in two systems for years, and the file is how they talk.
- Import products
- CSV with sku, name, manufacturer, mpn, and brand. Duplicates are skipped rather than merged badly.
- Update in place
- A second CSV that edits existing products — core fields, parent-child relationships, data sources, and configured enrichment attributes, all in one file.
- Matching order
- Internal ID first, then external ID, then SKU. Use an internal ID when the row needs to change the SKU itself.
- Export data
- Export jobs produce CSV of the attributes you select, for the products you select.
- Export images
- Image export jobs bundle sourced and generated product imagery for bulk download.
Bulk changes you can look back at
Product history
Job history
Review before commit
Questions
How do we change a SKU without losing the product?
What is a catalog, exactly?
How do variants work?
Can two people work in the same catalog?
Is there a limit on products?
Bring in a thousand products and see how it holds.
CSV import is free — credits are only spent when an agent runs. Loading the catalog costs nothing.
5 credits on signup · no card required