How to Create a Digital Product Passport: A Practical Guide

A product team has a launch date, a supplier spreadsheet, a stack of certificates, and a request for a Digital Product Passport. Someone suggests adding a QR code to the hangtag. That sounds practical until the team asks which product identity the code should represent, who approved the material data, what happens when the item is repaired, and whether the record still works when a delegated act changes the required fields.

The QR code is only the delivery mechanism. Creating a Digital Product Passport is primarily a data-modeling, evidence, and governance project. The European Union's framework is Regulation (EU) 2024/1781, the Ecodesign for Sustainable Products Regulation, adopted on 13 June 2024 and in force from 18 July 2024. It defines a DPP as product-specific data accessed electronically through a data carrier, while the detailed information depends on the applicable product-specific delegated act under Article 4. EUR-Lex explains the legal definition and gradual, product-by-product application.

For brands, manufacturers, retailers, ecommerce teams, repair programmes, and software partners, the sensible approach is to build a provisional but governed architecture now. Separate law already in force from delegated acts still pending, use persistent identifiers, attach evidence to every important field, require human approval, and publish only what the record can support.

• Why Creating a Digital Product Passport Starts With a Data Model
  • Build the schema before selecting the platform
• Define Scope, Use Cases, and Field Granularity
  • Choose the right level of identity
• Choose Identifiers That Persist Across the Lifecycle
  • Set the identity before designing the carrier
• Build Evidence-Backed Fields With Human Approval
• Set Up Supplier Workflows and Catalogue Ingestion
  • Make the intake specific
  • Connect the catalogue without creating duplicates
• Publish Through QR Carriers and Public Passports
  • Test the entire publication chain
• Manage Lifecycle Events and Verify Compliance Readiness
  • Use an event ledger
  • Keep regulatory status precise
  • Run the pre-publication checklist

Start with the visible part, usually a QR code, a public product page, or a vendor comparison. The harder decision comes first: what information should the passport carry, who owns each field, and at what level should each value apply?

Under the ESPR, a DPP isn't just a webpage. It is a set of product-specific data made accessible through a data carrier, with information determined by the applicable delegated act. The European Commission's DPP overview explains that the framework is phased by sector rather than governed by one universal deadline. Mandatory DPPs begin on 18 February 2027 for certain types of batteries, and the Commission opened the Digital Product Passport Registry on 20 July 2026 to support implementation ahead of that first deadline.

That makes the schema more important than the software interface. A vendor can change, a storefront can be redesigned, and a QR carrier can be reprinted. A poorly chosen product model, however, can force you to recreate supplier mappings and invalidate lifecycle references.

Use a practical field hierarchy:

• Essential fields are needed for the applicable legal requirement and should block publication when missing.
• Strongly recommended fields support interoperability, retailer requests, and credible lifecycle use cases.
• Voluntary fields can support brand transparency, but they still need evidence and approval if they create a factual or environmental claim.

The JRC methodology, summarized in this explanation of the ESPR data-modeling approach, recommends starting with policy objectives and concrete use cases, then mapping those use cases to data elements and prioritizing fields by value, feasibility, and effort. It also emphasizes a market-reality check. Don't define a field that suppliers cannot reliably provide without deciding how uncertainty will be represented.

Treat the schema as a contract between compliance, sustainability, product, ecommerce, and supplier operations. A useful model normally separates product identity, material and origin, conformity and safety, care and use, repair and resale, and end-of-life events. DPP Grid's product data management system resource is relevant as an example of a governed product-record workflow, but no platform replaces legal review or the need to validate your category-specific requirements.

Scope decisions should connect legal applicability with the teams and systems that will maintain the passport. Record the product category, the potentially applicable law, the status of any delegated act, and the business functions that must read or update the record. The Commission's FAQ explains that requirements may arise through delegated acts under the Ecodesign Regulation or through separate product-specific legislation, with DPP requirements introduced progressively across sectors. The official FAQ distinguishes the framework from product-specific requirements.

Define the operating scenarios before setting field granularity. A repair programme needs a persistent item identity and event history. Resale operations may need ownership transfer, authenticity review, condition, and repair records. Compliance teams may require material composition, substances, technical documentation, and controlled access for commercially sensitive evidence. A consumer page can expose a smaller, approved subset without changing the underlying record.

Three granularities cover the main data relationships in the ESPR context:

• Model level: the product model, identified with a GTIN. Use it for information shared across the model, such as composition, care, and general product guidance.
• Batch level: GTIN plus a lot number. Use it when a value depends on a production run, supplier lot, or manufacturing event.
• Item level: GTIN plus a serial number. Use it when one physical item needs its own repair, transfer, take-back, resale, or authenticity history.

Use the narrowest level that matches the evidence. Identical material composition across a model can sit at model level. A declaration applying only to one production lot belongs at batch level. A repair record for one jacket belongs at item level, not across every jacket sharing the model code.

The Digital Product Passport overview from DPP Grid provides a useful reference for comparing passport structures. Final scope must remain tied to the applicable legal instrument and documented use cases. The EU's 2025 materials indicate that the information set will be product-specific and established later through delegated acts. Build the provisional architecture with field status, applicability, evidence requirements, and a legal-review state, so teams can revise it without treating an interim schema as a universal template. The Commission's 2025 communication provides that context.

Identifier design determines whether a passport remains usable after the first sale. Retailers, consumers, repair operators, recyclers, and marketplaces should reach the appropriate record from the same product carrier. If each system assigns a new identity as the product changes hands, printed codes stop functioning as a durable reference.

Start with the product events the passport must preserve. A shared model identity suits information that applies across the product range. Add production-run identity when supplier evidence or declarations vary by lot. Assign an item identity when a single physical product needs its own repair, ownership, resale, or authenticity history.

GS1 maps these needs to GTIN for model-level data, GTIN with a lot number for batch records, and GTIN with a serial number for individual items. GS1 Digital Link URIs provide a web-based resolution pattern, allowing a carrier to lead to passport information in a browser. GS1 Japan's explanation covers the model, batch, and item structures and Digital Link use.

Review the proposed scheme against five operational questions:

1. Which values are shared across the model? Keep model-level identity for common product information.
2. Which evidence changes by production run? Use GTIN plus lot number where batch traceability is needed.
3. Will the item acquire its own service or ownership history? Use GTIN plus serial number for that record.
4. Can the resolver distinguish model, batch, and item requests? Test each supported resolution before printing.
5. Can the public destination remain stable? Update the approved passport behind the resolver rather than replacing the printed URL. The digital product passport QR code guide explains this carrier and resolution relationship.

The carrier only points to the identity. The passport service still needs access controls, the correct approved revision, and machine-readable information where required. A GS1 white paper describes product identifiers encoded in GS1 Digital Link URI syntax through a QR Code, alongside compatibility with ISO/IEC 15459 and ISO/IEC FDIS 18975. The GS1 white paper explains that standards-based approach.

Approve the identifier scheme before producing packaging artwork or garment labels. A later change can disrupt retailer mappings, marketplace references, repair records, and printed carriers already in circulation.

A passport field is only as reliable as the evidence behind it. Define what is the value, and what supports it? A supplier declaration, test report, mill certificate, bill of materials, repair manual, or conformity document can support the answer. A typed value without a source remains a data-entry event, not a governed compliance record.

Start with the field definition, then test the evidence against its scope. Record the unit, permitted values, granularity, requirement state, and accountable owner. Link the supporting document and identify the relevant passage, page, or table. The reviewer should confirm that the document applies to the correct supplier, product, batch, or serialized item. This prevents a valid certificate from being attached to the wrong record.

Document extraction can propose candidate values and connect them to source files. It should not publish a claim. DPP Grid describes this separation as AI suggestions versus approved facts, with source-linked provenance, confidence, conflicts, and versioned audit history. It doesn't guarantee compliance, certify products, or replace legal advice.

Approval should produce an auditable decision, not just a changed status. Capture the reviewer, decision, date, reason, and resulting revision. Use clear outcomes such as draft, approved, rejected, or needs clarification. Keep the approved public and machine-readable snapshot separate from working drafts and restricted evidence.

Versioning protects the record when materials, suppliers, or specifications change. Retain the previous published value, its source, approver, and reason for change. If a new document contradicts an existing value, flag the conflict and pause publication until an assigned reviewer resolves it. A rollback should create a new revision that restores the earlier state, rather than erase the history.

Keep regulated composition and conformity fields distinct from marketing copy. A sustainability team may approve a sourcing statement, while compliance owns a substance declaration and legal reviews a market-facing claim. Human approval is the control that turns extracted information into governed product data.

Supplier data collection fails when the process depends on scattered email threads. A structured request should identify the supplier, product or lot, required fields, evidence format, submission deadline, and person responsible for review. Ask each supplier only for information relevant to its role. A trim supplier shouldn't receive the same request as a dye house or finished-goods manufacturer.

A workable supplier request includes:

• Defined scope: Product, model, batch, facility, or component covered.
• Required evidence: Certificates, declarations, laboratory reports, bills of materials, or process records.
• Field instructions: Expected unit, permitted format, granularity, and whether the response is public or restricted.
• Submission status: Draft, submitted, needs clarification, approved, rejected, or expired.
• Conflict handling: A clear route for correcting a value without overwriting the original submission.

CSV or XLSX templates work well for initial catalogue loads when the columns match the approved schema. Add validation for missing identifiers, invalid field formats, duplicate rows, and values that don't match the product level. A supplier portal is more suitable when vendors need to upload documents, answer structured requests, and see which items still need attention.

For Shopify or another commerce catalogue, map the SKU master to the appropriate GTIN and reconcile category, material, origin, and variant data before publication. Don't merge records solely on product name. Use deterministic keys and preserve the source system for every imported attribute.

Programmatic ingestion needs equally clear controls:

Use scoped API keys, idempotent writes keyed to the identifier and revision, quotas, and outgoing webhooks where supported. Return field-level errors instead of accepting a request that fails without feedback. DPP Grid documents catalogue ingestion through manual entry, CSV/XLSX, and Shopify synchronization, plus API workflows with scoped keys, idempotent writes, quotas, and outgoing webhooks on eligible plans. Treat those as implementation capabilities to verify against your selected plan, not as proof that an integration is legally sufficient.

Publication begins only after the record passes its approval gates. The carrier, often a QR Code, should resolve to a stable product identity. The passport is the governed record behind that carrier, with public fields separated from restricted supplier, commercial, or security-sensitive evidence.

GS1 Digital Link is useful because the URI can express the product identity while a resolver determines the destination experience. A consumer may see material and care information, while an authorised reviewer may access documents or evidence metadata. The EU framework and related technical literature describe the dual-governance model, in which economic actors manage product-side passport information while a registry or exchange layer supports discovery and interoperability.

Before approving print artwork, check:

• Carrier resolution: The QR Code reaches the correct model, batch, or item record.
• Browser access: A consumer can view the public passport without installing an app.
• Machine-readable output: Structured data remains available for systems that need it.
• Revision behavior: An approved update appears behind the same persistent identity without deleting prior versions.
• Print quality: The carrier remains scannable on the actual label, hangtag, packaging, or product surface.
• Access separation: Public claims don't expose confidential supplier documents or unnecessary personal information.
• Registry readiness: The product identity and resolver information can be mapped when the EU Registry accepts the relevant submission.

Print-ready PDFs can support production teams, but a PDF alone isn't a DPP. The live passport must remain browser-resolvable, governed, and tied to the persistent identifier. DPP Grid describes QR carriers and printable PDFs, public browser-resolvable passports, white-label options, custom domains, styling controls, and an EU Registry connector with registry-ready validation where service and authorization permit. Confirm the exact production configuration before relying on any one feature.

Don't describe a voluntary transparency page as an official EU passport unless the legal and product-specific conditions have been satisfied. The Commission's FAQ says there is no general obligation for every product to have a DPP, because introduction is gradual and product by product. That distinction should appear in internal approvals, ecommerce copy, and retailer documentation.

A passport becomes more valuable when it records what happens after manufacture. For apparel, relevant events may include ownership registration, transfer, repair, refurbishment, trade-in, resale, take-back, recall, and end-of-life routing. Each event should attach to the correct product identity and add evidence without rewriting the original product facts.

A repair record should identify the item, event date, service provider, work performed, parts or materials used, supporting document, and approval state. A resale event may record ownership transfer, condition review, authenticity verification, and the new public snapshot. A take-back event may need a collection reference and downstream handling evidence. The exact fields depend on the use case and applicable law, but the governance rule is stable: append a controlled event rather than editing history.

A lifecycle event ledger should preserve:

• The source passport: The model, batch, or item record that initiated the event.
• The trigger: Repair, transfer, resale, recall, refurbishment, take-back, or dismantling.
• The actor: The approved organisation or user who submitted the event.
• The evidence: Invoice, service report, inspection document, ownership proof, or end-of-life record.
• The timestamp and revision: When the event was submitted, approved, published, or superseded.
• The access level: What the consumer, regulator, repairer, reseller, or supplier can see.

DPP Grid's documented lifecycle capabilities include ownership registration and transfer, repair history, take-back, trade-in, and verified-item resale. Its event-ledger pattern is useful because it keeps lifecycle activity attached to the same persistent item identity instead of scattering it across a repair system, marketplace, and customer-service inbox.

The ESPR framework is already in force, but that doesn't mean every product category already has a final passport field list or active obligation. The Commission states that mandatory requirements are introduced through delegated acts or separate product-specific legislation. For batteries, the Commission identifies 18 February 2027 as the start of mandatory DPPs for certain battery types, while the broader rollout remains phased. Don't turn references to apparel, furniture, electronics, or other sectors into final deadlines unless the applicable legal act supports that conclusion.

The same discipline applies to adjacent product-safety work. For products sold in the EU, include a checkpoint for GPSR-specific information, such as the EU Responsible Person where applicable, manufacturer contact details, and safety information. Keep those fields distinct from sustainability claims. A DPP readiness programme should also review supply-chain restrictions and procurement controls. For manufacturers working with covered federal procurement requirements, Section 889 requirements for OEMs provides useful context on a separate compliance obligation that shouldn't be confused with ESPR or GPSR.

Before releasing a passport, the compliance lead should be able to answer yes to each applicable question:

• Identity: Does the GS1 Digital Link or other supported resolver return the correct record?
• Granularity: Is every field assigned to model, batch, or item level deliberately?
• Evidence: Does each material, origin, conformity, safety, and environmental claim have a linked source?
• Approval: Are responsible reviewers, decisions, dates, and reasons recorded?
• Conflict control: Are contradictory supplier documents resolved or blocked from publication?
• Public access: Are consumer fields separated from restricted evidence and commercial information?
• Lifecycle: Can repair, transfer, resale, take-back, and recall events attach without overwriting history?
• Registry preparation: Is the registry-ready validation or connector configured where authorised and available?
• Supplier ownership: Are supplier contacts, evidence responsibilities, and expiry reviews assigned?
• Legal review: Has the team separated binding requirements from preparatory fields, proposals, and voluntary disclosure?

DPP Grid can support this operating model through evidence management, supplier requests, catalogue ingestion, persistent identifiers, approval states, public passport publication, and lifecycle records. It doesn't guarantee compliance, certify a product, or substitute for counsel and product-specific regulatory review.

DPP Grid gives teams a governed place to model product records, collect supplier evidence, review suggested values, approve facts, publish persistent passports, and attach repair or resale events to the same identity. Visit DPP Grid to explore the sandbox and test a passport workflow against your own apparel, consumer-goods, or ecommerce catalogue.