ImportKit
Permissions and owner types
What ImportKit can reach in your store, what it can't, and why the two lists look the way they do. The short version: no customers, no orders, and the app tells you per row when that's the reason something didn't import.
What ImportKit requests
Shopify shows you this list on the install screen. Here it is with the reasoning:
| Permission | Why |
|---|---|
read_content, write_content |
Create blog articles and read the blogs you can import into. Also gates metafields whose owner is an article, blog or page. |
read_products, write_products |
Look up products, variants and collections by handle, ID or SKU, and write their metafields and metafield definitions. |
read_metaobjects, write_metaobjects |
Create and update metaobject entries, and resolve references to them. |
read_metaobject_definitions, write_metaobject_definitions |
Read your existing metaobject definitions and create new ones. Gated separately from entries by Shopify. |
read_files, write_files |
Resolve file_reference values in metafields and metaobject fields. |
write_locations, write_markets, write_discounts,
write_cart_transforms, write_delivery_customizations,
write_payment_customizations, write_validations
|
So you can define metafields on those owner types. Metafield definitions are gated by the owner resource's own permission, not by a metafield permission — see below. |
Shopify gates metafield definitions by the owner resource's own permission. To let you create a metafield on a market, the app needs market write access — even though it never reads or changes a market. That's why permissions for discounts, locations and checkout customisations appear on a CSV importer.
What ImportKit deliberately doesn't request
These are absent on purpose:
| Permission | What it would unlock |
|---|---|
write_customers | CUSTOMER, COMPANY and COMPANY_LOCATION metafields |
write_orders | ORDER metafields |
write_draft_orders | DRAFTORDER metafields |
write_gift_cards | GIFT_CARD_TRANSACTION metafields |
write_purchase_options | SELLING_PLAN metafields |
Each of those pulls an app into Shopify's protected customer data review or a separate access request. Requesting them would mean holding access to your customers and orders in order to support a handful of metafield owner types — a bad trade for a CSV importer.
The consequence is worth stating plainly: ImportKit cannot read your customers or your orders. Not by policy, by absence of access. That's also why the privacy policy can say the app holds no customer personal data.
Owner types for metafield definitions
You can create metafield definitions for these 13 owner types:
| Owner type | Owner type | Owner type |
|---|---|---|
ARTICLE | DISCOUNT | PRODUCT |
BLOG | LOCATION | PRODUCTVARIANT |
CARTTRANSFORM | MARKET | VALIDATION |
COLLECTION | PAGE | |
DELIVERY_CUSTOMIZATION | PAYMENT_CUSTOMIZATION |
Note PRODUCTVARIANT has no underscore. Get it wrong and you'll see
ownerType "PRODUCTS_VARIANT" is not valid — did you mean "PRODUCTVARIANT"?
Owner types for metafield values
You can set metafield values on these 7:
PRODUCT, PRODUCTVARIANT, COLLECTION, PAGE,
ARTICLE, BLOG, SHOP
Friendly spellings are normalised: PRODUCT_VARIANT, VARIANT and
VARIANTS all become PRODUCTVARIANT, and plurals become singular.
CUSTOMER and ORDER are recognised as valid owner types by Shopify but
are blocked in ImportKit for the reasons above.
How a blocked row behaves
This is the part worth knowing, because it's the difference between an app that degrades honestly and one that fails opaquely. A row targeting a permission ImportKit doesn't hold is reported individually:
CUSTOMER metafields need the "write_customers" access scope,
which this app hasn't been granted.And that's all it does:
- The row errors and isn't charged.
- The rest of the file still imports. One blocked owner type doesn't block the run.
- The pre-import check reports it in advance, so you find out for free.
- The credit estimate counts only the rows that will actually be written.
You'll usually see it before building a file
On the mapping step, ImportKit shows the owner types your store's granted permissions actually cover, as a banner above the mapping table — “Your ownerType column can only use these values, based on the permissions this store has granted the app”.
So the constraint is visible while you're still assembling the file, rather than after a failed import.
The allowed-values banner on the mapping step
The banner listing the owner types available to this store, sitting above the column mapping table.
assets/screenshots/allowed-owner-types.png
If permissions change
When ImportKit's requested permissions change, Shopify asks you to approve the new set — the app can't quietly widen its own access. Approving updates what the app can reach; declining leaves it as it was.
Permission changes are also picked up automatically by the app, so the owner types offered on the mapping step stay in step with what your store has actually granted.
Revoking access
Uninstall ImportKit from your Shopify admin and all API access ends immediately — the session and access token are deleted when Shopify notifies the app. Nothing further can be read or written.
What happens to the data ImportKit stored is covered in the privacy policy's retention section.
If you need customer or order metafields
ImportKit isn't the tool for those, and won't become it — the trade-off isn't worth it. Options:
- Set them in the Shopify admin, one resource at a time.
- Use Shopify's own customer import for customer data where it covers what you need.
- Use the Admin API directly, with a custom app scoped to your store.
Note that both the definition and the value are out of reach for those owner types, since Shopify gates them with the same permission. There's no partial support to fall back on.