For BigCommerce merchants and agencies
Move twelve kinds of store data in and out as CSV or Excel — or skip the spreadsheet and edit prices, stock, SKUs and metafields from the browser: a filtered bulk edit across thousands, or a grid you fill in a page at a time. Either way, you read the run first.
No card. The free plan is a working plan, not a countdown.
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.
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 plan 412 of 25,000 items — within Growth
Every export is written with the column names the importer reads, so a file that comes out can be edited in Excel and put straight back in. Each type has its own safety rule — open one to read it.
Fields, custom fields, metafields, images, videos, bulk pricing tiers and 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. They ride inside the product file rather than a file of their own.
Two variants given the same SKU stop the whole apply, before anything is written.
Full paths, renames, moves and 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 to it.
Bodies, tags and publish dates, in the date format BigCommerce actually accepts.
Titles are not unique, so a title matching more than one post fails and names them rather than editing whichever came first.
URL and entity redirects, upserted in batches rather than one call per row.
Upsert on From Path, so re-running a file cannot leave duplicates behind.
SEO title, meta, keywords, image and URL. Created on demand when a product names one.
REPLACE is refused: re-creating a brand would give it a new id and leave every product that pointed at the old one with no brand.
Several addresses per customer, groups by name, and 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. Or open one of the two grids and edit the cells directly.
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 for 30 days. The per-row results stay in History after the file itself is cleaned up.
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.
Rate card · monthly
$0
Evaluate it on a real file, for as long as you like.
$39/mo
One store, regular catalog maintenance.
$59/mo
Seasonal reprices and supplier feeds, end to end.
$99/mo
Agencies moving several stores at once.
An item is a product, not a row — a product with twenty variants counts once. Prices exclude any tax that applies where you are.
BigCommerce stays the source of truth: there is no copy of your catalog kept in sync. What Ottermerce does hold is the files you upload, the files it exports for you, the per-row result of each run, any shared metafield definitions you create, and your store credentials.
Import and export files are deleted after 30 days. An export file is a full dump of whatever you exported, so treat it as you would any download.
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.
Five: Products (which also covers categories, brands and price lists), Customers (customers and groups), Content (pages and blog posts), Sites & Routes (redirects) and Marketing (coupons and gift certificates).
The app makes no call to orders, carts, checkout or payments. Worth knowing precisely: BigCommerce grants scopes from the app listing rather than from what the code asks for, so the permissions screen at install is the authority. Read it, and tell us if it asks for more than these five.
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. Paid plans are monthly and, while the app is in early access, arranged by hand rather than through a checkout.
Upload it, run a dry run, read every row. Nothing is written until you say so.
