Platform · Catalog management

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 situation

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.

Structure

Two ways to organise a catalog

Catalogs

Collections that cut across the taxonomy. A supplier's whole range, this season's additions, one client's products, or the batch you are migrating this week. Jobs can target a catalog directly.

Variant families

Parent-child products with aggregation. The parent carries what the family shares — brand, description, specification — and each child carries only what makes it different. Enrich once, inherit down.
Bulk operations

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.
Safety

Bulk changes you can look back at

Product history

Every enrichment and validation run is kept against the product, so you can see which job wrote which value and when.

Job history

Each run stores its inputs, model tier, cost, and results. A surprising change has a paper trail.

Review before commit

AI Import writes nothing until you approve it, so the riskiest path into the catalog is also the one with a checkpoint.
Catalog management

Questions

How do we change a SKU without losing the product?
Match the row on internal ID or external ID rather than SKU. The identifier you match on is the one you cannot change in that file — everything else is fair game.
What is a catalog, exactly?
A collection of products. Group by supplier, brand, season, client, or project, and target jobs at one collection instead of hand-picking rows every time.
How do variants work?
A parent product holds what the family shares; children hold what differs. Enrichment on the parent aggregates to the family, so you run one job rather than forty near-identical ones.
Can two people work in the same catalog?
Yes. Members share the organization, its products, and its credit balance. Seats are free.
Is there a limit on products?
No product cap. Credits are consumed by jobs, not by storage — a large dormant catalog costs nothing to keep.

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