Multiple barcodes per Shopify variant: EAN, UPC and GTIN

Postazione e-commerce con laptop, scanner e pacchi etichettati con codici a barre per la gestione del catalogo Shopify

Shopify now lets you associate up to 20 barcodes with the same product or variant. It is a small change in the admin interface, but an important one for catalogs where the same item arrives from different suppliers, uses different identifiers across retail and marketplaces, or needs EAN, UPC, GTIN, ISBN, ASIN and internal codes to coexist.

Shopify announced the change on September 8, 2026. Existing products do not need to be recreated: the barcode that was already stored stays in the first position. The part worth checking is what happens to integrations that were built around a single barcode field.

What changes in the Shopify catalog

Previously, a variant effectively had one primary barcode identifier. When the same item had additional codes, merchants often stored them in metafields, spreadsheets or external systems.

Shopify now supports multiple barcodes directly on a product or variant. Each code can be classified as UPC, EAN, ISBN, GTIN or ASIN; identifiers that don't follow one of these standards can be stored as Custom.

Shopify documents a maximum of 20 barcodes per product or variant. The same value can't be used twice on the same product or variant. When a standard type is selected, Shopify validates the value against that format.

The first barcode still matters

Multiple barcodes don't mean every surface consumes the whole set. Shopify's changelog states that when a channel or integration expects a single barcode, it continues to use the first barcode on the variant.

That is the first dependency I would check on an existing store. If the primary barcode feeds a marketplace, product feed, label workflow or ERP, changing the order of the codes can affect downstream systems even though the Shopify product itself looks unchanged.

Where multiple barcodes solve a real problem

Multiple suppliers: the same item can arrive with different supplier or batch codes.
Private label: a manufacturer code and your own EAN can identify the same variant.
Marketplaces: the same item can also need an ASIN or another channel-specific identifier.
Retail and POS: different packaging or regions can carry different codes for the same variant.
Migrations and catalog consolidation: historical identifiers can remain searchable without creating duplicate products just to preserve old codes.

I wouldn't use barcodes as a generic container for every company identifier. SKU, barcode and product attributes solve different jobs. If the data describes a product characteristic or a catalog relationship, metafields or Metaobjects may be more appropriate. See the guide to complex Shopify catalogs with variants, metafields and Metaobjects.

CSV: the column is now “Barcodes”

Shopify updated product import and export too. The CSV column is now Barcodes and can contain multiple values separated by semicolons.

The documentation also shows how to declare a type, for example gtin:00012345678905; upc:012345678905; INTERNAL-123. A value without a type is imported as Custom.

One operational detail matters: a CSV file can't contain both the old singular Barcode column and the new Barcodes column. Shopify says a file containing both fails to import. Any automated CSV generator should therefore be updated before the next bulk import.

POS can find a variant with any associated barcode

Shopify POS can search and scan using any barcode associated with a variant. Shopify introduced this behavior in POS v11.14, so a staff member can scan an associated code and still reach the same variant.

For omnichannel operations this can remove manual lookups and duplicate records. It still makes sense to test the real scanners and avoid ambiguous identifiers across different items.

If the issue is broader than identification and involves availability or routing between locations, treat that separately. Shopify multi-location inventory and order routing is a different layer of the architecture.

The critical point is ERP, apps and custom integrations

For a store using only Shopify Admin and POS, the change is relatively straightforward. The risk rises when catalog and inventory data sync with an ERP, PIM, 3PL, marketplace or custom app.

Shopify's developer changelog highlights a specific compatibility issue: an integration that still reads only ProductVariant.barcode sees the first code and gets no automatic signal that additional barcodes exist. That can create silent data loss in a synchronization.

Shopify introduced the new barcodes connection and marked the old barcode field as deprecated. The developer changelog associates the new handling with API version 2026-10 and says a future removal date will be announced with a full API version of notice.

So I would not change an integration simply because the Admin now displays more codes. First verify the API version in use, which fields are read and written, how the first barcode is interpreted, and whether an update replaces the full set.

Be careful when writing barcodes through the API

There are two developer details that can cause regressions. When the new multiple-barcode input is used, Shopify says sending barcodes replaces the variant's entire set, so an integration that adds one code must also preserve the codes that should remain.

Also, a single variant input can't set both the legacy barcode field and the new barcodes input. An API migration therefore needs an explicit write path and regression testing for catalog sync.

A practical rollout sequence

Map every current barcode consumer: Admin, POS, feeds, marketplaces, ERP, 3PL, apps and CSV.
Decide which code must remain in the first position.
Add a small number of real test cases.
Verify search and scanning in Admin/POS where applicable.
Export the CSV and inspect the new Barcodes column.
Verify integrations that read or write catalog data.
Only then extend the change across the rest of the catalog.

For a catalog with thousands of variants, I would avoid a bulk update before completing at least one full read-modify-export-sync cycle. The native feature removes workarounds, but it can't know which identifier your surrounding systems consider primary.

What doesn't change

Existing barcodes remain in place and there is no mandatory migration if one barcode per variant already solves your use case. This is added capability, not a reason to reorder a catalog for its own sake.

The useful criterion is operational: add extra codes when they remove duplication, improve scanning reliability or let different systems recognize the same variant without creating artificial product copies.