Docs › What you can import

All import types

Five content types, one wizard. They behave the same way in most respects, and this page is about the places where they differ.

Which one do I need?

I want to create new fields on products, articles, collections…

Metafield definitions

I have a spreadsheet of values to put into fields that already exist

Metafield values

I want a new kind of custom content — authors, size charts, FAQs, locations

Metaobject definitions first, then metaobject entries to load them

I have a list of things to load into a metaobject I already defined

Metaobject entries

I'm moving a blog into Shopify

Blog articles

If “definition” versus “value” isn't a distinction you've had to make before, two paragraphs on it here will save you time.

Side by side

Reading that table

Needs a target

An extra choice on the upload step, above the drop zone. For metaobject entries the target isn't cosmetic — the columns you can map are generated from the definition you pick, so changing it changes the mapping step.

Pre-import check

Four types are uniquely keyed, so ImportKit can compare your file against your store and predict the outcome of every row for free. Blog articles aren't keyed by anything, so there's nothing to compare against and no check step. More →

Template

Three types have a hand-written template with worked example rows. Metaobject entries can't have one, because the columns depend on your definition — but the upload step still shows you every column that definition needs. Blog articles are simple enough that the column reference on the upload step is usually enough.

Re-running the same file

This is the important column. For four types, a second run is safe and controlled by your conflict mode. For blog articles it duplicates the articles, because Shopify doesn't treat an article handle as unique in a way that makes de-duplication reliable.

What makes a row a “duplicate”

Each type has its own notion of identity. It's worth knowing, because it decides when a row is a create and when it's an update.

Two rows in the same file with the same identity are caught too: the second is reported as duplicate of row N rather than quietly colliding mid-import.

The order to import in

If you're setting up custom data from scratch, or copying a store, dependencies run in one direction. Following it means every reference resolves on the first attempt.

1. Metaobject definitions

   Nothing depends on anything else. Do these first so metafield definitions can point at them.

2. Metafield definitions

   A metaobject_reference<author> type needs the author definition to exist already. It'll still import without it, but with a warning that the field will accept any metaobject rather than only authors.

3. Metaobject entries

   Needs its definition. Also creates the entries that later references point at.

4. Metafield values, and blog articles

   Last, because these are the rows that reference everything else — definitions for their types, metaobject entries for their reference values, and products or pages as their owners.

A full worked migration in this order →

What's the same for all five

• Your column names are irrelevant; mapping is explicit.
• Blank cells are skipped, never written as empty.
• Values are trimmed.
• Ignored and unmapped columns are dropped before the import runs.
• One credit per row written; skips, conflicts and errors are refunded.
• Rows are processed one at a time, with retries on rate limits.
• Every row gets a durable outcome you can read afterwards in Jobs.
• Cancel stops between rows; Retry resumes from the first unprocessed row.
• Nothing is ever deleted, and no import can be rolled back.