For BigCommerce merchants and agencies
Move nine kinds of store data in and out as CSV or Excel — or skip the spreadsheet and change prices, swatch colours, image order, variants and metafields across hundreds of products straight from the browser. Either way, you read the whole run first.
No card. The free plan is a working plan, not a countdown.
Row 2 would update SKU SLCTBS price 49.00 → 53.90 Row 3 would create SKU TWL-CHM-02 under Home / Linens Row 4 would update variant 4231 stock 12 → 40 Row 5 would delete image 265 (Image ID matched) Row 6 will fail "Vintage Mug" matches 3 products — name is not unique, so nothing is guessed
BigCommerce has no undo. One wrong column on 4,000 rows is a weekend of manual repair.
A separate checker guesses at your columns. It can pass a file the real import then chokes on.
Same code, writes recorded instead of executed. If the preview is clean, the run is the same run.
Most tools validate your file. Ottermerce runs it — the same mapper, the same product lookup, the same errors — and records what it would have written instead of writing it.
0 writes sent · full per-row report
same rows · same failures · same report
The branch is the last step, not the first. That is the whole trick, and it is why row 6 fails identically in both — a preview and a run are the same event with one switch flipped at the end.
file spring-catalog.xlsx 2.4 MB rows 1,284 items 412 products recognised 38 columns unknown "Modifer Name" did you mean "Modifier Name"? token can reach Products, Categories, Brands plan 412 of 25,000 items — within Growth
Every export is written with the exact column names the importer reads, so a file that comes out can be edited in Excel and put straight back in. Round trips were tested against a live store until the counts came back identical.
Pass-through fields, custom fields, metafields, images, videos, bulk pricing tiers, modifiers.
A name matching three products fails the row and lists their ids rather than editing one.
Options and swatches, per-variant SKU, price, stock, identifiers and metafields.
Two variants given the same SKU stop the whole apply, before anything is written.
Full paths, renames, moves, metafields. Parents are created before their children.
BigCommerce deletes a category's whole subtree with it, so a delete is refused unless Cascade says otherwise.
Parent by name rather than raw id, so a file works in a second store too.
A page is never re-created to change it — that would issue a new URL and break every link.
Bodies, tags and publish dates, with the date format BigCommerce actually accepts.
Titles are not unique: a row identified only by title fails and names the matches.
URL and entity redirects, written as one batch per file.
Upsert on From Path, so re-running a file cannot leave duplicates behind.
SEO title, meta, search keywords, image and URL. Created on demand when a product names one.
Deleting a brand leaves its products alone rather than taking them with it.
Several addresses per customer, groups by name, custom attributes.
Force Password Reset is the one column that mails anyone, and an export never writes it.
Category access and discount rules, with amounts trimmed so a round trip does not drift.
Access set to specific with no category ids fails, rather than hiding every category.
Filter your catalog, pick an operation, preview it, apply it. Adjust prices by a percentage, set a brand, add or remove categories, add or delete metafields and custom fields.
A bulk edit is an import.
Same pipeline · same preview · same history
It generates the file and runs it through the same pipeline, so you get the same per-row results — and the generated file is kept as the audit trail.
SKU, price, sale and cost price, stock, weight, UPC and MPN, purchasing state — across every variant of a product at once.
Clearing a field is refused rather than quietly ignored, because a blank cell means "leave alone" everywhere else.
Drag to reorder, promote any image to the thumbnail, matched by BigCommerce's own image id rather than by filename.
Leaving an image out of the list is refused — positions are absolute, so the omitted one would collide with whatever took its place.
Switch an option between dropdown, radio, rectangles and swatch, and set the colour chip for every value.
A swatch needs a colour for every value or BigCommerce rejects the lot, so a missing one is named before the request is sent.
Add, rename, retype and remove them, one product at a time or across everything a filter matches.
If the store has gained a field your page never displayed, the whole change stops and names it.
Limits are per import and per day. A dry run never counts against them — finding out a file is too big should not cost you the day's quota.
| Plan | FreeEvaluate | StarterOne store | GrowthMost stores | ScaleAgencies |
|---|---|---|---|---|
| Per month | $0 | $39/mo | $59/mo | $99/mo |
| Items per import | 100 | 5,000 | 25,000 | 200,000 |
| File size | 5 MB | 25 MB | 100 MB | 500 MB |
| Imports per day | 3 | 15 | 50 | Unlimited |
| Exports | All types | All types | All types | All types |
| Queue | Low | Standard | Standard | Priority |
| Start free | Choose Starter | Choose Growth | Choose Scale |
An item is a product, not a row — a product with twenty variants counts once. Prices exclude any tax that applies where you are.
No. BigCommerce stays the source of truth. Ottermerce holds your import files, the results of each run and your store credentials — nothing else.
Paste a store hash and an API token in Settings, or install the app from your BigCommerce control panel. Either way the app behaves identically.
That row fails and the rest continue. Every row gets a result you can read on screen or download as a CSV annotated with the original line numbers.
No — and no tool honestly can, because BigCommerce has no undo. That is exactly why the dry run exists and why it takes the real code path.
Only if you fill in the Force Password Reset column, which is the one field that makes BigCommerce send mail. Exports never write it, so a round trip cannot trigger it by accident.
Four scopes, and no more: Products (which also covers categories and brands), Customers (customers and groups), Content (pages and blog posts) and Sites & Routes (redirects). Nothing touches orders, carts, checkout or payments.
One store per account today. An agency running several stores needs an account per store — say so when you write in and we will sort it out rather than leave you paying four times.
No. Every run is started by a person looking at a preview, which is deliberate: an unattended import is one nobody read the dry run for. If you want a nightly sync from a feed URL, tell us what you are syncing — it is a different product and worth building properly.
Not today — BigCommerce only. The file format and the whole preview pipeline are platform-neutral by design, so another platform is a new set of API clients rather than a rewrite, but nothing is claimed until it is tested against a real store.
Rows already written stay written — there is no rollback, because BigCommerce offers none. The results record exactly which rows completed, so you can cut the file down to what is left and run the remainder. This is the other reason to read a dry run first.
The ceiling is BigCommerce's API rather than us: an import is thousands of individual calls and they are rate limited at their end. Work runs across four parallel workers, and a product with twenty variants costs far more calls than twenty simple products — so row count alone does not predict it.
No. The free plan does not expire, and paid plans are monthly.
Upload it, run a dry run, read every row. Nothing is written until you say so.
