Skip to content

Digital Product Passports from a Shopify catalogue

A Shopify store already holds about a quarter of what a textile passport needs, and it holds one of those fields somewhere most merchants never look. The rest divides into things you can answer once, things your supplier has to answer and things nobody can answer yet.

Sources as at
26 August 2026
On this page

What the store already answers

Five of the twenty two fields come straight out of a Shopify catalogue with no input from anybody: the product identifier, the model and variant structure, the commodity code, the country of origin and the weight. A sixth, fibre composition, comes partly from the store and partly from you.

That is a better starting position than most platforms and it is not a large fraction of the passport. What decides how much work a passport programme is turns out to be less about the platform than about which of the remaining sixteen fields belong to somebody upstream.

Where each attribute comes from when the catalogue is in Shopify.
Where it comes fromAttributesWhat that means for you
The store record Product identifier, model and variant, commodity code, country of origin, weight. Already there, assuming the field holds what its name says. Tidying the catalogue is the cheapest useful work in the whole programme.
The store plus you Fibre composition. Often present as prose in a description. It becomes a passport value when it is structured, and it stays a guess until then.
You once, then a register Operator identity, operator contact, producer registration per market. Answered once for the business rather than per product, then checked against public registers where a register allows it.
You, or somebody upstream Recycled content, conformity declarations, production facilities, substances of concern, SCIP reference, repair route, care instructions, safety certificates. Eight fields. Most of them are a relationship problem rather than a data problem, and four of them wait on evidence that has not been created anywhere yet.
Calculated Carbon footprint, water impact, durability coefficient, microfibre shedding, recyclability route. Produced from the fields above by a governed method rather than entered. They are only as good as the composition and the weight underneath them.

The field-by-field definitions live on the field guide rather than being restated here.

Three things that catch people out

Your commodity code is in the catalogue and not in the export

Shopify holds the harmonised system code on the inventory item, and it is absent from the product CSV export. A merchant who exports their catalogue to see what they have will conclude they do not hold a commodity code, and be wrong. It is one of the easier passport fields and one of the most commonly assumed missing.

Every merchant names their metafields differently

Where you have already recorded a fact in a metafield, that fact should answer the passport question rather than being asked again. Doing that reliably is harder than it sounds, because matching against a published list of key names works on a demo store and on almost nothing else. Real stores carry vocabularies that grew one product launch at a time.

The practical version for you is short. Keep one key per fact, use it consistently and do not encode two facts in one field.

Ships is not sells

Shipping settings are not evidence that you place goods on a market. A shop that will post to Belgium has not thereby placed goods on the Belgian market, and an engine that inferred markets from a postage table would be attaching legal duties to a configuration screen. Which markets you sell into is a question you answer, once, and it decides several fields at a stroke. Who carries what is set out on the applicability page.

What a store cannot hold

We worked out what a shop would have to store to answer all twenty two fields without ever being asked a question. A meaningful part of it has no home in Shopify at all, in any field, native or custom.

That is not a criticism of the platform. It is a catalogue system, and some of what a passport wants is evidence about evidence: who said a thing, when they said it and what could not be established. A product field can hold a value. It cannot hold the reason a value is absent, and that reason is the part that makes a passport readable by somebody who is not the brand.

The consequence for planning is that a passport programme is not a data migration into new metafields. Some of it lives elsewhere by nature.

The work, in numbers

On a 34 variant test catalogue, twenty two attributes across those variants is 748 cells. Of those, 363 resolve without asking anything, and 24 distinct questions cover the rest.

Those are our own figures on our own test catalogue. The engine has not been run against a customer catalogue, so nothing here is a customer outcome and none of it is an average. Take the shape rather than the ratio: a small number of well chosen questions covers a large number of cells, because one answer usually lands across many rows.

Seven of the twenty two attributes resolve for nobody on that catalogue, and every one of the seven is waiting on evidence that does not publicly exist rather than on a better integration.

One denominator worth checking

Variants are not products. A composition is a property of the product, so five sizes of one shirt are one composition question and five passports. Counting variants when estimating effort inflates the work, and counting products when estimating passports understates the output.

What to do first

  1. Check what is in your barcode field. A common identity defect we see is an internal stock code written into the barcode field, and a wrong identifier is hard to put right once it has been printed onto goods that are already in circulation.
  2. Structure the composition. Move it out of the description and use the legal fibre names. The fibre composition page covers which names are permitted and what a qualifier does to one.
  3. Weigh things. Net product mass, without packaging. Nobody can do this for you and several calculated fields are blocked until it exists.
  4. Decide your markets. One answer, and it settles the applicability questions underneath several fields.
  5. Ask your suppliers once, properly. The eight supplier-dependent fields do not improve with better software until somebody upstream writes something down.

What not to do first is buy anything. Four of those five cost nothing and every one of them makes whatever you buy afterwards work better.

Where the passport ends up

The output is a page reachable from a code on the product. The identifier goes into a URL grammar that carries it, the code is printed with enough error correction and enough quiet zone to survive a garment's life, and a resolver answers when it is scanned.

Two decisions there are permanent in a way nothing else in this guide is. The identifier printed onto goods in circulation cannot be reassigned, and the address it resolves to has to keep answering for as long as the garments exist. Getting those wrong is not a release you can roll back.

What comes out of it A worked passport, row by row, with the resolved rows and the empty ones side by side. It is the clearest way to see what this work produces. How much time there is What is in force, what is adopted and what has only been indicated, with sources and verification dates.

Sources