> ## Documentation Index > Fetch the complete documentation index at: https://docs.merchantops.ai/llms.txt > Use this file to discover all available pages before exploring further. # Exporting products > Pull products out of MerchantOps: pick your own columns, or take a round-trip file you can edit and re-import. There are two reasons to export a product catalog, and MerchantOps has a separate tool for each: building a file **for someone else** with exactly the columns they asked for, and taking a file **out and back in** so you can bulk-edit in a spreadsheet. This page covers both, and when to use which. Both live on the **Products** page under **Export Products**, and both require read access to products. For prices rather than product data, see [pricing export](/pricing/export). | | **Export Builder** | **Round-trip export** | | ------------- | ------------------------------------------------- | --------------------------------------------------------- | | What it's for | A file shaped for a person or a downstream system | Editing your catalog in a spreadsheet and re-importing it | | Columns | You choose, rename, and order them | Fixed layout, so the importer can read it back | | Variants | Not included | Included by default, as their own rows | | Formats | Excel or CSV | Excel or JSON in the dashboard | | Re-importable | No | Yes — that's the point | ## Export Builder Select the products you want, choose **Export Builder (choose columns)…**, and build the file column by column. You get a palette of fields to drag into the column layout, where you can reorder them and rename each column header to whatever the recipient expects. The palette is built from your data, not a fixed list: The product's key, source, product type, version, labels, published flag, and status. Every [property](/catalog/product-types-properties) defined on the product types in your selection. Select products of one type and you get that type's properties; select a mix and you get the union. You can also narrow what gets exported: to the **latest version** of each product only, to products carrying particular [labels](/catalog/display-groups-labels), or to particular [sources](/catalog/products-variants). Exporting the latest version only is a **filter you can turn off**, and turning it off means every [version](/catalog/versioning) of every selected product lands in the file — usually several rows per product. The dialog has it on by default; if you drive the export from the API instead, it is off by default and you have to ask for it. Check the row count against the product count before you send the file anywhere. ### Save a column layout as a template Once you have a layout you'll want again — a recurring feed with a fixed set of columns, for example — save it as an **export template**. Loading a template restores the columns, their headers, and the filters, so a monthly export is a two-click job rather than a rebuild. ### File shape and format The builder writes **one row per product, one column per field you mapped** — the shape a downstream system with a fixed header row expects. Choose `.xlsx` or `.csv` for the output. A second shape, **one row per property value**, exists on the export API for callers whose products have very different property sets. It isn't offered in the dialog, which always writes the column-based shape. Large selections don't download in the browser. Above a size threshold (500 products by default, configurable per environment) the export is dispatched as a background [Job](/jobs/overview) instead, and you download the finished file from the Jobs page when it completes. ## Round-trip export The round-trip export exists for one workflow: **export → edit in a spreadsheet → re-import**. Its layout is fixed because the importer has to be able to read it back. Under **Export Products** you get: * **Standard Excel .xlsx (re-importable)** — the spreadsheet path. * **Standard JSON (re-importable)** — exactly the shape the JSON import accepts, for scripted edits. * an **Include variants** toggle that applies to both. Round-trip exports always take the **latest version** of each product; there is no version filter to get wrong. ### Variant rows With variants included, the file is one row per product followed by one row per [variant](/catalog/products-variants). Each row carries a `row_type` of `product` or `variant`, and a variant row names its parent with `parent_key`. That is the same layout the Excel importer expects — see [variant rows](/data-ingestion/uploading-products#variant-rows-excel-only). ### Prefer XLSX for barcodes **Choose Excel, not CSV, if your data contains UPCs, EANs, or long numeric SKUs.** The `.xlsx` round-trip export writes every cell as text, so a 12-digit barcode survives a trip through a spreadsheet exactly as stored. A CSV has no such protection: opening it in a spreadsheet application can silently convert a long barcode to scientific notation or strip a leading zero, and re-importing that file writes the mangled value back. A round-trip **CSV** exists on the API for callers that want one, but it is not offered in the dashboard menu, precisely because of the barcode problem. ### Re-importing your edits Edit the file, then bring it back through **Import Products (Excel)** on the Products page — and leave **Merge only provided columns** ticked. That overlays just the columns you kept onto each product's latest version rather than replacing the whole record, which is what makes it safe to export a narrow file, fix one column, and put it back. The full rules are in [uploading products](/data-ingestion/uploading-products#re-importing-to-update-existing-products). The round-trip exports are synchronous only. A selection above the background-job threshold is rejected rather than queued, so split a very large catalog into several exports. The other half of the round trip: re-importing an edited export. What the rows in your export represent. Why "latest version only" matters when you export. Where a large background export is tracked and downloaded.