Prepare DPP-oriented product data from supplier documents

Structured product data as the foundation

A Digital Product Passport is only as good as the structured data behind it. Doc2Shelf extracts product identifiers, materials and composition, technical specifications, and compliance information from spec sheets and datasheets, normalizing them into consistent fields across your catalog.

Review source-linked fields and resolve missing information before using the structured output in a downstream DPP implementation.

DPP preparation output alongside listings and declarations

Doc2Shelf prepares DPP-oriented output from the same reviewed product record that drives marketplace listings and EU/US compliance declaration drafts. One upload can support sales content, regulatory drafting, and DPP data preparation without presenting those outputs as equivalent.

Export the reviewed DPP-oriented product data as structured JSON. Declaration labels and PDF/DOCX declaration documents remain separate outputs for the same product.

Prepare for product-group requirements

Final DPP data, identifiers, data carriers, access rights, interoperability rules, and operating systems depend on the applicable product-group delegated acts and implementation environment. Organizing reviewed source data now makes that later mapping easier without claiming the current export is a finished passport.

What the DPP-oriented JSON contains

The export is one JSON file per product, built from the reviewed product record. It is available only after the product has passed review, and it includes only declaration drafts that have also been reviewed. The table shows the main data groups, typical fields, and where that information usually comes from in supplier documents.

The content is what was extracted from your documents and then confirmed or edited during review, so the quality of the export depends on that review. Gaps that matter for compliance drafting are listed as missing required data, so you can chase them with the supplier before the data moves downstream. The file also records a format version and an export timestamp. Image entries are links; download any images you need to keep, because storage links may be time-limited.

How the export fits into a DPP implementation

A Digital Product Passport is a system, not a file: a persistent unique product identifier, a data carrier on the product or packaging, hosted data with access and update rights, a back-up with a DPP service provider, and, under ESPR, registration of identifiers in the EU DPP registry. Doc2Shelf covers the first stage — getting reviewed, structured data out of supplier PDFs. Your own systems or a DPP service provider take it from there, mapping the JSON to the data model in the applicable delegated act or sector law.

In practice, mapping means three things. First, renaming and restructuring fields to the target schema, for example splitting a combined dimension value into separate length, width, and height fields with units. Second, adding data no supplier document holds, such as the persistent identifier you assign, the data carrier, and the access rights for each field. Third, deciding the passport level — model, batch, or item — which determines whether batch and serial values from the export are used. Keeping the reviewed JSON as a dated input file also gives you a record of what data the passport was built from.

Data quality and identifiers

ESPR requires passport data to be accurate, complete, and up to date, and the passport to be connected to a persistent unique product identifier. Both requirements start with supplier data. Before you send any export downstream, check the points most likely to cause problems later:

• Identifier level: decide whether each product is identified at model, batch, or item level; delegated acts set this per product group.
• GTINs and model numbers: confirm they match the packaging and that variants have their own identifiers.
• Operator details: manufacturer, importer, and EU responsible person details must match labels and declarations.
• Units and values: confirm units on dimensions, weights, and ratings, especially where a data sheet covers several models.
• Document versions: keep the supplier document behind each product, and re-extract when the supplier issues a revision.
• Confidence and completeness: each extraction carries a confidence score and a completeness score; use low scores to prioritize review.

DPP timeline at a glance

Dates in force and dates that are only planned are easy to confuse. As of October 2026, no ESPR product-group delegated act requiring a passport appears to be in force; the first groups in the Commission’s working plan have indicative adoption dates, and obligations normally apply at least 18 months after a delegated act enters into force. Our guide to Digital Product Passport requirements covers the full timeline.

Scope: preparation data, not a finished passport

Doc2Shelf’s DPP output is preparation data. It helps you collect, review, and structure the product information a passport will draw on, and hands it over as JSON for review and downstream implementation.

It does not create, register, host, deploy, or validate a completed Digital Product Passport. It does not assign unique product identifiers or data carriers, check data against the harmonised DPP standards, register products in the EU registry, or assess whether a product complies with ESPR or any other law. Those steps remain with the economic operator, its systems, and its DPP service provider.