Skip to main content
Uploading a CSV is the fastest way to bring many products into MerchantOps at once — a spreadsheet export from your PIM, ERP, or another catalog becomes a batch of products. This page explains how columns map to product fields, how the import runs, and how to track it. For one-off additions, use the dashboard; for continuous feeds, see import connectors.
If your data lives in a spreadsheet, export it to CSV first. Pipe-delimited cells let a single column carry multiple values.

​
The file

Your CSV needs a header row. A few columns are required; the rest are up to you.
ColumnRequiredMaps to
keyYesThe product’s stable key
nameYesThe product’s display name
productTypeYes, unless a default is chosenThe product type it validates against
sourceNoProvenance of the row (defaults to merchant input)
isPublishedNoWhether the product is marked published
anything elseNoA product attribute
A single upload accepts up to 250 rows.

​
How columns map

MerchantOps maps your columns automatically — there is no mapping dialog to fill in on this path.
1

System columns map to product fields

key, productType, source, and isPublished set the product’s core fields. Common headers are recognized case-insensitively and in a few spellings — for example Product Type, product_type, and productType all resolve to the product type.
2

Every other column becomes an attribute

Any column that isn’t a system column is stored as a product-level attribute, keyed by the column name — brand, description, color, material, and so on.
3

Pipe-delimited cells become multi-value

A cell like Red|Blue is split into a list of values. Use this for any attribute that holds more than one value.
Brands that are new to the CSV are registered automatically as you import, so you don’t have to create each brand up front.

​
How the import runs

The upload creates a Job and processes rows in batches.
1

Rows are validated

Rows referencing a product type that doesn’t exist in your organization are rejected and reported individually — with a “did you mean?” hint when a close match exists. The remaining valid rows still import.
2

Products are created

Each valid row becomes a product, validated and initialized against its product type. Attribute values are coerced to the type each property definition expects (for example, TRUE/Yes/1 becomes a real boolean).
3

Enrichment runs if you asked for it

If you enable enrichment options on the upload, each new product is queued for enrichment — Lakehouse search, brand-site scraping, or content generation — tracked under the same Job.

​
Tracking the import

The upload returns a Job ID. The Job reports totals for created, failed, and — where applicable — skipped rows, and carries a per-row error list (row number, product key, and reason) so you can fix a source file and re-upload just what failed.
Rows are reported by their position in the file, counting the header as row 1. When you correct errors, match the row numbers in the Job’s error list against your original CSV.

​
Display groups on property imports

Products validate against property definitions, which are organized into display groups. When you import property definitions by CSV, any display group named in that file that doesn’t yet exist is created for you. (This applies to the property-definition import, not to the product CSV described above.)

Import connectors

Automate recurring imports instead of uploading by hand.

Jobs

Watch progress and review per-row errors.

Product types & properties

The templates and attribute schema your rows validate against.

How enrichment works

What happens when you enable enrichment on an upload.