Digital Product Passport Data Requirements Reference Guide

A product team has a spreadsheet for materials, a supplier portal for certificates, a Shopify catalogue for product identity, and a sustainability file containing figures that nobody can trace back to an approved source. Then someone asks a simple question: which digital product passport data requirements apply to this product, and can we prove every published value?

That question is harder than creating a QR code. DPP readiness depends on regulatory applicability, persistent identity, evidence quality, field-level approval, machine-readable publication, and controlled updates throughout the product lifecycle. A passport that looks complete but contains unsupported or outdated claims creates a governance problem rather than solving one.

This reference guide treats DPP data as a governed product record. It covers the legal framework, field categories, evidence expectations, serialization, model, batch, and item-level strategies, validation, supplier workflows, and publication controls. It also shows how CSV and XLSX ingestion, Shopify catalogue synchronization, APIs, evidence attachments, human approval, versioning, QR carriers, and registry-ready workflows can fit into an implementation plan.

• Introduction and Scope
• Regulatory Framework and DPP Essentials
• What the registry changes
• Categorizing Data Fields
• Detailed Data Field Entries
• Unique product identifier
• Manufacturer and economic-operator information
• Product model and production information
• Material and fibre composition
• Recycled content and environmental indicators
• Compliance and conformity information
• Repairability, lifecycle events, and end-of-life information
• Cross Referencing and Related Data
• Formatting and Serialization Guidelines
• Granularity and Identifier Strategies
• Validation Rules and EU Compliance Mapping
• A practical validation map
• Governance and Workflow Recommendations
• Quick Reference Cheat Sheet
• Quick Reference Cheat Sheet for DPP Fields
• Glossary of Key Terms
• Related Resources and Next Steps

The practical starting point is a field inventory, not a visual passport design. List the information your teams already hold, identify its source, record its confidence and owner, then compare it with the legal requirements that apply to the relevant product group. This prevents a common failure mode: collecting every conceivable sustainability attribute while missing the identity, provenance, or evidence needed to make the passport usable.

The phrase digital product passport data requirements can suggest a universal checklist. That interpretation is unsafe. The European Commission's approach is product-specific, and delegated acts determine which data applies to each product group. Your catalogue should therefore separate fields that support the passport's identity and access layer from modular fields that become mandatory only under a relevant legal act.

A workable catalogue records more than a field name. For each value, capture:

• Status: required, preparatory, optional, not applicable, or requiring legal review.
• Source: supplier document, test report, certificate, internal system, or approved declaration.
• Evidence quality: whether the supporting record is current, specific to the product, and attributable.
• Format: controlled vocabulary, date, identifier, measurement, text, document, or lifecycle event.
• Granularity: model, batch, or individual item.
• Governance: owner, reviewer, approval state, effective date, and version.

This structure gives compliance, product, sustainability, ecommerce, suppliers, repair teams, and software partners one auditable working model. It also makes implementation more flexible. Manual entry can support exceptional products, CSV or XLSX templates can handle catalogue migration, Shopify synchronization can keep commercial product identity aligned, and API workflows can deliver structured updates from upstream systems.

The key principle is simple:

A passport should publish what the organization can substantiate, identify what remains preparatory, and preserve the history of every approved change.

The EU legal foundation is the Ecodesign for Sustainable Products Regulation, ESPR, Regulation (EU) 2024/1781. The European Union adopted it on 13 June 2024 and published it in the Official Journal on 28 June 2024. The European Commission's Digital Product Passport overview describes the DPP as a legal framework for product information supplied digitally under applicable legislation.

A product team must treat the DPP as an access mechanism tied to the physical product. Economic operators compile the required information digitally and connect it through a physical data carrier placed on the product, packaging, or accompanying documentation. A PDF behind a QR code may provide information, but it does not by itself establish the required product identity, metadata relationships, or access structure.

!A timeline graphic illustrating the regulatory milestones for the development and adoption of Digital Product Passports.

On 20 July 2026, the Commission announced that the Digital Product Passport Registry was live. The registry provides infrastructure for economic operators to register unique product identifiers and associated metadata. Its decentralized architecture allows product data to remain in different systems while the registry supplies a discoverability layer and the DPP identifier anchors access.

That design creates practical work for implementation teams. Product identifiers must remain consistent across systems, metadata must stay linked to the correct product record, and authorized users need a controlled workflow for registration and resolution. DPP Grid can support identifier checks, metadata preparation, approval tracking, and registry submission workflows where the relevant service and authorization are available. It cannot decide legal applicability for every product or certify compliance.

The ESPR sets the framework, while product-specific delegated acts define detailed requirements. The Commission's delegated-act methodology document5423_1/de00000001065679) points toward data that is interoperable, machine-readable, structured, searchable, and transferable, rather than one permanent universal schema. Maintain separate compliance-register statuses for adopted law, applicable delegated acts, proposals, expected timelines, and industry preparation. That separation prevents draft assumptions from becoming published product claims.

A practical DPP workflow therefore combines regulatory mapping, identifier governance, evidence review, and controlled publication. Product teams should record which fields are legally applicable, which remain preparatory, and which system or person approved each release.

A product team preparing a DPP needs a field catalogue that supports ownership, evidence collection, and publication workflows. Five related groups provide a practical structure, but they do not determine legal status. Whether a field is mandatory or optional still depends on the applicable delegated act or sector legislation.

!An infographic titled Digital Product Passport Data showing categorized information fields including identity, sustainability, compliance, and supply chain.

DPP requirements are product-specific and established through delegated acts. Use a stable identity layer plus modular attribute sets. A fashion brand could maintain product identity, fibre composition, and supplier evidence in the common record, then activate further attributes when the applicable textile rules require them. DPP Grid can map these groups to field owners, evidence requests, review states, and controlled publication workflows.

A modular catalogue also prevents draft expectations from becoming published claims. Guides may mention carbon footprint, repairability, substances of concern, or recycling information, but those categories are not automatically mandatory for every product. Record the decision beside each field:

• Required now: supported by an applicable legal requirement.
• Preparatory: needed to close a known data gap or support future mapping.
• Optional: useful for business or circularity workflows, but not currently identified as mandatory.
• Not applicable: excluded for a documented product reason.
• Needs legal review: unresolved until the relevant product-specific rule is assessed.

Link each decision to its evidence source, responsible owner, review date, and approval status. That structure lets teams revise the catalogue when a delegated act changes without rebuilding the product record.

The following entries use one implementation pattern. Each field has a status decision, evidence rule, serialization approach, granularity choice, validation logic, regulatory mapping, and workflow owner. The examples are practical planning models, not claims that every field is universally mandatory.

Description: The persistent identifier is the anchor for discovery, resolution, and related metadata. It should remain stable even when the passport receives new evidence or lifecycle events.

Status: Foundational and required when an applicable DPP obligation applies. The exact identifier structure depends on the relevant rules and supported standards.

Evidence: Retain the product master record, identifier assignment record, and any approved mapping between commercial SKU, GTIN, batch, or serial. A supplier spreadsheet alone shouldn't be treated as sufficient evidence if the organization can't establish ownership and uniqueness.

Format: Use a controlled identifier field. Where supported, resolve the identifier through a web-accessible record and represent it in machine-readable JSON or JSON-LD. A GS1 Digital Link-compatible structure can connect a GTIN with a serial or batch component.

Granularity: Model, batch, or item. Don't combine levels in one value. Store the level explicitly.

Validation: Reject empty values, illegal characters, duplicate active identifiers, and changes to an identifier already attached to a published snapshot. Check that the identifier in the QR resolution matches the identifier in the passport record.

Mapping: The ESPR requires a persistent unique product identifier connected to the physical data carrier. Confirm product-specific implementation details against the applicable delegated act.

Example: A serialized leather jacket can carry an item identifier for ownership transfer and resale. A high-volume consumer product may use a batch identifier where the use case and legal rule support that approach.

A governed record can accept values through manual entry, CSV or XLSX ingestion, Shopify catalogue synchronization, or an API. Human approval should occur before publication, especially when an imported catalogue maps an existing SKU to a new identifier.

Description: This identifies the responsible organization and provides the accountable context for the product record.

Status: Foundational identity and compliance information. Whether each operator detail must be publicly exposed or restricted depends on the applicable legal framework and access rules.

Evidence: Keep the legal entity record, marketplace or product master source, supplier agreement, and approved operator documentation. For imports, retain the internal determination of which party is responsible for market placement.

Format: Use normalized legal names, registered addresses where required, organization identifiers where available, and controlled country codes. Avoid free-text variations such as “ABC Ltd.” in one record and “ABC Limited” in another unless the system stores a canonical value.

Granularity: Usually model or batch, with item inheritance where the responsible operator doesn't change.

Validation: Require a valid organization reference, consistent country value, and an active relationship between operator and product. Flag changes for human review instead of automatically overwriting the published record.

Mapping: The Commission's DPP FAQs describe the passport as a digital container for products, components, and materials, with contents determined by delegated acts or sector legislation.

Example: A retailer should distinguish its commercial seller role from the manufacturer's role. The passport shouldn't flatten those parties into one unverified company name.

Description: Model name, product family, production date or period, and relevant manufacturing facility information help users and authorities understand the record's scope.

Status: Often preparatory until a product-specific legal act defines the exact fields. Treat identity attributes as core and production attributes as modular unless the applicable rule says otherwise.

Evidence: Use approved ERP, PLM, factory, and supplier records. A production date should trace to a production or batch record, not an inferred ecommerce launch date.

Format: Use ISO-style dates in machine-readable payloads, controlled product-family codes, and normalized facility identifiers. Store a date precision indicator if the source only supports a month or production period.

Granularity: Production date and facility can be batch-level. Model names are usually model-level.

Validation: Check date consistency, valid facility references, and the relationship between batch, model, and identifier. Don't allow a batch to reference a model that isn't part of the same catalogue lineage.

Mapping: Map the field to the applicable delegated act or sector legislation once known. Keep the legal reference as metadata rather than hardcoding it into the consumer-facing description.

Example: For apparel, production facility evidence may come from an approved supplier contribution. For consumer goods, a batch record can support recall or conformity workflows.

Description: This records the materials, components, fibres, or substances that make up the product, including proportions or other values where the applicable rule requires them.

Status: Product-specific. Fibre composition may be operationally important for apparel, while a different material vocabulary may apply to consumer goods.

Evidence: Request supplier declarations, bills of materials, laboratory test reports, and certificates tied to the relevant product, component, or batch. Store document provenance, issuer, date, scope, and reviewer decision.

Format: Use controlled material and fibre vocabularies, normalized units, and structured arrays rather than a single sentence such as “mixed fabric.” Preserve the original supplier wording as source evidence, but publish the approved normalized value.

Granularity: Model-level for unchanged composition, batch-level when suppliers or material lots vary, and item-level only where composition differs by individual unit.

Validation: Ensure component proportions use a consistent unit and don't exceed the permitted total. Flag unknown, conflicting, or unsupported material values. Don't convert a supplier's qualitative statement into a precise measurement without evidence.

Mapping: Link the field to the relevant product-specific delegated act or sector regulation. A category list alone doesn't establish a universal legal requirement.

Example: An apparel team can attach a supplier certificate to a structured fibre-composition entry, route the value to a materials owner, and require approval before publishing it to the passport.

Description: These fields represent environmental or circularity metrics only where the applicable legal or business rule defines the metric, boundary, method, and evidence threshold.

Status: Usually preparatory or conditional until a product-specific requirement applies. Don't label a carbon or recycled-content field “required” merely because it appears in a general industry checklist.

Evidence: Use a methodology-specific calculation, supplier certificate, test report, chain-of-custody record, or other authoritative source appropriate to the claim. Record the calculation scope, reporting period, assumptions, and reviewer.

Format: Store numeric values with units, method identifiers, boundary information, and a source reference. Avoid publishing a bare number without context.

Granularity: Model-level for a stable product design, batch-level when input materials vary, or item-level when the evidence supports that resolution.

Validation: Require a unit, method, evidence reference, and approval state. Compare values against configured plausibility checks, but route unusual values to a person rather than automatically correcting them.

Mapping: Map each metric to the exact applicable legal provision or delegated act. The JRC methodology supports a traceable, product-group-specific approach rather than a universal field list.

Example: A recycled-content claim should remain in “needs review” if the certificate covers a supplier's material family but not the specific product or production lot.

Description: This group can include applicable regulations, conformity references, declarations, marking information, and substances-of-concern data where relevant.

Status: Conditional. The field becomes mandatory when the applicable regulation or delegated act requires it.

Evidence: Attach declarations of conformity, test reports, technical files, certificates, and controlled substance records. Evidence should identify the product scope and remain linked to the published version.

Format: Use structured regulation identifiers, document references, dates, and controlled status values. Store CE marking information as a compliance record, not merely as a text label.

Granularity: Model or batch in many workflows, with item inheritance where the compliance evidence covers every item.

Validation: Check that a document exists, is within its validity policy, covers the relevant product, and has an approved reviewer. Require consistent date formats and reject a compliance status that lacks a legal or documentary basis.

Mapping: Connect each field to ESPR provisions, delegated acts, or sector legislation. Don't imply that a CE mark alone proves every DPP attribute.

Example: A consumer electronics team can link a conformity document to the model record while retaining substance evidence at component level where the underlying data requires it.

For shipping-sensitive products, compliance teams may also need a separate evidence trail for transport restrictions and documentation controls. Ship Restrict's compliance insights can help teams think through source ownership, document retention, and approval boundaries without confusing shipping compliance with DPP compliance.

Description: These fields cover repair instructions, spare-part or maintenance information where applicable, disassembly guidance, take-back pathways, recycling instructions, and authenticated events such as repair, transfer, refurbishment, or resale.

Status: Conditional and use-case dependent. Lifecycle events can be operationally valuable even when a particular event isn't yet a mandatory DPP field.

Evidence: Use approved service records, technician reports, refurbishment checks, product manuals, and documented recycling pathways. Every event should identify who performed it, when it occurred, and which item or batch it concerns.

Format: Represent events as structured records with event type, timestamp, actor, affected identifier, evidence reference, and approval state. Keep immutable published snapshots separate from later lifecycle updates.

Granularity: Item-level is strongest for repair, ownership, and resale history. Model-level can hold general instructions. Batch-level can support a shared end-of-life path where appropriate.

Validation: Require a persistent identifier, event timestamp, responsible party, and evidence for material changes. Prevent edits to an approved historical event. New corrections should create a governed version or correction record.

Mapping: Map each attribute to the relevant delegated act or sector legislation once the requirement is confirmed.

Example: A repair programme can record a time-stamped zipper replacement against a serialized jacket, while the model record stores general care and disassembly instructions. Human approval should separate a verified repair event from an unverified customer statement.

A DPP field rarely stands alone. A material entry may determine whether a substance record is relevant. A batch identifier can define the scope of a supplier certificate. A repair event may depend on the item identifier, service provider, date, replaced component, and evidence document.

The EU methodology report says DPP content should be developed through a step-by-step process and a traceability matrix, because requirements depend on the product group and the reason each field exists, rather than on a universal checklist. Use the JRC methodology report for product-specific DPP data requirements as the basis for that discipline.

A practical matrix might contain:

Store these relationships as metadata. When a source changes, the system should identify affected fields and prevent an outdated passport version from remaining active undetected.

Interoperability starts with a clean data model. Separate identifiers, values, units, evidence references, status, and timestamps. Don't bury several attributes in one descriptive paragraph.

A JSON-LD representation might use a stable product identifier and structured properties:

{"@context":"","@id":"","@type":"Product","name":"Leather Jacket","identifier":"GTIN-SERIAL","material":"Leather","additionalProperty":[{"@type":"PropertyValue","name":"recycledContent","value":"approved value","unitText":"controlled unit"}]}

The exact context and vocabulary must match the implementation standard you've selected. Validate @id resolution, context declarations, identifier syntax, units, and relationships before publication. A W3C JSON-LD validator can help identify structural errors, while Google's Rich Results Test can reveal how product-page markup is interpreted. Those tools don't certify a DPP.

For carriers and resolver design, use a persistent identifier that can be searched across systems. DPP Grid's guide to DPP QR codes is useful when deciding how a QR carrier should connect a physical product to a browser-resolvable passport.

CSV and XLSX workflows need explicit column mappings. Define whether a blank cell means unknown, not applicable, or awaiting supplier input. DPP Grid can ingest catalogue data through manual entry and CSV/XLSX templates, while API workflows can support structured writes and JSON or JSON-LD outputs. Human review remains necessary when imported values create public claims.

Set granularity according to the lifecycle use case and the evidence the product team must maintain.

Model-level records suit stable information shared across a product family. They reduce maintenance effort, but cannot separate an individual item's repair, ownership, condition, or resale history.

Batch-level records attach data to a production lot. Use them when material inputs, manufacturing facilities, or conformity evidence differ between lots. They also support targeted operational actions, such as locating products linked to one production run.

Item-level records provide the strongest traceability for products with distinct service or ownership events. A serialized leather jacket can retain its own repair, take-back, ownership, and verified resale history. The trade-off is a larger identifier set, more event records, and tighter governance.

Use a stable identifier-resolution layer to route model, batch, and item records without changing the underlying identity. The carrier should resolve to a web-accessible passport, while the identifier remains searchable across connected systems. For catalogue structure and SKU governance, Sprello's product catalog solutions provide comparison material for aligning ecommerce records with compliance data.

DPP Grid workflows can apply the same approach across manual catalogue entry, CSV/XLSX imports, and API updates. Define the granularity and identifier scope before mapping columns or publishing carriers. This prevents a model record from absorbing item-specific events and gives reviewers a clear basis for approving exceptions.

Validation needs three layers. Syntactic validation confirms that values follow the required format. Semantic validation checks whether they make sense in context. Regulatory validation verifies that the field, evidence, identifier, and publication status meet the applicable legal rule.

The ESPR requires a product to have an available DPP when it is placed on the market or put into service, in line with the applicable delegated acts. The data carrier must connect to a persistent unique product identifier and appear physically on the product, its packaging, or accompanying documentation, according to the relevant rule. Translate these obligations into internal controls using the ESPR text on EUR-Lex as the regulatory reference.

Configure regex or controlled patterns for identifiers and dates. Use range checks for measurements and conditional rules for product categories. Do not hardcode value ranges unless the applicable specification supports them. The validation engine should flag missing evidence, mismatched granularity, duplicate identifiers, stale documents, and unresolved references.

DPP Grid can prepare identifier and metadata registration through a registry connector, while webhooks can return validation results to an upstream catalogue or workflow. Its evidence audit trail resource shows how to connect evidence, approvals, and publication history. Teams can use these controls to reduce operational risk, but they still need legal review and a product-specific conformity assessment.

A release gate should block publication when identity, evidence, or carrier checks fail. Store the failed rule, responsible reviewer, and corrective action so an exception remains traceable rather than becoming an informal approval.

A passport should have an owner before it has a QR code. Product teams should define who supplies each field, who verifies the evidence, who approves the public claim, and who can amend the record after publication.

A controlled workflow can look like this:

1. Define field policies. Classify every field as required, preparatory, optional, not applicable, or needing legal review.
2. Assign ownership. Give product, sustainability, compliance, supplier, and service teams explicit responsibilities.
3. Ingest source data. Accept approved catalogue files, supplier contributions, documents, or API payloads.
4. Validate and review. Run structural and semantic checks, then require human approval for public claims.
5. Publish a version. Create an immutable snapshot, signed publication manifest, resolver, and physical QR carrier.
6. Maintain lifecycle records. Add approved repairs, transfers, take-back, refurbishment, and resale events without rewriting historical snapshots.

!A five-step workflow guide for ensuring Digital Product Passport data quality through governance and regular updates.

The best workflow separates suggested values from approved facts. Evidence should retain its source, confidence, conflicts, checksum or document reference where available, and reviewer decision. A supplier can contribute a material certificate through a time-bound request, but the brand's designated reviewer should decide whether it covers the exact product and publication scope.

DPP Grid supports evidence-backed fields, supplier portal requests, catalogue ingestion through manual entry or CSV/XLSX templates, Shopify synchronization, APIs with scoped keys, and outgoing webhooks on eligible plans. It also supports versioned audit history, human-reviewed translations, locale-specific snapshots, QR carriers, printable PDFs, and browser-resolvable public passports. Those features support governance workflows, but the platform doesn't guarantee compliance, replace legal advice, or certify a product.

Use a product data management system approach when deciding how to connect ingestion, review, approval, and publication. Keep sandbox or test credentials separate from live registry credentials, limit API access by scope, and require a person to approve any claim that reaches a public passport.

Use this table during catalogue audits, supplier requests, and publication reviews. The statuses are planning labels, not a substitute for checking the applicable delegated act.

Before publication, confirm that every required field has an owner, evidence reference, validation result, and approved version.

• Delegated Act: A product-specific EU legal measure that defines detailed requirements under an enabling regulation.
• Granularity Level: The scope of a record, usually model, batch, or individual item.
• GS1 Digital Link: A standards-based approach for connecting product identifiers to web information through a data carrier.
• JSON-LD: A JSON-based serialization method for linked, machine-readable data.
• Registry Connector: A technical connection used to submit or manage identifiers and metadata in a relevant registry workflow.
• Versioning Policy: Rules governing changes, approvals, effective dates, and historical snapshots.
• Evidence Attachment: A source document or record linked to a field to support its provenance and approval.
• Supplier Portal: A controlled workspace where suppliers provide requested data and documents for review.

Start with the EUR-Lex ESPR text, the European Commission DPP FAQs, and the GS1 DPP guidance. Then audit your catalogue against the field groups, identifier strategy, evidence rules, and approval states in this guide.

For implementation planning, review DPP Grid's resources on machine-readable product data, version control, evidence audit trails, QR carriers, and product data management. Prepare a small product sample, map its sources and gaps, and test the path from supplier contribution to approved passport publication.

DPP Grid helps teams govern Digital Product Passports with persistent model, batch, and item identities, evidence-linked fields, supplier requests, catalogue imports, Shopify synchronization, API workflows, QR carriers, and versioned publication snapshots. Visit DPP Grid to review the platform and request a focused walkthrough for your product data and compliance workflow.