A Shopify catalog import acceptance checklist should prove what changed, what stayed untouched, and what still needs review. I would accept an importer only after its results reconcile with an approved plan, including held products and interrupted work. A completed upload alone does not answer those questions.
What exactly are you accepting?
Start with a bounded change: one supplier feed, a saved version of the input, and a named set of permitted operations. Separate creating products, adding variants, updating existing fields, and publishing listings. I would give each operation its own expected result so a successful creation cannot conceal an unintended update.
My reference is BC Supply Ops for BeautyCorner.gr, built around a 70,000+ product store and 7 suppliers. The importer normalizes supplier feeds and matches barcodes against the live store without Shopify writes. A reviewable new-arrival plan appears before publication.
The case study records 456 clean candidates ready to publish, 113 new variants for existing products, and 1,271 items held for review on one feed. Those are documented snapshot counts, not today's queue or a throughput target. Their separation is the useful decision: new products, new variants, and unresolved arrivals are different kinds of work.
The checklist below is my proposed acceptance process for another store. It builds on that project evidence without claiming these exact tests or report fields were used there. If the project is still being scoped, start with the inventory integration developer brief.
Which existing fields must survive the import?
Write a field ownership list before discussing batch size. For each field, specify whether the supplier may set it, staff retain control, or a separate system owns it. Record what an absent value means: preserve, clear, reject, or request review.
For example, I would use a test product with a merchant-written description and an existing variant image. A supplier update intended only to change a permitted field should leave those protected values intact. Save the before and after values so acceptance depends on evidence rather than a quick visual impression.
The import method matters. Shopify's product CSV import documentation explains that, with matching-handle overwrites enabled, a blank optional column can clear an existing value. An omitted optional column generally preserves it, but dependent columns need additional care.
For an API implementation, Shopify's productSet documentation distinguishes list fields from other fields. When a list is supplied, existing entries absent from that input are deleted; omitted non-list fields remain unchanged. I would require an explicit preservation test before allowing a supplier's partial variant list to drive that mutation.
These are different write contracts, so a generic “blank fields are ignored” promise is insufficient. Ask the developer to name the actual import method and show the behavior on controlled fixtures. Product deletion, variant removal, and publication changes should remain outside approval unless specifically included.
Can every source row be accounted for?
I would keep a row register separate from the product totals. A supplier can repeat an offer, or several source rows can contribute to the same destination product. The register should retain each source reference and point to the resolved product or variant, rather than assuming rows equal products.
Give every row one current disposition, with its earlier transitions preserved in history. Useful dispositions include unchanged, created, updated, held, intentionally excluded, failed, and awaiting reconciliation. A duplicate source row can be intentionally excluded while retaining its link to the accepted row and the reason.
| Gate | Evidence to retain | Do not accept when |
|---|---|---|
| Input and scope | Saved source, capture time, mapping version, permitted fields and targets | The executed input differs from the reviewed input |
| Identity | Source reference, matched Shopify IDs, create-or-update decision | A row could refer to more than one sellable variant |
| Field preservation | Before and after values for changed and protected fields | An unapproved field or variant changed |
| Row accounting | One disposition per source row, with destination references where resolved | A row disappears between parsing and the result report |
| Media and listing | Correct item image, readiness, intended publication destinations | A listing is released with unresolved media or scope |
| Retry and interruption | Stable destination IDs and reconciled outcomes after the repeat | Completed work becomes a second product or an uncertain write is retried blindly |
| Handover | Named reviewer, remaining holds, owner and next action for each exception | The operator cannot explain what remains unfinished |
Use the supplier barcode matching checklist to resolve identity questions before counting a row as accepted. Keep product and variant totals alongside the register, with expected changes derived from the approved plan. Any difference should lead to specific records, not an unexplained adjustment to the headline count.
What should a representative trial contain?
Choose cases by behavior rather than taking only the first rows in a file. I would include a new product, a new variant under an existing product, an unchanged item, a duplicate row, an ambiguous match, and an arrival without usable imagery. Add any supplier-specific exception the catalog team already handles manually.
For each case, write the expected outcome before execution. An ambiguous match should remain held with a reason; an unchanged item should retain its destination identity and protected fields. These are proposed acceptance fixtures, not reported production incidents or a claim that one sample proves the entire catalog is correct.
BC Supply Ops keeps imageless arrivals in a supplier-organized queue and publishes only products with a saved image. Its publishing flow associates images with the correct variants. The missing-image hold and release guide covers the operator review behind that decision.
For a new API importer, I would also require a media readiness check. Shopify's MediaStatus reference distinguishes uploaded and processing media from media ready to display, and from failed processing. A submitted image URL should therefore remain pending until the intended image can be displayed and inspected.
Shopify recommends testing a small subset in a dev store before a large merchant CSV import. I would apply the same staged review principle to a custom importer, while recording differences between test and production configuration. Validate the resulting product, variant selection, price, and intended channel visibility before widening the approved scope.
What happens when a run stops halfway through?
In BC Supply Ops, publishing is capped per run, idempotent, and resumable. Duplicate barcodes and already-published items are skipped instead of recreated. The platform also records publish hashes and sync state to support interrupted work.
For a new custom importer, I would ask for an interruption demonstration in the test environment. Stop a bounded run after some writes complete, then resume the same approved input. Check that completed items keep their Shopify IDs, unfinished items progress, and held items remain held.
Include an uncertain outcome: a write was sent, but the worker did not retain a conclusive response. The acceptance requirement is to reconcile the destination before deciding whether another creation is needed. Have the developer explain how the job finds that destination; the merchant should not need to search by a similar product title.
Run the unchanged input again after reconciliation. The expected result is no duplicate creation and no drift in protected fields. Record both the job's report and independently read destination values; a worker reporting success is only one part of the evidence.
Do not assume the same controls exist in Shopify's built-in CSV importer: Shopify says a started CSV import cannot be canceled. Choose the test procedure for the actual tool. Resuming unfinished work and reversing completed changes also need separate procedures; a rerun is not evidence of rollback.
What should the catalog owner sign off?
I would close the trial with the approved input, field rules, row register, destination checks, and interruption results together. Give each unresolved item an owner and a next action. A deliberately held arrival can be an acceptable outcome, provided it is visible and prevented from accidental release.
Approve only the next defined scope: the supplier, input version, permitted fields, and batch boundary. If the source or mapping changes, review the affected expectations again. Keep a record of who accepted the evidence and what would stop further processing.
Start by choosing one supplier import your team finds difficult to verify. Fill the acceptance table with actual examples, especially protected fields, held products, and retry behavior. Bring that scope to my Shopify supplier automation enquiry page, or book a call to define an inspectable first milestone.