#Imports and exports

For anyone moving data in or out as CSV. This page covers the screens and how a job behaves; the column-by-column format for each kind of record is on its own page, linked below.

#Starting an import

Every list screen that can be imported into has an Import button: products, customers, orders, reviews, wishlists, loyalty members and loyalty activity. Pick your file, pick the format if you are uploading a competitor's export unchanged, and start.

The job runs in the background. You can leave the page.

#Watching a job

Settings → Imports lists every job with its type, status, progress and total rows.

Open a job for the detail: the file it ran on, and every row that had a problem with the row number and the reason. Both the list and an open job update themselves while the job is still running, so you can leave the page up and watch it finish.

#What an import wrote

A finished job also lists the records it wrote, under Records on the job's detail page. It says how many were created and how many were updated, and each row names the file row it came from and links through to the record.

Only the resource the import type names is listed. An orders import lists its orders, not the order items or the customers underneath them.

A record deleted since the import keeps its place in the list and reads as "Deleted record", so the history of what a migration did stays readable even after a cleanup.

Over the API this is GET /import-jobs/{id}/records, which is paginated and can be filtered on the action or the resource. The reverse lookup is an include on the record itself: ask for include=importJob on a customer, product, order, review, wishlist or loyalty membership and you get back the import that last wrote it, along with its file row.

Imports are kept for a while and then cleared out, along with their source file and their record links. How long is set by your plan: see Plans and limits. The records themselves are never touched by that cleanup.

#Bad rows do not stop the job

This is the most important thing to know about importing into Cascade. A row that cannot be read, or that references something Cascade does not have, is skipped and reported rather than failing the file. The rest of the file lands.

So a completed job with 300 problems is a real outcome, not a failure: 300 rows need looking at and the rest are in. Read the problems list before deciding the import worked.

Whole-file failures are different, and are what "Failed" means: a file that is not CSV, a header row nothing recognizes, a file bigger than your plan allows.

#Imports are re-runnable

Every importer matches on a natural key rather than creating blindly: a product by slug, a customer by email, an order by your own ID, a review by its external ID. Importing the same file twice updates the same records rather than doubling them.

That is what makes a half-finished migration safe: fix the rows that were reported, re-upload the same file, and only the fixed rows change.

The other side of it is that every column you send overwrites what is stored. Import a file with an empty notes column and you have cleared the notes. Export first, edit that, re-import.

#Order matters

Records reference each other, so import in this order:

1. Products, which orders and reviews point at.
2. Customers, which orders, reviews and wishlists point at.
3. Orders.
4. Everything else: reviews, wishlists, loyalty.

An order naming a product that has not been imported yet is a skipped row, not a broken job. If you see hundreds of unresolved references, this order is usually why.

#Exports

Export from the same list screens, and the export honors the filter you have on. Narrow the list to what you want, then export, rather than exporting everything and cutting it down in a spreadsheet.

Settings → Exports lists the jobs. A completed export has a download link. An export whose list matched nothing still completes, with 0 rows and an empty file. An export that could not be finished is marked Failed rather than sitting on Processing, so you can start it again.

An export's detail also records what it covered: the search box's term and the filter that was on the list when you started it. Two exports of the same type that returned different numbers are told apart there.

Exports and imports round-trip: what comes out of a review export can go back into a review import onto the same records rather than duplicating them, which is what makes "export, edit in a spreadsheet, re-import" a safe way to bulk-edit.

#Limits

Jobs per day and rows per job are set by your plan. See Plans and limits. A file over the row limit fails as a whole file, so split it rather than trimming it.

#Over the API

Both are API endpoints, so a recurring export or a nightly import can be automated. See Import jobs and Export jobs.

If you are syncing continuously rather than migrating once, use the import endpoints on each resource instead. They take JSON, upsert on the same natural keys, and do not need a file. See Custom integration.