Digital Product Passports from a Shopify catalogue
A Shopify store already answers a handful of the attributes a textile passport needs, and it holds one of them somewhere most merchants never look. The rest divides into things you can answer once, things a supplier has to answer and things nobody can answer yet. The platform will not stop you publishing any of it, so the order you work in matters more than anything you buy.
On this page
What the store already answers
Five of the attributes we track 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 catalogue systems give you and it is still a small part of a passport. What decides how much work a passport programme is turns out to be less about the platform than about which of the remaining attributes belong to somebody upstream.
| Where it comes from | Attributes | What 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 of them. Most are a relationship problem rather than a data problem, and four wait on evidence we have not found published anywhere. |
| Calculated | Carbon footprint, water impact, durability coefficient, microfibre shedding, recyclability route. | Produced from the attributes above by a governed method rather than entered. They are only as good as the composition and the weight underneath them. |
The definitions live with the attributes themselves 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 attributes 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 attributes at a stroke.
What the platform cannot hold, in its own documentation
One structured object definition on this platform holds up to forty fields. That is the platform's own developer documentation as read on 28 August 2026, and it is the ceiling a passport meets first. A passport laid out flat is wider than forty fields, so it has to become several linked objects or one blob of text inside a single field.
Linked objects are the honest choice and they cost you a data model. The blob is the tempting one. It reads perfectly well to a person and it is invisible to every tool downstream that reads a catalogue as columns, which is most exports, most channel feeds and most integrations. A blob passes every check there is, because nothing downstream can see inside it.
40
fields in one structured object definition, which is narrower than a passport laid out flat
One definition, on one platform, read in that platform's own developer documentation on 28 August 2026. Platform documentation moves frequently and undated, so this is a reading on a date rather than a fixed property.
SourceShopify developer documentation on custom data, metaobjects and storage limitsChecked 28 August 2026
The size question, which is the one most people ask first, is answered and then closed. The platform publishes a storage envelope for custom data, and the volume of text a passport carries is not what runs into it. What binds is the count of fields inside one definition rather than the number of characters inside them. The published envelope figure sits in our research record and is not transcribed here until it can carry the date it was read.
The same documentation carries no standard definition for composition, for material type, for origin or for sustainability. There is no shape the platform blesses for any of the four, so every merchant recording them invents a shape and nothing makes two stores agree. The platform's published product taxonomy gives apparel categories a single categorical fabric attribute, which is one value rather than a percentage composition and is not held per component. That last claim reached us through our own research pass rather than from the taxonomy release, and the sources below say so.
None of this is 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, which is why what a blank is allowed to mean is a method question rather than a storage question.
The consequence for planning is that a passport programme is not a data migration into new metafields. Some of it lives elsewhere by nature.
What the platform already does with your catalogue
A disclosure rail that already reaches the customer
The platform carries a first-class disclosure field type. What it holds renders into the storefront, the app, custom storefronts, checkout and agentic channels, which is distribution most brands would pay for and which costs nothing to use. That is the platform's own documentation, read on 28 August 2026.
Today the rail carries two disclosure types and neither of them is European. Anything else goes down an unstructured route that accepts free text and defines nothing. We have not found a European passport attribute published through that route, which is a statement about where we looked rather than about what every merchant does.
So the honest answer to whether the platform supports European passport compliance is that it has built the pipe and has not defined the contents. A merchant who wants a disclosure in front of a customer already has somewhere to put it. A merchant who wants that disclosure structured, comparable and readable by a machine does not.
It syndicates, and it guesses
Catalogues are syndicated to AI shopping surfaces on an opt-out basis, and the platform infers colour, material and pattern using its own models. Both statements come from the platform's documentation, read on 28 August 2026.
Read those two together, because they are the sharpest thing on this page. The platform is guessing exactly the attributes this estate argues should be stated with evidence, and the guess arrives in front of a customer looking identical to a declared value. An inferred material is a model's reading of a photograph and a description. A composition on a passport is a value somebody put their name to. Nothing in the presentation separates them.
We are not claiming that better structured data makes a product more visible on those surfaces. Nothing we have read supports that, and it is the claim this subject is most often sold with.
Two things the platform says about itself
It states that it does not offer the responsible person service, so a merchant who needs one is buying it somewhere else. Its own support material also says that text generated by its tools can include product benefits the merchant never listed, with responsibility for accuracy sitting on the merchant. Both were read on 28 August 2026.
A platform writing down that its own drafting tool can invent a benefit is the most useful sentence in this section, because a benefit nobody can substantiate is the exact shape of claim that has to be stood behind by whoever published it. It is also a reminder that accuracy is assigned to you by default in more places than you have looked.
Nothing here is going to make you do it
The platform validates nothing on custom data, gates nothing on completeness and blocks no publish. It documents a requirement for product identifiers and does not validate them either. That is the documentation as read on 28 August 2026, and for planning it is the most important thing on this page.
All the urgency in this subject is imported from outside the platform. The store will let you sell a product with an empty composition field and an internal stock code sitting in the barcode field for as long as you care to. Nothing turns amber. Nobody sends a warning email. The first party to notice is a customer, a buyer running a supplier questionnaire or an authority, and by then the work is not a week.
The market around it is thin in the same way. Passport applications are listed in the platform's app market, the reviews published across those listings are few, and the platform's own code generating application carries a catalogue size above which it stops being usable, which is modest against a real range. We surveyed that market in August 2026 and recorded the counts. The shape is what matters here: a category that exists, with very little published evidence of use and tooling that assumes a small catalogue.
Three numbers this page does not carry yet
Our research record holds the published storage envelope for custom data, the count of passport listings in that app market with the reviews published across them, and the catalogue size above which the platform's own code application stops working. None of the three is transcribed here until it can be published with the date it was read, which is the rule every other figure on this page already follows.
The work, in numbers
On a 34 variant test catalogue, the attributes we track across those variants come to 748 cells. Of those, 363 resolve without anybody being asked anything. A further 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 attributes we track resolve for nobody on that 34 variant catalogue, and every one of the seven waits on evidence we have not found published anywhere 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
- 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. Nothing in the platform will flag it.
- Structure the composition. Move it out of the description and use the legal fibre names. A single categorical fabric value is not a composition, and neither is a sentence.
- Weigh things. Net product mass, without packaging. Nobody can do this for you and several calculated attributes are blocked until it exists.
- Decide your markets. One answer, and it settles the applicability questions underneath several attributes.
- Ask your suppliers once, properly. The supplier dependent attributes do not improve with better software until somebody upstream writes something down, and asking once, properly is a different exercise from sending a questionnaire.
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 hard to undo in a way nothing else in this guide is. An identifier that has been printed onto goods in circulation cannot be edited on the garment, and whether the number itself may ever be reused is governed by the numbering scheme's own specifications, which this estate has not read at their current release and does not assert either way. The address it resolves to has to keep answering for as long as the garments exist. Getting either wrong is not a release you can roll back.
You might want to read next
Sources
-
Platform documentationRelevant provisions reviewedChecked 28 August 2026
A market participant rather than an authority. Evidence of platform behaviour, never authority on the law. One checkable claim on this page rests on it, that the commodity code lives on the inventory item and is absent from the product CSV export.
-
Platform documentationRelevant provisions reviewedChecked 28 August 2026
Read for the two ceilings a passport programme actually meets: the field limit inside one structured object definition, and the storage envelope that settles the size question. It also carries the absence of any standard definition for composition, material type, origin or sustainability.
-
Shopify documentation on the product disclosure field type and where it rendersPlatform documentationRelevant provisions reviewedChecked 28 August 2026
Read for the disclosure field type, the channels it renders into and the two disclosure types it carries today. Its published address was not established by this build, so the row links nowhere and says so.
-
Shopify documentation on catalogue syndication to AI surfaces and inferred attributesPlatform documentationRelevant provisions reviewedChecked 28 August 2026
Read for two statements the platform makes about itself: that catalogues are syndicated to AI surfaces on an opt-out basis, and that colour, material and pattern are inferred with the platform's own models. Its published address was not established by this build.
-
Platform documentationReached through a secondary reproduction, primary text not read
Behind the sentence about the single categorical fabric attribute on apparel categories. It reached this page through our own research pass rather than from the taxonomy release itself, which is why it is the one platform claim here that carries no read date.
-
In forceRelevant provisions reviewed
The nomenclature behind the commodity code. Republished every year, so a stored code ages on a known cycle.
-
Arts. 9, 11CELEX 02024R1781-20240628In forceRelevant provisions reviewed
The framework behind the identifier and the carrier described in the last section.
Help someone else make sense of product passports.