Skip to content
Start a passportAdd products
Implementation & Decisions

Digital Product Passports from a Shopify catalogue

Your catalogue is the starting point. ActivateDigital does the passport work around it, then brings the genuine decisions back to you.

Reading time
11 min
Published by
ActivateDigital
Last verified
Share article
LinkedIn X Email
A supermarket aisle with an organic-branded snack box and a hand holding a phone showing ingredients and certifications.
Jump around this page

In 60 seconds

Yes. ActivateDigital builds a textile Digital Product Passport from the Shopify product data and evidence you already hold. The engine does the resolution work first, then asks only for the facts that still need you or your supplier. No 22-field form.

  • Start with the catalogue you already sell from. ActivateDigital does the resolution work first, then asks only for the facts that still need you or your supplier.
  • The journey is Connect, import, resolve, review and publish.
  • Shopify's inventory CSV lists HS Code and COO columns; its product CSV does not support variant metafields. Check the relevant source before calling a fact missing.
  • Shopify supports metafields with types and validation rules. The passport still needs the source, the scope and the decision behind each value.
  • In the controlled textile test, the initial queue averaged 5.1 product-specific confirmations per product, before merchant answers.

Your starting record can contribute identifiers, variants, composition, origin, customs information or weight where those values are present. ActivateDigital checks what each value supports. You do not need to turn the catalogue into a completed passport before you begin.

The journey is Connect → import → resolve → review → publish. In the wider ActivateDigital workflow, that is Connect → Build → Activate.

Which Shopify fields can a Digital Product Passport use?

Start with the catalogue you already use to sell. Useful information can sit in product and variant records, inventory records, descriptions, metafields or the supplier files behind the listing. A missing column in one export is not the same as a fact the business does not hold.

Starting informationWhat it contributesWhat still needs checking
Product and variant recordsTitles, store identifiers, SKUs, options and a barcode where populatedWhich product the record identifies, and whether an external identifier is valid for its intended use
Inventory informationAvailable customs, origin and measurement informationThe retrieved field, units, product scope and evidence behind the value
Descriptions and metafieldsMaterial, composition, care and other recorded statementsWhich component or variant the statement describes, and whether it supports the intended claim
Company recordsResponsible business details and relevant registrationsThe business role, market and scope in which the detail applies
Supplier documentsSpecifications, declarations, certificates and test evidenceIssuer, date, product or batch coverage and the statement the document actually supports

Shopify documents product/variant and inventory information separately. Its ProductVariant reference and InventoryItem reference describe those data structures. What a store has populated and what an app's authorised connection retrieves are separate questions.

For the meaning of individual fields, use the existing guides to product identifiers, country of origin and fibre composition. The field library keeps the detailed definitions in one place.

From store connection to a reviewed passport

Illustrative workflow. These are stages of the process, not screenshots or exact names of controls in the app. The route a product takes depends on its data, evidence and applicable publishing checks.

1. Connect: start with your store

Begin with the Shopify passport product page. Use your existing catalogue as the starting source and follow the current connection instructions. Review the permissions presented during connection; the connection's actual scope determines what can be accessed.

You're bringing the information you already use to run the business, not agreeing to research a passport field by field before the software gets to work.

2. Import: establish what is already there

The starting records provide the product identity, variants and populated facts available through the supported route. Keep their source and scope: a store description is a supplied statement, not independent proof of everything it says.

Supplier files and other evidence can add information that was never intended for a public listing. What counts is what the combined records support, not how many fields are visible on the storefront.

3. Resolve: do the work around the record

ActivateDigital brings usable information together through a waterfall: each stage works with the available evidence before a gap is passed back to you. The work includes establishing which product a fact belongs to, checking supporting information and calculating a result where the inputs and method support it.

Source-backed facts remain distinguishable from declarations and calculated results. Evidence for one variant does not become evidence for an entire range just because the products share a title.

4. Review: deal with what actually needs attention

A missing declaration, incomplete scope and two credible sources that disagree are three different problems, needing three specific responses, not another complete form.

Confirm the private fact, supply the missing evidence or resolve the disagreement through the appropriate review. Each remaining task gets a reason. A value that cannot be established stays unknown rather than becoming a plausible guess.

5. Publish: put the governed result to work

Once the required publishing checks are met, the reviewed record can become a passport that can be reached through its product link or code. A record being ready for publication and a passport being live are different stages.

Publication does not turn a preparation model into legal certification. Nor does a published page prove that every supporting document should be public. The output, access rules and category requirements must fit the intended use.

Your catalogue starts the process. The governed record is the result.

What the different product states mean

A single product can contain established facts, incomplete evidence and an unresolved conflict at the same time. These labels explain the information, rather than scoring the whole product with a single green tick.

The examples below use a fictional navy hoodie, style HX-01, size M, batch B-2609. They illustrate the decisions involved, not a captured app session or a measured product result.

Descriptive stateExampleWhat it means for the next step
Existing data foundSKU HX-01-NAV-M and the navy/M options are present in the catalogueUse them to connect the starting record. Do not treat the SKU as an independently issued GTIN
Ready for publicationThe required checks and decisions for the intended output have been completedThis is a separate decision from finding data or creating a draft
Live passportPublication has completed and the intended passport can be reachedConfirm the correct product, accessible content and ongoing update responsibility

The hoodie's other states are worked through in one product record: a matched technical pack, a converted net mass, a partial care statement, a body-fabric conflict kept with both records rather than averaged or settled by the newer date and recycled content left unknown rather than zero. A fibre test does not by itself establish recycled origin.

The conflicted example has not reached the last two states. They describe possible later stages, not the outcome of this fictional record.

See what happens when the supplier and the lab disagree. For a missing fact rather than a disagreement, use the route for missing product information.

Your store IDs are a starting point, not the whole identity

Shopify product and variant IDs identify records inside the store. A SKU can be useful to your business without being the recognised identifier a retailer or passport workflow needs. Preserve the relationship between those identifiers rather than silently treating them as interchangeable.

Your first product identifier covers the choice. Mapping product IDs across systems covers keeping them associated with the same product.

A shared style is not permission to flatten the range. Use model, variant and SKU-level facts for the information boundary and passport granularity for the separate model, batch or item question.

Three things that catch people out

One export does not show everything Shopify holds

Product and inventory exports have different jobs. Shopify's inventory CSV documentation lists HS Code and COO columns. Its product CSV guidance supports defined product metafields but says variant metafields are not supported by product CSV import/export. Do not classify information as missing until you have checked the relevant source. Sources: inventory CSV, product CSV.

Those platform facts do not establish that a particular ActivateDigital connection imports every one of those fields. The connection or supported upload route has to supply the relevant information.

A field name is not the whole meaning

A custom field called “material” might describe the body fabric, the lining or a marketing category. Consistent names help, but the record still needs product and component scope. “Fabric: cotton” is not the same statement as a complete percentage composition.

Where an export changes the meaning of a field, the detailed question belongs with what does not map between systems.

Shipping settings do not settle market obligations

A delivery configuration is not, by itself, evidence of every market in which a business places products. Confirm the relevant markets and business role from the operating position, not from postage settings.

A stored customs code is a starting value too, not proof it remains the correct classification. The specialist guide explains what happens when the commodity code changes.

Shopify can store custom data. The passport still needs evidence and control.

Shopify supports metafields and linked metaobjects. Defined custom data can carry types and validation rules. It would be wrong to say that Shopify does no validation at all or that evidence information cannot be represented there. Source: Shopify custom data documentation.

The commercial question is what work sits around those fields. Who decides which source supports the value? How is a supplier's scope kept with the statement? What happens when a newer report contradicts it? Where does the reason for an unknown live?

A governed product record brings the value, its basis and the decision about its use together. The distinction is not “Shopify has nowhere to put the text”. It is storing a statement versus establishing what you can rely on.

The method behind the evidence states is explained in how we know, and what a blank means.

The Registry does not close catalogue gaps

Treat registration and product-data preparation as separate tasks. A registry process does not, by itself, supply a missing composition declaration or reconcile two versions of a supplier record. See what a business still has to prepare, host and maintain outside the Registry.

The passport work happens before the questions

ActivateDigital starts with your existing Shopify data, resolves what the record and evidence support and brings back the facts only you or your supplier can confirm. A composition shared across several sizes should not become unnecessary repeated research, while real material differences still need their own scope.

In the controlled textile test on the existing-data hub, the initial queue averaged 5.1 product-specific confirmations per product, excluding shared company identity. It was an offline test before merchant answers: follow-ups could arise, and it didn't measure completed journeys or elapsed time.

See how to build a textile passport from the data you already have, then read how the test was counted. The example and the measured results are separate.

A populated field is not the same as a supported claim

A product can be listed online without that fact demonstrating its readiness for a particular passport requirement. A validly formatted field is not evidence that the underlying statement is true.

Keep store publication, evidence review and passport publication distinct. For textiles, ActivateDigital's 22-field readiness model is a preparation model, not the final statutory field list. The textile DPP requirements page owns the legal position. The Commission continues to describe the textile-specific requirements as work for a future delegated act. Source: European Commission.

What to do first

Start with one representative product and the records as they are. Include a meaningful variant difference and the supporting evidence you already use in the business. Let the resolution work identify the next useful task before commissioning more data collection.

Where a supplier holds the next answer, ask for the particular fact and supporting document. The guide to how far up the supply chain to go explains that boundary. A small team does not need to buy a new PIM before starting: use the operating model for product data without a PIM.

Comparing platforms? Run a representative-product software pilot using an ordinary product, variants, missing evidence, a conflict and a later change. For the cost question, use the textile passport cost guide, not an assumed saving based on a field count.

Where the passport ends up

The passport is a published view of governed product information, reached through its product link or code. For a concrete output, inspect a worked passport.

Keep the stable product identity separate from the page presenting it. Before printing a carrier, establish which product it identifies, where it resolves and who will maintain that address. A scan that opens a page has not, by itself, proved the product identity or the completeness of the evidence behind it.

The same governed record is also a controlled starting point for buyer requests, retailer data, marketplace information and API outputs. Each destination still needs its required format, access rules and supported delivery route. Reuse the information without pretending every downstream integration is already connected.

Keep the storefront and passport connected

The shop's product page and the passport have different jobs. The storefront helps a customer choose and buy. The passport provides the relevant product information through the appropriate access route. Link the correct product and variant; do not send every item in a range to an unrelated generic page.

The storefront's separate job

Where a DPP duty applies, the online offer has its own access obligations. The details belong with where a DPP must appear on an ecommerce product page, rather than being inferred from the presence of a QR code in an image.

A multilingual storefront is not several truths

Different language versions should remain associated with the same governed identity. They are presentations of product information, not a licence to maintain conflicting product facts. See how one DPP identity supports market and language presentation.

Start with your Shopify catalogue

You already have a starting record. Bring the catalogue and evidence you use to sell your products. ActivateDigital does the resolution work, so the next question has a purpose.

Keep exploring

The questions this page usually raises next.

Also worth reading

Sources and scope

Platform facts were checked against Shopify's ProductVariant, InventoryItem, product CSV, inventory CSV and custom data documentation on 6 October 2026. Documentation describes the platform, not the permissions or behaviour of a particular installed app.

ActivateDigital's product approach and bounded test figures come from the supplied current Knowledge material. The workflow and navy-hoodie example are illustrative, not evidence of a live app session. The European Commission's textile DPP page supplies the textile legal-status boundary.