# TracePass — full content (markdown) > Every English page of www.tracepass.eu, concatenated as markdown for AI ingestion. Localised variants (bg/de/it) are available per-page via `Accept: text/markdown` or a `.md` suffix. --- --- title: TracePass — AI-Powered Digital Product Passport Platform description: "TracePass is the EU Digital Product Passport platform: upload your product data and get a GS1 Digital Link passport, permanently hosted — battery, textile, electronics, or any ESPR category. Our AI reads your existing datasheets, auto-fills the mandatory fields, and flags gaps for human review. No migration, no empty forms — compliance on the data you already have." canonical: "https://www.tracepass.eu/" locale: en source: "https://www.tracepass.eu/" --- # TracePass — AI-Powered Digital Product Passport Platform > TracePass is the EU Digital Product Passport platform: upload your product data and get a GS1 Digital Link passport, permanently hosted — battery, textile, electronics, or any ESPR category. Our AI reads your existing datasheets, auto-fills the mandatory fields, and flags gaps for human review. No migration, no empty forms — compliance on the data you already have. TracePass is the EU Digital Product Passport platform: upload your product data and get a GS1 Digital Link passport, permanently hosted — battery, textile, electronics, or any ESPR category. Our AI reads your existing datasheets, auto-fills the mandatory fields, and flags gaps for human review. No migration, no empty forms — compliance on the data you already have. ## What is a Digital Product Passport? A Digital Product Passport (DPP) is a structured digital record that accompanies a physical product across its lifecycle, carrying information about its composition, origin, environmental footprint, repair and recycling instructions, and regulatory compliance status. Under the EU's Ecodesign for Sustainable Products Regulation (ESPR, Regulation 2024/1781) and the EU Battery Regulation (2023/1542), DPPs become mandatory for most product categories sold in the EU between 2027 and 2030. The passport is accessed through a data carrier — typically a GS1 Digital Link QR code or NFC tag — printed on or attached to the product. ## What Makes TracePass Different - **AI Data Extraction & Research** — Upload PDFs, spec sheets, certificates — or just a product model. Our AI reads your documents, searches the public web for missing data, and suggests field values with confidence scores. You review and approve. No manual data entry from scratch. - **Built and Hosted in the EU** — TracePass LTD is an EU company (Bulgarian Commercial Register, UIC 208790302) with EU data residency. Your compliance data — and the passports your customers scan — never leave the EU. Procurement-grade specifics on the Trust page. - **Your URL, Forever — No Lock-In** — Publish on your own custom domain, so the QR printed on the product is yours permanently. Cancel any time and export everything as JSON-LD with full provenance — no per-scan fees, no hostage data. The URL on shipped products keeps working while you migrate. ## Verifiable, not vapor: - [EU company · UIC 208790302](https://www.tracepass.eu/impressum) - [EU PIC 863746977](https://ec.europa.eu/info/funding-tenders/opportunities/portal/screen/how-to-participate/org-details/863746977) - [Listed: CIRPASS-2 Stakeholder Exchange Forum](https://circular-data.org/o/892486cd-c05d-4c74-97ca-c18e70bfb934) - [GS1 Digital Link resolver](https://www.tracepass.eu/trust) - [Wikidata entity](https://www.wikidata.org/wiki/Q139970743) ## How It Works 1. Upload Your Data — CSV, Excel, PDF, spec sheets — upload whatever you have. No special format needed. 2. AI Fills, You Review — Our AI extracts data and fills 90+ mandatory fields with confidence scores. You review suggestions, approve or edit. AI-assisted, human-verified. 3. Compliance Validation — Automated validation against ESPR, Battery Regulation 2023/1542, and category-specific requirements. Audit-ready: every field carries its source document, the person who approved it, and a timestamp — so you can defend any value to an inspector. 4. QR Code + Live Passport — Get your Digital Product Passport with GS1 Digital Link QR code. Hosted, multilingual, permanently accessible. ## FAQ ### What happens if I cancel my subscription? Your published Digital Product Passports stay accessible via QR code and Digital Link for 30 days after cancellation. During this grace period, QR codes on shipped products keep resolving as normal. After 30 days, passports stop resolving publicly. Reactivating any time before then restores full access automatically. Your data is never deleted — you can export it to CSV from the dashboard or pull it via the REST API (every plan; daily call cap only on Free and Basic, Starter and above unlimited) at any time, and resubscribing restores everything. ### What if my payment fails? Published passports stay live — QR codes on shipped products keep working even when billing lapses. New passport creation, AI extraction, and supplier requests are paused. You have 14 days to resolve billing before the 30-day passport grace window starts; settling the invoice at any point before then lifts all restrictions automatically. ### Can I take my data with me? Yes. The data you enter belongs to you, with no lock-in. Paid plans include a full JSON-LD export (every passport, product, and template, with provenance and version history preserved), per-category CSV that round-trips with any ERP/PIM, and programmatic access via the REST API. Cancellation doesn't delete your data — you can re-subscribe later and continue where you left off. ### What happens when I downgrade? Passports never disappear just because you downgraded. Upgrades apply immediately with prorated charges. Downgrades that reduce the passport cap charge an overage fee on the remaining passports at the new plan's per-DPP rate — we warn you before confirming so there's no surprise. ### Do I need to give the AI training data? No. The AI reads your uploaded documents and can also research the public web for missing fields. Every field you approve, modify, or reject then improves confidence scores for your future extractions — and accepted manufacturer names are shared across your own workspace so your team doesn't re-enter them. --- --- title: PPWR compliance software for packaging that ships in the EU description: PPWR compliance software for packaging producers. TracePass auto-fills recyclability grade, recycled content, and EPR data into 66 PPWR-ready fields. canonical: "https://www.tracepass.eu/ppwr" locale: en source: "https://www.tracepass.eu/ppwr" --- # PPWR compliance software for packaging that ships in the EU > PPWR compliance software for packaging producers. TracePass auto-fills recyclability grade, recycled content, and EPR data into 66 PPWR-ready fields. Regulation (EU) 2025/40 turns recyclability, recycled content, and EPR registration into per-SKU reporting obligations. TracePass structures the packaging data you already hold into 66 PPWR-ready fields, auto-fills what it can from your specs and supplier disclosures, and generates a passport for every pack variant — so PPWR readiness is a data task, not a spreadsheet marathon. ## What PPWR actually requires The Packaging and Packaging Waste Regulation (PPWR), Regulation (EU) 2025/40, replaces the old Packaging Directive with directly-applicable rules across every Member State. Unlike a directive, there's no national transposition to wait on — the obligations land on the same staged dates everywhere from 2027 onward. For anyone placing packaging on the EU market, the practical effect is that recyclability and recycled content stop being marketing claims and become structured, reportable, per-format data. - Recyclability grades (A / B / C): every packaging unit gets a design-for-recycling performance class, with poorly-recyclable formats restricted over time. - Minimum recycled-content thresholds: plastic packaging must hit per-application recycled-content percentages, rising on a staged timeline — tracked per material, not per product line. - EPR (Extended Producer Responsibility): producer registration and fee modulation tied to recyclability, captured per Member State scheme rather than as free text. - Reuse and refill targets: reporting obligations for reusable packaging formats in scope sectors. - Substances of concern: declaration of restricted substances in packaging, aligned with the wider DPP data model. - Staged enforcement (2027–2030): the obligations phase in by date and format, so the data model has to be ready before the deadline, not after it. ## How TracePass makes packaging PPWR-ready ### Auto-fill from the specs you already have TracePass's research agent reads material-disclosure pages and packaging specs — Tetra Pak, CCEP, brand-owner sustainability sheets — and fills material composition, recyclability grade, and recycled-content percentage automatically. You review, you don't re-type. ### Structured material composition, not free text A structured editor captures percentage per material and functional layer, so composition data stays consistent SKU-to-SKU instead of drifting across spreadsheets. That's what makes recyclability-grade and recycled-content reporting auditable. ### EPR scheme captured per Member State Producer-responsibility scheme is a structured field per Member State (CITEO, DSD, PRO Europe, Valorie, and the rest), with the producer registration number captured as data — ready for fee-modulation reporting rather than buried in a PDF. ### Request the data you don't hold — automatically When a value is only the supplier's to know, TracePass emails them from a token-linked portal and writes the answer straight back into the field. No chasing material data over email threads. ### Batch-create passports across every pack variant One product-line template generates thousands of SKU-variant passports in a single run — the format/size/material permutations that make packaging reporting painful become a batch job with per-variant QR codes. ### Built against (EU) 2025/40, future-proofed for the staged dates Recyclability classes, per-material minimum-recycled-content thresholds, and reuse-target fields are already in the schema. Record the current (national or voluntary) grade now and update to the harmonised PPWR criteria when they arrive — without losing the passport's history. ## Who it's for Packaging producers, fillers, and brand owners placing primary, secondary, or tertiary packaging on the EU market — food, beverage, e-commerce, rigid plastics, flexibles, paper, glass, and aluminium — plus the compliance and packaging-development teams who own PPWR reporting. ## PPWR software — frequently asked ### What is PPWR compliance software? PPWR compliance software structures the packaging data that Regulation (EU) 2025/40 makes reportable — material composition, recyclability grade, recycled-content percentage, and EPR registration — into per-format records you can report against and attach to a digital product passport. TracePass auto-fills those fields from your existing specs and supplier disclosures rather than asking you to maintain them by hand. ### When does PPWR start applying? Regulation (EU) 2025/40 applies on staged dates from 2027 through 2030, with recyclability and recycled-content obligations phasing in by packaging format. Because it's a regulation, not a directive, the dates apply directly in every Member State without national transposition — so the data model needs to be in place ahead of each deadline, not after it. ### Do I need separate software for EPR reporting? No — TracePass captures the EPR scheme and producer registration number as structured fields per Member State, alongside the recyclability and recycled-content data that drives fee modulation. The same record that makes a packaging unit PPWR-ready carries the EPR data, so you're not maintaining two parallel datasets. ### How is this different from your packaging DPP page? Same engine, different starting point. This page is for teams evaluating PPWR compliance software — how the tool structures, auto-fills, and reports your packaging data. The packaging passport page walks through the per-format digital product passport itself. If you want the capability breakdown by field, start with packaging; if you're scoping the compliance workflow, you're in the right place. ### Can TracePass fill recyclability grade and recycled content automatically? Where the data is published or held in your specs, yes — the research agent reads material-disclosure pages and packaging specs and proposes the recyclability grade and recycled-content percentage, with source and confidence attached so your team can review before publishing. Where only a supplier holds the value, TracePass requests it through a token-linked portal and writes it back into the field. --- --- title: The EU Battery Regulation, handled as a data task description: What the EU Battery Regulation (EU) 2023/1542 requires, and the software that fills the battery-passport fields — mandatory from 18 February 2027. canonical: "https://www.tracepass.eu/battery-regulation" locale: en source: "https://www.tracepass.eu/battery-regulation" --- # The EU Battery Regulation, handled as a data task > What the EU Battery Regulation (EU) 2023/1542 requires, and the software that fills the battery-passport fields — mandatory from 18 February 2027. Regulation (EU) 2023/1542 makes a digital battery passport mandatory from 18 February 2027 — the mandatory fields per battery, from chemistry and carbon footprint to supply-chain due diligence. TracePass reads your datasheets, fills what it can, requests the rest from suppliers, and publishes a GS1 Digital Link passport per unit. The regulation becomes a structured-data problem, not a compliance scramble. ## What the EU Battery Regulation requires From 18 February 2027, every LMT, industrial (>2 kWh), and EV battery placed on the EU market must carry a digital battery passport with the mandatory data fields — reachable from a QR code on the battery and resolvable through a unique GS1 Digital Link identifier. This obligation comes from Regulation (EU) 2023/1542, which replaced the 2006 Battery Directive with directly-applicable rules across every EU Member State, meaning the same passport requirements take effect on the same dates everywhere in the Union without any national transposition needed. - Digital battery passport mandatory from 18 February 2027 for LMT, industrial (>2 kWh), and EV batteries. - Carbon footprint declaration per battery model, with a calculated CO₂e/kWh figure and a defined methodology. - Recycled-content shares for cobalt, lead, lithium, and nickel — declared, then rising to minimum thresholds on the staged timeline. - Supply-chain due diligence: documented policies on the social and environmental risks of raw-material sourcing. - State-of-health and durability data for the battery management system, accessible to authorised parties. - Unique identifier + data carrier (QR) resolving to the passport, following the GS1 / EU data-model conventions. ## How TracePass fills the battery passport ### Fill the mandatory fields from your datasheets TracePass reads cell datasheets, safety data sheets, and test certificates and fills chemistry, capacity, voltage, weight, and safety data automatically — you review, you don't re-type. ### Carbon-footprint defaults you can replace later When you don't yet have a verified LCA, defaults from the Battery Pass Consortium / EU PEF fill the CO₂e/kWh field so the passport is complete — swap in your measured figure later without losing the passport. ### Request supplier-only data automatically Scope-1 emissions, exact cobalt provenance, due-diligence attestations — when only the cell maker holds a value, TracePass emails them from a token-linked portal and writes the answer back into the field. ### Reference-database prefill for known cells Known cell models (Panasonic NCR18650B, Samsung, LG, CATL) prefill dozens of fields in seconds from reference-database lookups — you start from a populated passport, not a blank form. ### Batch passports for the production line Batch-create up to 500 passports per run, with auto-generated serial numbers and per-unit QR codes ready for the line — importers can build the passport they're legally responsible for from a single OEM datasheet. ### Every field carries source, confidence, and an audit trail Auto-extracted values are suggestions with a source and a confidence score, queued for explicit human review before publishing — so your QA signs off on the passport, and the audit trail shows where every value came from. ## Who it's for Cell manufacturers, pack assemblers, EV / e-bike / industrial-battery brands, and importers compiling battery passports — including for cells they don't manufacture themselves. ## EU Battery Regulation — frequently asked ### When does the EU battery passport become mandatory? From 18 February 2027, under Regulation (EU) 2023/1542, every LMT, industrial (>2 kWh), and EV battery placed on the EU market must carry a digital battery passport reachable via a QR code. The data model needs to be in place ahead of that date, not after it. ### How many fields does the battery passport require? The passport must carry the mandatory fields per Annex XIII of Regulation (EU) 2023/1542, covering identity, chemistry, carbon footprint, recycled content, supply-chain due diligence, performance, and end-of-life. TracePass structures them all: many populate automatically from datasheets and reference databases; the rest are requested from suppliers or entered once and reused across the batch. ### Is this different from the EU Battery Directive? Yes. Regulation (EU) 2023/1542 replaced the 2006 Battery Directive. As a regulation it applies directly in every Member State without national transposition — so the obligations, including the battery passport, land on the same dates across the EU. The older term "Batterierichtlinie" refers to the superseded directive. ### We import cells we don't manufacture. Can we still produce the passport? Yes — as the importer the passport obligation is yours, and TracePass is built for it: upload the OEM datasheet, the platform extracts what it can and requests the supplier-only values through a token-linked portal, so you can compile a compliant passport even when the manufacturer abroad hasn't produced one. ### What are the risks of getting the EU Battery Regulation wrong? The commonest risk is not a missing passport but a misplaced one: Regulation (EU) 2023/1542 imposes three legally distinct information obligations that are easy to conflate. Article 13 is physical marking ON the battery — the separate-collection symbol has applied since 18 August 2025, and the Cd/Pb chemical symbols under Article 13(5). Annex VIII is technical documentation supporting conformity assessment, held and produced on request. Only Article 77 with Annex XIII is the passport itself, mandatory from 18 February 2027. A complete passport behind a missing or undersized label is still a labelling failure. Article 77(4) also puts accuracy, completeness and being up to date on the economic operator placing the battery on the market — a duty that does not transfer to a software vendor, though it may be delegated in writing. ### How long must the battery passport stay available? There is no year count, and quoting one is a common error — the ten-year retention in the Battery Regulation belongs to technical documentation and conformity records (Articles 38, 41 and 51), not to the passport. The passport's rule is event-bound. Article 77(8): a battery passport “shall cease to exist after the battery has been recycled” — recycling is the only terminus. Article 78(e) requires that it “remain available after the economic operator … ceases to exist or ceases its activity in the Union”. So the window runs from placing on the market until the battery is recycled, and it must survive the company that created it. That survivorship requirement is also why ESPR Article 10(4) obliges an operator to lodge a back-up copy with a digital product passport service provider. ### What does battery passport compliance actually cost? The two biggest variable costs are the PEF (Product Environmental Footprint) study — €8K–€25K via an external assessor, 2–6 weeks — and GS1 membership for a Digital Link resolver at €500–€1,500/year. Internal compliance-team time runs 240–400 person-hours for the first DPP, dropping to 40–80 hours per repeat model once supplier relationships are in place. Software costs are a small fraction: TracePass plans start at €49/month for manual entry and €350/month for AI-assisted extraction at mid volume. The PEF and GS1 setup are the long-lead items — both should start before the data-collection sprint. --- --- title: Battery Passports, generated from your existing datasheets description: Battery passport ready before February 2027. Upload cell datasheets — TracePass fills them, requests the rest from suppliers, ships GS1-QR passports. canonical: "https://www.tracepass.eu/battery" locale: en source: "https://www.tracepass.eu/battery" --- # Battery Passports, generated from your existing datasheets > Battery passport ready before February 2027. Upload cell datasheets — TracePass fills them, requests the rest from suppliers, ships GS1-QR passports. Upload the supplier datasheet. TracePass extracts the mandatory fields, cross-checks reference databases, requests the rest from the cell manufacturer, and publishes a GS1 Digital Link passport per unit. ## Who it's for Cell manufacturers, pack assemblers, EV / e-bike / industrial-battery brands, and importers compiling DPPs for cells they don't build themselves. ## How TracePass helps - AI reads your cell datasheets, SDS, and test certificates — fills chemistry, capacity, voltage, weight, and safety data automatically. - Reference-database lookups for known cell models (Panasonic NCR18650B, Samsung, LG, CATL) prefill dozens of fields in seconds without you having to type them. - Carbon-footprint defaults from Battery Pass Consortium / EU PEF fill CO₂e/kWh when you don't yet have a verified LCA — replace later without losing the passport. - When a field is only the cell manufacturer's to know (scope-1 emissions, exact cobalt provenance), we email the supplier automatically from a token-linked portal. No back-and-forth spreadsheets. - Batch-create up to 500 passports per run, with auto-generated serial numbers and per-unit QR codes ready for the production line. - As an importer, upload one OEM datasheet and we create the DPP you're legally responsible for — even if the OEM abroad hasn't produced one. - Every field has source + confidence + audit trail, so your internal QA can review before publishing. ## What the template covers - Chemistry + cell format (NCA / NMC / LFP / 18650 / prismatic / pouch) - Capacity, voltage, energy density, power capability - Raw-material provenance (Li / Co / Ni / natural graphite) - Carbon footprint kg CO₂e/kWh with method reference - Recycled-content % per element (Co / Li / Ni / Pb) - SVHC + hazardous-substance disclosure - Performance + durability + end-of-life fields ## FAQ ### I have 2,000 cells to passport by next quarter. Can TracePass handle that? Yes. Batch creation takes up to 500 passports per run; an import of 2,000 is four runs. Auto-generated serials, shared model fields, per-unit QR codes. The practical bottleneck is your datasheet availability, not the platform. ### We're an importer and our OEM hasn't given us CBAM / Battery Reg data. What now? TracePass sends a token-linked data-request portal to the OEM on your behalf. They fill in the fields you're missing without needing an account. If they don't respond in 14 days we send an automatic reminder. You still own the passport and publish when ready. ### How does this plug into our existing ERP / PLM? Two ways. (1) CSV bulk import with a category-specific template — any ERP can export that. (2) REST API on every plan (Free included; daily call cap only on Free and Basic, Starter and above unlimited) for direct integration. We don't build SAP connectors yet; your integrator writes the mapping once against our documented API. ### What if the regulation changes in 2026? We track Battery Regulation delegated acts and update the Annex XIII template in place. Your existing passports stay valid; new fields appear as 'empty' and you decide when to fill them. ### Do you support EPCIS for multi-tier supply-chain traceability? Yes — full GS1 EPCIS 2.0 (export, capture and query) included on every paid plan. Any passport's supply-chain, service, and ownership events serialise as a standards-valid EPCIS 2.0 document, advertised on the GS1 Digital Link QR so an EPCIS-aware system discovers the event history automatically. For multi-tier chains, the Capture interface lets your suppliers and ERP systems push events in, and our AI agent drafts events from datasheets for your review. Volume meter scales by tier (Basic 1k events/mo up to Pro 10M, unlimited on Enterprise). EPCIS is the recommended traceability vehicle for ESPR Article 5(5)(o). --- --- title: "Textile Passports, wired to your brand's existing product data" description: "Apparel and home-textile brands: upload your product pages and care-label data. TracePass fills 60 ESPR fields, multilingual public passports, NFC-ready." canonical: "https://www.tracepass.eu/textile" locale: en source: "https://www.tracepass.eu/textile" --- # Textile Passports, wired to your brand's existing product data > Apparel and home-textile brands: upload your product pages and care-label data. TracePass fills 60 ESPR fields, multilingual public passports, NFC-ready. Point TracePass at your product pages. We extract fibre composition, care instructions, certifications, and repair URLs automatically — and host a multilingual passport behind a QR code embedded in the care label. ## Who it's for Apparel brands, footwear makers, home-textile manufacturers, technical-textile producers, and their EU importers. ## How TracePass helps - AI agent reads your brand's product pages, your tech packs, and your suppliers' material certificates — fills composition, certifications, country of manufacture automatically. - Reference-database lookups for canonical fabrics (Lenzing TENCEL Lyocell, Polartec 200, Cordura 1000D, OrganicLeather) prefill dozens of fields in seconds without you having to type them. - Structured fibre-composition editor keeps percentage-and-part data clean (e.g. "upper body 95% cotton organic 5% elastane / lining 100% recycled polyester") instead of free-text JSON. - Worn Wear / repair-programme URLs are discovered and attached automatically — reviewers just approve. - OEKO-TEX STANDARD 100, bluesign, GOTS, Fair Trade, GRS / RCS / RWS certifications pre-validated as enums so your answers match regulator vocabularies and don't fail mapping at audit. - Multilingual public passport — 24 EU languages, care symbols rendered from the structured care-instructions field, so the label print never falls behind language coverage. - Supplier portal for fields only the mill or dyer knows (dye method, water usage litres/kg, microplastics-mitigation, scope-1 emissions of the wet-processing site) — they fill via a token-linked form, no TracePass account needed. - As a brand or importer, upload one tech pack and we create the DPP you're legally responsible for — even if the contract manufacturer abroad hasn't produced one. Every field has source + confidence + audit trail, so your QA can review before publishing. - NFC-ready — link an NFC tag in the care label so scans resolve even after the printed QR fades from repeated washing. ## What the template covers - Fibre composition (structured: fibre type + % + garment part, supports multi-component pieces like a lined jacket with separate shell / lining / insulation fibres) - Country of manufacture + per-stage origins (fibre spinning, fabric weaving / knitting, wet processing, cut-make-trim assembly) - Recycled-content % per fibre with verification scheme (GRS / RCS / SCS / brand-internal) - Chemistry: REACH SVHC declaration, ZDHC MRSL conformance level, restricted-substance limits per market - Care + repair + take-back + recyclability — including spare-part availability, recycling stream classification (mechanical, chemical, downcycling) - Certifications (OEKO-TEX STANDARD 100, bluesign, GOTS, Fair Trade, GRS, RCS, RWS) as enum-validated fields with certificate number + expiry date - Microplastics-release assessment (qualitative bands + quantitative shedding tests where measured) ## FAQ ### We have 10,000 SKUs — is this practical at our scale? Yes. Product lines share most fields; variant SKUs inherit from the line and override size / colour. Batch creation plus the REST API means your PIM can push new SKUs at the same speed you release them. ### Our care labels are already multilingual. Does the DPP duplicate that work? No. The DPP stores care data once as structured codes. We render each of the 24 EU languages for you. Your label can link directly to the passport QR instead of printing care text in 10 languages. ### How do we get fibre-composition data from our dyeing mill? Supplier portal: we email a token-linked form; the mill fills fibre + dye-process fields without needing a TracePass account. You approve their inputs in the normal review flow. ### We import garments made by contract manufacturers in Bangladesh / Vietnam / Türkiye — they have no DPP. Are we covered? Yes. Under ESPR the importer placing the textile on the EU market is the responsible economic operator, so the DPP obligation lands on you regardless of whether the contract manufacturer produces one. Upload the tech pack plus any supplier-supplied data (test reports, certifications, fibre composition) and we draft the full passport. The AI agent flags missing fields and emails the supplier a token-linked form for the gaps; you approve before publish. Same workflow whether you're a brand, distributor, or pure importer — the passport carries your legal-entity details, not the OEM's. ### Do you support EPCIS for multi-tier supply-chain traceability? Yes — full GS1 EPCIS 2.0 (export, capture and query) included on every paid plan. Any passport's supply-chain, service, and ownership events serialise as a standards-valid EPCIS 2.0 document, advertised on the GS1 Digital Link QR so an EPCIS-aware system discovers the event history automatically. For multi-tier chains, the Capture interface lets your suppliers and ERP systems push events in, and our AI agent drafts events from datasheets for your review. Volume meter scales by tier (Basic 1k events/mo up to Pro 10M, unlimited on Enterprise). EPCIS is the recommended traceability vehicle for ESPR Article 5(5)(o). --- --- title: Electronics Passports — generated from your EPREL entry + spec sheets description: 167 electronics-DPP fields, filled from data you already have. TracePass reuses your EPREL registration and spec sheets — WEEE, RoHS, and CE in one place. canonical: "https://www.tracepass.eu/electronics" locale: en source: "https://www.tracepass.eu/electronics" --- # Electronics Passports — generated from your EPREL entry + spec sheets > 167 electronics-DPP fields, filled from data you already have. TracePass reuses your EPREL registration and spec sheets — WEEE, RoHS, and CE in one place. Your products already have EPREL entries, CE test reports, and spec sheets. TracePass reads them, fills 167 fields across ESPR + EPREL + WEEE + RoHS, and hunts down your DoC and support pages automatically. ## Who it's for Consumer electronics, ICT hardware, display, imaging, and networking-equipment brands plus their EU importers. ## How TracePass helps - Research agent pulls EPREL QR codes + registration numbers straight into the passport — no copy-paste. - Support / spare-parts / repair pages discovered automatically and saved as evidence-backed URLs. - Structured SVHC list editor (array of substances with CAS + concentration + use) instead of free text. - URL-hunt pass explicitly targets `declarationOfConformityUrl`, `repairInstructionsUrl`, `recyclingInfoUrl` — the fields that trip up research agents on other platforms. - Multi-variant support: define a product line once, auto-generate 20 SKU passports with variant-specific differences (storage, colour, region). - Firmware-update policy as a first-class field — declare your guaranteed security-update window and have it surface on the public passport. - Confidence + source + audit per field so your compliance team can sign off efficiently. ## What the template covers - EPREL registration + energy class - RoHS + REACH SVHC disclosure - Repairability index + spare-parts availability window - Software-update policy + minimum-support years - WEEE collection scheme + recyclability - Packaging composition - Certifications (CE, Energy Star, TCO, EPEAT) ## FAQ ### Does TracePass duplicate our EPREL entry? No — it reuses it. Your EPREL registration number + URL + label image become passport fields. One source of truth. ### Our product has 20 variants (colour / storage / region). Do we need 20 passports? One per SKU placed on market. You define the product line once with shared fields; we auto-generate per SKU passports where only the variant-specific fields differ. ### What about products that don't need CE marking, like certain cables? Save the CE-marking field as false with evidence, and we declare the exemption on the public passport. We're explicitly taught to handle not-applicable cases rather than leaving fields blank. --- --- title: Construction Passports — your DoP and EPD, structured description: Turn your DoP and EN 15804 EPD into a CPR-compliant DPP. TracePass fills 49 construction-product fields with attachable evidence and a public viewer. canonical: "https://www.tracepass.eu/construction" locale: en source: "https://www.tracepass.eu/construction" --- # Construction Passports — your DoP and EPD, structured > Turn your DoP and EN 15804 EPD into a CPR-compliant DPP. TracePass fills 49 construction-product fields with attachable evidence and a public viewer. Upload your Declaration of Performance and EN 15804 EPD. TracePass structures them into 49 CPR-ready fields, hosts the PDFs as evidence, and publishes a per-batch passport you can QR-label at the factory gate. ## Who it's for Manufacturers of insulation, windows, doors, plasterboard, concrete, structural steel, glazing, roofing, and sanitary products under harmonised technical specifications. ## How TracePass helps - Attach your existing DoP PDF; we read it for essential-characteristics values and hold the PDF as evidence per field. - EPD lookup from ECO Platform + manufacturer sustainability pages fills carbon footprint + lifecycle data automatically. - Fire / reaction / VOC class as structured enum fields — not free text — so regulators parse them reliably. - When your product doesn't have a manufacturer-specific EPD yet, we attach the category-default EPD with clear provenance so the passport is still compliant during transition. - Batch-level passports (not per-item): one DPP per production batch with the batch number as serial. Matches how the industry already tracks. - Field coverage mapped to the Construction Products Regulation (Regulation (EU) 2024/3110) Annex III — so every essential characteristic the regulation requires has a slot in the schema, not a free-text catch-all. ## What the template covers - DoP + essential characteristics (per harmonised standard) - Fire reaction + fire resistance class - VOC emissions + dangerous-substance release - Thermal / acoustic / mechanical performance - EN 15804 EPD carbon footprint + lifecycle - Recycled + bio-based content % - Installation + maintenance URLs ## FAQ ### Most small manufacturers don't have EN 15804 EPDs yet. Can we still be compliant? Yes. The template falls back to category-average EPD values (from ECO Platform) with explicit provenance in the evidence field. When your own EPD arrives, you replace the value and the audit trail records the upgrade. ### One passport per batch or per product family? Per batch — that's how construction already tracks. Declaration-of-Performance numbers usually change per batch anyway. TracePass stores the batch number on each passport and the product-family metadata on the shared product record. ### Does the construction DPP replace our Declaration of Performance, or is it a separate thing we now have to maintain twice? It doesn't replace the DoP — under the Construction Products Regulation (CPR, Reg (EU) 2024/3110) the DPP becomes the digital carrier that makes your DoP and EN 15804 EPD machine-readable and publicly accessible behind a GS1 Digital Link QR. TracePass reads your existing DoP and EPD once and structures them into the 49 CPR fields, so you maintain the source documents you already issue, not a second parallel dataset. When a value changes, you update it in one place and the published passport reflects it. ### If the AI fills our declared performance values from the DoP, who's accountable when a number is wrong? You are — TracePass never publishes anything on its own. The AI proposes each of the 49 fields with a confidence score and a link back to the exact DoP or EN 15804 EPD page it pulled the value from, and nothing goes live until you review and approve it. That source attribution means your compliance reviewer can verify every declared performance value against the original document instead of trusting a black box, which is exactly the audit trail a CPR market-surveillance check expects. --- --- title: Steel Passports — your CBAM + datasheets, one pipeline description: Already report CBAM emissions? Reuse that data. TracePass fills 84 steel-DPP fields — grade, chemistry, mechanicals, scope 1/2 emissions — from one upload. canonical: "https://www.tracepass.eu/iron-steel" locale: en source: "https://www.tracepass.eu/iron-steel" --- # Steel Passports — your CBAM + datasheets, one pipeline > Already report CBAM emissions? Reuse that data. TracePass fills 84 steel-DPP fields — grade, chemistry, mechanicals, scope 1/2 emissions — from one upload. You're already compiling CBAM embedded-emissions data. TracePass reuses it as structured fields in your steel DPP, adds grade / chemistry / mechanicals from the mill datasheet, and publishes a batch-level passport per heat. ## Who it's for Steel mills, rerollers, distributors, and downstream converters placing steel coils, sheets, long products, pipes, or wires on the EU market. ## How TracePass helps - Research agent reads SSAB / ArcelorMittal / TATA / grade datasheets — fills composition, mechanicals, and typical grade values in seconds. - CBAM fields (scope 1, scope 2, precursor emissions, grid intensity) as first-class structured data — the same numbers feed your DPP and your quarterly CBAM return. - Heat-number + batch-number lineage built-in, because that's how the industry already tracks. - Inspection-certificate URI field with evidence capture — point at the EN 10168 cert and we keep it attached to every coil passport. - Corporate sustainability-report metrics (recycled scrap %, EAF vs BOF) filled from your existing ESG disclosures. ## What the template covers - Grade + EN designation - Chemical composition per element - Mechanical properties (yield, tensile, elongation, hardness) - Heat + batch number, inspection-cert URI - CBAM embedded emissions (scope 1 / 2 / precursor) - Electricity grid intensity, kWh/tonne - Recycled (scrap) content % + facility type ## FAQ ### When will a steel Digital Product Passport be mandatory? No ESPR delegated act for iron & steel has been adopted yet. The indicative timeline from the ESPR Working Plan (COM(2025) 187 final, CELEX 52025DC0187 — a Commission Communication adopted 16 April 2025, not a binding act) points to a delegated act around Q4 2026 and a mandatory DPP from approximately 2028. Treat those as best-estimate dates; the obligation only becomes firm when the delegated act is formally adopted. Note that CBAM (Regulation (EU) 2023/956) already requires embedded-emissions data for steel imports today — that data is a natural head start for the future DPP. ### Can we avoid double data-entry between DPP and our CBAM reports? That's the point. TracePass stores CBAM fields as structured data on each passport. Export per-batch CBAM contribution for your quarterly return from the same source your DPP reads from. ### One passport per coil is a lot. Is there a less granular option? Passports are per heat or per batch, not per coil — industry practice. Each physical coil carries a QR back to its heat-level passport. Typical throughput: one passport covers 20–40 tonnes. ### Can you trace the production route — smelting, rolling, finishing — as EPCIS events? Yes. Each production step serialises as an EPCIS 2.0 TransformationEvent — smelting, casting, rolling, finishing — using GS1 Core Business Vocabulary where it exists and TracePass-published vocabulary URIs for the steel-specific steps it doesn't cover. The event history is a standards-valid EPCIS 2.0 document, included on every paid plan and advertised on the product's GS1 Digital Link QR. The Capture interface lets mills and processors push events directly; the query interface answers the EPCIS 2.0 query grammar via a self-hosted OpenEPCIS node. Volume meter scales by tier — high-throughput mill operators sit on Scale (1M events/mo) or Pro (10M); Enterprise is unlimited. EPCIS is the recommended traceability vehicle for ESPR Article 5(5)(o). --- --- title: Furniture Passports — built from your product catalog + sustainability hub description: "Furniture brands: upload product pages + FSC certs. TracePass fills 79 fields (wood origin, FSC CoC, formaldehyde) and publishes per-unit passports." canonical: "https://www.tracepass.eu/furniture" locale: en source: "https://www.tracepass.eu/furniture" --- # Furniture Passports — built from your product catalog + sustainability hub > Furniture brands: upload product pages + FSC certs. TracePass fills 79 fields (wood origin, FSC CoC, formaldehyde) and publishes per-unit passports. Point TracePass at your IKEA-style product pages and corporate sustainability hub. We fill 79 fields covering wood origin, FSC Chain-of-Custody, formaldehyde class, upholstery chemistry, and repair/disassembly URLs. ## Who it's for Furniture manufacturers, brands, retailers, and importers — residential, office, and contract furniture; mattress producers. ## How TracePass helps - Research agent reads your product pages and corporate sustainability disclosures — fills primary material, intended use, maximum-user-weight automatically. - Formaldehyde emission class as an enum (E0 / E0.5 / E1) — no more inconsistent free text across your SKU list. - FSC / PEFC Chain-of-Custody certificate attached per wood input; EUDR-ready country-of-harvest + geolocation fields already in the template. - URL-hunt pass finds iFixit-style repair guides and manufacturer-hosted Declaration of Conformity PDFs. When you don't need a CE mark (upholstered residential furniture), we save `null` with evidence explaining the exemption. - Upholstery + foam composition as structured arrays — weight, material, treatment. - Designed for ESPR (Regulation (EU) 2024/1781) furniture-category coverage — durability, repairability, recycled content, and substances-of-concern reporting all sit in the schema and surface on the published passport. ## What the template covers - Wood species + country of harvest + FSC/PEFC CoC - Formaldehyde + VOC emission class - Upholstery / foam composition (structured) - Flame retardants + PBDE disclosure - Carbon footprint (lifecycle) - Repair + disassembly URLs - Take-back / second-hand programme ## FAQ ### We source timber from multiple mills — can we declare a mix? Yes. Wood-origin and supplier fields accept arrays. Combined with FSC mixed-credit accounting, that's a defensible declaration. ### Our upholstered residential furniture doesn't need a CE mark. Do we still have a DPP gap? The DoC-URL field saves as null-with-evidence (we write the exemption reason as the evidence text). Regulators see 'not applicable, per TSD scope' instead of an empty field. ### How does TracePass cover the EUDR timber due diligence side, not just the product passport? EUDR requires you to keep deforestation-free evidence and geolocation data for the timber in your furniture, which goes beyond the published DPP itself. TracePass lets you upload your existing due-diligence documents and supplier declarations, and the AI extracts the wood-origin and chain-of-custody fields with a confidence score and a link back to the source document. You review and approve each field before it becomes part of the passport, so the EUDR evidence and the DPP stay consistent rather than living in two disconnected systems. ### Our particleboard furniture has formaldehyde emission test reports — does TracePass read those into the right fields? Yes. You upload the formaldehyde emission test reports for your boards, and the AI extracts the emission-class values into the relevant DPP fields, attaching a confidence score and a link to the exact report it pulled each value from. Because emissions and wood-origin data often sit in separate lab and supplier documents, having every figure traced back to its source makes it far easier for you to verify, and for a market surveillance authority to trust, the published passport. --- --- title: Detergent Passports — for the one chemicals rule that is already law description: Detergents get a real digital product passport on 23 September 2029 under Reg (EU) 2026/405. Upload your SDS — TracePass fills the Annex VI dataset from it. canonical: "https://www.tracepass.eu/detergents" locale: en source: "https://www.tracepass.eu/detergents" --- # Detergent Passports — for the one chemicals rule that is already law > Detergents get a real digital product passport on 23 September 2029 under Reg (EU) 2026/405. Upload your SDS — TracePass fills the Annex VI dataset from it. Regulation (EU) 2026/405 creates a mandatory digital product passport for detergents and end-user surfactants from 23 September 2029 — Article 21, with the dataset in Annex VI. It is not an ESPR delegated act waiting to be written; it is adopted law with a date. TracePass reads your safety data sheet and fills the passport fields from it. ## Who it's for Manufacturers and importers of laundry and dishwasher detergents, cleaning products, and surfactants sold to end users in the EU. ## How TracePass helps - SDS PDF extraction: the AI reads sections 1–16 and fills composition, classification, hazard and safe-use fields automatically. - Annex VI Part A dataset modelled as distinct fields — trade name, UPI, manufacturer UOI, DPP service provider reference, traceability identifier, commodity code, and the full list of intentionally added substances identified per CLP Art. 18(3). - Banded ingredient content kept separate from the passport. The <5 % / 5–15 % / 15–30 % / ≥30 % ranges are an Annex V LABELLING duty, not passport data — Annex VI Part A carries no concentrations at all. We cite each to the annex that actually mandates it. - Intentionally added micro-organisms captured with genus, species and strain, as Annex VI Part A(i) requires for probiotic detergents. - ECHA SVHC candidate list checked at save time — substances flagged automatically with proof of the check. - Null-with-evidence saves for fields that do not apply to your product. 'Not applicable, per SDS section X' is a compliant answer, not a blank. ## What the template covers - Trade name + unique product identifier + packaging image - Manufacturer contact + unique operator identifier - Full list of intentionally added substances (CLP Art. 18(3)) - Intentionally added micro-organisms (genus / species / strain) - Surfactant, phosphate and phosphonate content bands (Annex V label) - Biodegradability of surfactants - CLP classification + hazard / precautionary statements + UFI ## FAQ ### Is the detergent passport actually law, or another 'expected' ESPR act? It is adopted law. Regulation (EU) 2026/405 was adopted on 11 February 2026 and applies from 23 September 2029. Article 21 requires the manufacturer to create a digital product passport before placing a detergent or end-user surfactant on the market, and Annex VI Part A sets the dataset. That is a different situation from most DPP categories, where the obligation still depends on an ESPR delegated act nobody has written yet. ### Do the ingredient percentage bands go in the passport? No, and this catches people out. The <5 % / 5–15 % / 15–30 % / ≥30 % bands are an Annex V labelling duty. Annex VI Part A — the passport dataset — carries no concentrations at all: point (h) is a full list of intentionally added substances identified per CLP Article 18(3). We model the banded values as label data and the substance list as passport data, and cite each to the annex that actually mandates it. ### We only sell industrial and institutional detergents. Does the same dataset apply? Lighter, in one specific way. Annex VI Part A states that the full substance list in point (h) does not apply to industrial and institutional detergents, or to surfactants, where the equivalent information is provided in a REACH Article 31 safety data sheet. The same carve-out exists for the label in Annex V. The rest of the passport dataset still applies. ### The SVHC candidate list changes twice a year. Will our fields silently fall out of date? TracePass structures SVHC and REACH data as distinct DPP fields with source attribution back to the originating SDS, so you always see which document a substance entry came from and when it was approved. When a candidate list update affects you, you re-run extraction on the relevant SDS and review the changed fields rather than rebuilding the passport. The AI flags low-confidence matches for your review, so you stay the decision-maker on every regulated substance entry. --- --- title: Paints & Coatings — structured data before the mandate description: No EU digital product passport is mandated for paints yet. Structure your VOC, REACH and CLP data now — so you are ready when one is. canonical: "https://www.tracepass.eu/paints-coatings" locale: en source: "https://www.tracepass.eu/paints-coatings" --- # Paints & Coatings — structured data before the mandate > No EU digital product passport is mandated for paints yet. Structure your VOC, REACH and CLP data now — so you are ready when one is. We will say this plainly: there is no EU digital product passport for paints and coatings, and none is scheduled. Directive 2004/42/EC requires a VOC content declaration in g/l on the label and creates no passport, and paints are not in the ESPR first working plan — only a preparatory-study candidate, with a mid-term review in 2028 at the earliest. What TracePass gives you today is your VOC, REACH and CLP data in one structured, exportable place, so the passport is a publish step rather than a project when it arrives. ## Who it's for Manufacturers and importers of decorative paints, varnishes and vehicle refinishing products placed on the EU market. ## How TracePass helps - SDS PDF extraction: the AI reads sections 1–16 and fills composition, classification, hazard and safe-use fields automatically. - VOC content and the Annex II limit for your product subcategory captured as separate fields, in g/l, including the ready-to-use value that Directive 2004/42/EC Art. 4(1) requires where solvent is added before use. - Every paint-specific field is offered, never mandated. Nothing in the template tells you the law demands a passport field it does not — the only required fields here are the REACH and CLP duties that bind any chemical mixture. - ECHA SVHC candidate list checked at save time — substances flagged automatically with proof of the check. - CLP pictograms + hazard and precautionary statements as enums — exact regulator vocabulary, no typos. - Structured and exportable from day one, so if an ESPR delegated act lands for paints you are mapping fields, not starting a data project. ## What the template covers - VOC content + Annex II limit value (g/l) - Ready-to-use VOC content where solvent is added - Product subcategory under Directive 2004/42/EC Annex I - Paint type, solvent type and coverage - CLP classification + hazard / precautionary statements - SVHC disclosure (ECHA Candidate List) - Substance / mixture identity (CAS / EC / IUPAC) + SDS URL ## FAQ ### Do we actually need a digital product passport for paints? Not today, and we are not going to tell you otherwise. Directive 2004/42/EC requires a VOC content declaration on the label and creates no passport. Paints appear in the ESPR working plan only as a candidate for a preparatory study, with a mid-term review in 2028 at the earliest, so a delegated act before roughly 2030 is unlikely. If a supplier tells you paints need a DPP now, ask them which article says so. ### Then why structure the data at all? Two reasons that pay off before any mandate. Your VOC, REACH and CLP data usually lives across SDS PDFs, spreadsheets and a PIM, and customers — especially public buyers applying green procurement criteria — increasingly ask for it in a form they can consume. Second, when a delegated act does land, the work is mapping existing fields rather than starting a data project under a deadline. ### How is the VOC limit handled when solvent is added before use? As a separate field. Directive 2004/42/EC Article 4(1) states that for products in Annex I to which solvents have to be added to make them ready for use, the Annex II limit applies to the ready-for-use condition. So we capture VOC content, the applicable Annex II limit for your subcategory, and the ready-to-use value as distinct fields rather than collapsing them into one number. ### Which fields here are actually required? Only the ones a real in-force instrument mandates: REACH safety data sheet content, CLP classification and hazard statements, SVHC disclosure, and basic manufacturer identification. Every paint-specific field — VOC values, paint type, solvent type, coverage — is offered and not required, because no instrument currently demands it in a passport. We would rather show you an honest empty field than a fake obligation. --- --- title: Packaging Passports — your PPWR data, structured description: "Meet PPWR obligations without the spreadsheet grind. Upload packaging specs — TracePass fills 66 fields: material, recyclability grade, recycled content, EPR." canonical: "https://www.tracepass.eu/packaging" locale: en source: "https://www.tracepass.eu/packaging" --- # Packaging Passports — your PPWR data, structured > Meet PPWR obligations without the spreadsheet grind. Upload packaging specs — TracePass fills 66 fields: material, recyclability grade, recycled content, EPR. You already track packaging material, recycled content, and EPR registration per SKU. TracePass structures that data into 66 PPWR-ready fields and generates per-format passports for every pack variant. ## Who it's for Packaging producers, fillers, and brand owners placing primary / secondary / tertiary packaging on the EU market — food, beverage, e-commerce, rigid plastics, flexibles, paper, glass, aluminium. ## How TracePass helps - Research agent reads Tetra Pak / CCEP / brand material-disclosure pages and fills material composition, recyclability grade, recycled-content %. - Structured material-composition editor (% per material + functional layer) instead of free text that drifts SKU-to-SKU. - EPR scheme as an enum per Member State (PRO Europe, DSD, Valorie, CITEO, etc.) — producer registration number captured as structured data. - Batch creation scales to the distributor use case: thousands of SKU-variant passports from one product-line template. - Recyclability-grade field is future-proof — current (national or voluntary) grade now, ready to update when PPWR harmonised criteria arrive. - Built against Regulation (EU) 2025/40 (the Packaging and Packaging Waste Regulation, PPWR) — recyclability classes, minimum-recycled-content thresholds per material, and reuse-target reporting are all in the schema, ready for the staged enforcement dates. ## What the template covers - Material composition (structured by layer) - Recyclability grade (A / B / C) - Recycled-content % per material - Packaging weight, volume, pack-to-product ratio - Return-scheme + EPR scheme + producer reg number - Disposal + collection-points URL - Food-contact + restricted-substance disclosure ## FAQ ### We have 1,500 pack formats across the catalog. Feasible? Yes. Most packs share most fields — you define a product line once and batch-create the SKU-variant passports. Typical throughput: ~500 passports / minute on the batch API. ### Recyclability-grade A/B/C isn't finalised yet. What do we put? Your current voluntary or national grade with the evidence source. TracePass stamps every update so when PPWR harmonised criteria land, the transition is traceable — not a rewrite. ### How do we evidence the recycled-content percentage PPWR asks for, rather than just stating a number? Under PPWR (Reg (EU) 2025/40) recycled content is a regulated field, and a bare percentage with no source behind it is hard to defend in an audit. TracePass pulls the figure straight from your supplier datasheets, certificates and test reports, then records it with a confidence score and a link back to the exact source document. You review and approve each value before it publishes, so the number on the QR passport always traces to a file you can show a regulator. ### Does the packaging passport also cover our EPR registration, or is that a separate filing? EPR registration stays a separate obligation you handle with your national producer-responsibility scheme; TracePass does not file it for you. What it does is treat the EPR registration reference as one of the PPWR-regulated packaging fields, capturing it alongside material and recyclability so the passport stays consistent with what you have already registered. That way the QR passport and your EPR record point to the same packaging data instead of drifting apart over time. --- --- title: Toy Passports — from your LEGO-style product pages to a QR in minutes description: Upload your toy product pages + EN 71 test reports. TracePass fills 28 DPP fields — age grading, phthalates, materials, DoC URL — and ships QR-linked passports. canonical: "https://www.tracepass.eu/toys" locale: en source: "https://www.tracepass.eu/toys" --- # Toy Passports — from your LEGO-style product pages to a QR in minutes > Upload your toy product pages + EN 71 test reports. TracePass fills 28 DPP fields — age grading, phthalates, materials, DoC URL — and ships QR-linked passports. Toy DPPs are compact — 28 fields. TracePass reads your brand pages, fills age grading, materials, phthalate / SVHC claims, and finds your Declaration-of-Conformity URL. You review and publish. ## Who it's for Toy manufacturers, brand owners, importers, and distributors placing toys on the EU market. ## How TracePass helps - Research agent reads your product pages and brand hubs — pulls age grade, primary materials, safety warnings automatically. - EN 71-3 heavy-metal data as structured test result (standard version + elements tested + test-lab identity) — not free text. - URL-hunt pass finds manufacturer-hosted Declaration-of-Conformity PDFs without a manual search. - Null-with-evidence for 'no SVHC detected' and 'phthalate-compliant' claims — keeps the passport honest while declaring the check was made. - Smallest template in TracePass (28 fields) → fastest onboarding. A brand with 200 SKUs can be fully drafted in an afternoon. - Schema mapped to the Toy Safety Directive (Directive 2009/48/EC) essential safety requirements — chemical, physical, mechanical, electrical, hygiene + radioactivity all surface as structured fields on the passport. ## What the template covers - Age grading + safety warnings (per-market language) - Materials (primary + secondary) - EN 71-3 heavy-metal migration - Phthalate + SVHC compliance - CE marking + notified body - Declaration of Conformity URL - Disposal + recyclability ## FAQ ### The Toys DPP isn't mandatory yet. Why start now? Two reasons. (1) Early brand signal to retailers that you're compliance-ready. (2) When the revised Toy Safety Regulation kicks in, you're not scrambling to back-fill 28 fields across a 500-SKU catalog. ### Small studio, not ready for €350/mo. Options? Basic plan at €49/mo covers 25 passports — enough to pilot, with roughly 9 AI extractions a month included. The free tier includes one extraction too, so you can test the pipeline on a real test report before paying anything. Upgrade when the catalog, the deadline, or the extraction volume grows. ### Can the AI actually read our EN 71 test reports and phthalate results? Yes. You upload the existing EN 71 test reports and SDS-style chemical data, and the AI extracts the regulated values — heavy-metal migration, phthalate and SVHC results, age grading — into the matching DPP fields, each with a confidence score and a link back to the source page. Nothing publishes until you review and approve it, so a flagged or low-confidence field never slips through. AI extraction is included on every plan — the free tier covers one run, and higher tiers raise the monthly AI budget. ### We import toys rather than make them. Can we publish a passport from the supplier's DoC? Yes — importers and distributors are exactly who this serves. You upload what the manufacturer already gives you (the EN 71 test reports, the Declaration of Conformity, the CE documentation) and the AI maps it into the 28 DPP fields, including the DoC URL and age grading with the safety warnings per market language. The source attribution on each field keeps a clear audit trail back to the supplier document, which matters when you carry the EU responsibility for what you place on the market. --- --- title: FMCG Passports — from your existing labels and sustainability reports description: Skip the per-SKU data entry. TracePass turns labels and sustainability reports into 42 compliant DPP fields per SKU — food, beverage, cosmetic, household. canonical: "https://www.tracepass.eu/fmcg" locale: en source: "https://www.tracepass.eu/fmcg" --- # FMCG Passports — from your existing labels and sustainability reports > Skip the per-SKU data entry. TracePass turns labels and sustainability reports into 42 compliant DPP fields per SKU — food, beverage, cosmetic, household. FMCG products heading to the EU market need a 42-field Digital Product Passport covering EU ESPR sustainability data and Food Information to Consumers Regulation (EU) 1169/2011 mandatory labelling. TracePass reads your existing label text, sustainability reports, and PIM packaging specs and produces a compliant passport per SKU — no duplicate data entry. In TracePass onboarding, 60–70% of the required DPP data already exists in the business; the remaining gap is typically lifecycle carbon and supplier-sourced material declarations. ## Who it's for Producers, importers, and retailers of food, beverages, cosmetics, personal-care, and household-cleaning products placed on the EU market. ## How TracePass helps - Schema covers ESPR (Regulation (EU) 2024/1781) sustainability fields + FIC Regulation 1169/2011 mandatory food-information fields in one passport — so a single FMCG SKU satisfies both the consumer label and the regulatory DPP record from the same source data. - Open Food Facts + brand-page research fills ingredients, allergens, packaging material automatically — no duplicate data entry against your existing label. - Carbon-footprint pre-fill from brand sustainability reports where published — Coke, Nestlé, Unilever already disclose per-format numbers you can cite. - Structured ingredients list with allergen flags built-in; INCI for cosmetics, food names for food, disambiguated by subcategory. - Batch creation scales to retailers with thousands of SKUs per product family. - Packaging fields map to the separate Packaging template — one passport reference if your brand already created packaging DPPs. ## What the template covers - Brand + GTIN + subcategory - Ingredients (structured, allergen-flagged) - Net content + nutrition - Packaging material + recyclability - Country of origin + bottling - Shelf life + storage - Carbon footprint (lifecycle) - Certifications (Fairtrade / organic / FSC) ## FAQ ### What regulations does the FMCG Digital Product Passport cover? The TracePass FMCG template covers 42 mandatory fields spanning both EU ESPR (Regulation (EU) 2024/1781) sustainability data and the Food Information to Consumers Regulation (EU) 1169/2011 mandatory labelling — so a single passport per SKU satisfies both the consumer-facing label compliance and the regulatory DPP record from the same source data. ### Our label already lists ingredients. Do we enter them again? No. TracePass reads the label text (PDF, product-page, or printed label via image OCR) and extracts the ingredients list into structured form. Review once, stays structured forever. ### We have 5,000 SKUs in 40 countries. Multilingual labels, carbon per format. Can TracePass handle this? Product-line + variant architecture: one product line per recipe, variants per country / pack format. Shared fields propagate; country-specific fields (certifications, disposal instructions) are overrides. Carbon per format is a per-variant field. ### Half our DPP work is PPWR packaging data, not the product itself. Does TracePass cover the packaging overlap? Yes. For FMCG the DPP and PPWR packaging requirements overlap heavily, so packaging facts like material composition, recyclability and format weights belong in the same per-SKU passport as the product label and sustainability data. Upload your packaging specs and material declarations alongside the product datasheet, and the AI extracts both into the relevant fields with a confidence score and a link back to the source document. You review and approve before anything publishes, so the packaging data you sign off on is the data that goes live. ### Our compliance team won't let AI-generated label claims go public unchecked. Who is accountable for what gets published? You are, and TracePass is built around that. The AI never publishes on its own: it extracts each FMCG field from your own documents like labels, sustainability reports and material declarations, attaches a confidence score, and shows the exact source it pulled from, so your compliance team reviews every value against the original before approving. Nothing reaches the public GS1 Digital Link QR passport until a human signs it off. This keeps the speed of AI extraction while leaving the regulated claim firmly in your hands. --- --- title: Tyre Passports — your EPREL entry + type-approval, structured description: Tyre (tire) DPP software — reuse your EPREL entry + UNECE type-approval + datasheets. TracePass fills them, issues per-batch passports, QR on the sidewall. canonical: "https://www.tracepass.eu/tyres" locale: en source: "https://www.tracepass.eu/tyres" --- # Tyre Passports — your EPREL entry + type-approval, structured > Tyre (tire) DPP software — reuse your EPREL entry + UNECE type-approval + datasheets. TracePass fills them, issues per-batch passports, QR on the sidewall. Your tyres already have EPREL registration + UNECE type-approval + published rolling-resistance class. TracePass reuses all of it and adds lifecycle, rubber sourcing, and abrasion fields for a 95-field DPP. ## Who it's for Tyre (tire) manufacturers, importers, and distributors — passenger-car (C1), van (C2), truck / bus (C3), motorcycle, bicycle, and retreaded tyres. ## How TracePass helps - EPREL URL + registration number + label class pulled straight from Michelin / Continental / Bridgestone / your EPREL entry. - UNECE type-approval number as a structured field — not buried in a PDF. - Rubber-composition arrays + EUDR-ready deforestation-free declaration field. - Abrasion data structured as test-method + rate + index — matches emerging UNECE R117 tyre-wear rules. - Retreaded tyres supported with casing-origin + tread-material fields. - Built against the Tyre Labelling Regulation (Regulation (EU) 2020/740) — rolling resistance, wet grip, external rolling noise, and snow / ice grip classes all surface as structured enum fields on the published passport. ## What the template covers - Tyre size + load / speed index - EPREL URL + registration number - EU tyre-label classes (rolling resistance / wet grip / noise) - UNECE type-approval number - Natural + synthetic rubber % - Deforestation-free natural rubber sourcing - Abrasion rate + method + recyclability % - Inflation pressures + carbon footprint ## FAQ ### Does TracePass re-enter our EPREL data? No — reuses it. EPREL URL, registration number, and classes become structured passport fields. One source of truth. ### Retreaded tyres get their own DPP. Is that supported? Yes. Retread declarations (casing origin, tread material) are first-class fields in the template. ### We produce tyres in batches. Does one passport cover a whole production run, or do we need one per tyre? TracePass issues per-batch passports, so a single DPP covers an entire production run rather than every individual tyre. You enter the batch's rolling resistance, wet grip and other regulated values once, and the same GS1 Digital Link QR is moulded onto the sidewall of all tyres in that batch. There is no per-scan or per-SKU billing, so a batch with thousands of tyres costs the same to publish as a small one. ### How does the tyre DPP relate to our existing UNECE type-approval and Reg (EU) 2020/740 labelling data? The tyre passport sits on top of the same data you already hold for UNECE type-approval and the (EU) 2020/740 energy label, including rolling resistance and wet grip classes. TracePass lets you upload your type-approval documents and test reports, and the AI extracts the regulated fields with confidence scores and source attribution so you can see exactly where each value came from. You review and approve before publishing, so the DPP stays consistent with what you have already declared, rather than becoming a separate source of truth. --- --- title: Jewelry Passports — metal, gemstone, provenance, one record per piece description: "Jewelry brands: hallmarking, RJC CoC, Kimberley status, metal + gemstone provenance. TracePass fills 53 fields per piece and hosts per-unit passports." canonical: "https://www.tracepass.eu/jewelry" locale: en source: "https://www.tracepass.eu/jewelry" --- # Jewelry Passports — metal, gemstone, provenance, one record per piece > Jewelry brands: hallmarking, RJC CoC, Kimberley status, metal + gemstone provenance. TracePass fills 53 fields per piece and hosts per-unit passports. Point TracePass at your brand's product pages and sustainability hub. We fill 53 fields covering metal fineness, gemstone 4Cs, Kimberley / RJC status, and take-back programmes. ## Who it's for Jewelry brands, goldsmiths, retailers, and importers placing fine jewelry (gold / silver / platinum / diamond / gemstone) on the EU market. ## How TracePass helps - Research agent reads Pandora / Tiffany / brand sustainability hubs — pulls RJC status, recycled-metal %, hallmark authority automatically. - Gemstone-data editor (type / weight / 4Cs / origin / treatment) as structured fields — one schema for diamonds, coloured stones, and lab-grown. - Null-with-evidence for plain-metal pieces with no gemstone — declares 'metal-only construction' honestly instead of leaving fields empty. - Kimberley Process certificate + RJC Chain-of-Custody captured as structured evidence + URL. - Sterling-silver pieces get `additionalMetals: ['copper']` filled automatically — AI recognises S925 = 92.5% Ag + 7.5% Cu by definition. - Designed for ESPR (Regulation (EU) 2024/1781) jewellery-category coverage — recycled-metal %, gemstone provenance, durability, and end-of-life buy-back sit in the schema, ready for the delegated act when it lands. ## What the template covers - Primary metal + fineness (925 / 750 / 950) - Additional-metal alloy composition - Hallmark presence + authority - Gemstone type / weight / 4Cs / origin / treatment - Kimberley Process (diamonds) - RJC Chain-of-Custody - Fairmined / Fairtrade gold - Care + repair + take-back programmes ## FAQ ### Small artisan studio — 53 fields sounds heavy. Most fields auto-fill from metal + gemstone type. A sterling silver ring without gemstones needs ~15 fields actually filled; the rest save as null-with-evidence. Basic plan (€49/mo) covers artisan volumes. ### How do we share the Kimberley certificate? Upload the certificate PDF or paste the URL — TracePass stores it as structured evidence on the Kimberley-status field. Regulators and retailers can verify directly from the passport. ### We sell across several EU markets with different hallmarking rules — can one passport handle that? Yes. TracePass records the hallmark presence and the assay/hallmark authority as separate fields, plus the metal fineness (925 / 750 / 950), so the same per-unit passport carries the evidence each member state expects. You review and approve the authority before publishing, and the GS1 Digital Link QR resolves to the same record wherever the piece is sold. ### Our gold is recycled and RJC-certified — how does the passport prove that without overclaiming? TracePass captures the RJC Chain-of-Custody status and recycled-metal percentage as structured fields, each backed by the source document or URL it was drawn from and a confidence score. Because every figure links to its evidence and you approve it before publishing, the passport states exactly what your certification supports — no Fairmined or recycled claim appears unless a source backs it. --- --- title: TracePass API documentation description: REST API reference for the TracePass Digital Product Passport platform. canonical: "https://www.tracepass.eu/docs" locale: en source: "https://www.tracepass.eu/docs" --- # TracePass API documentation > REST API reference for the TracePass Digital Product Passport platform. Reference for the TracePass REST API — products, Digital Product Passports, parties, batches, and the JSON-LD tenant export. ## Quickstart Create your first passport in five minutes — register, mint an API key, post a single passport, scan the QR. - [Quickstart](https://www.tracepass.eu/docs/quickstart.md) ## Authentication Two auth methods — API key (Bearer) and OAuth 2.0 with PKCE — plus Idempotency-Key for safe retries and per-plan rate limits on the v1 surface. - [Authentication](https://www.tracepass.eu/docs/authentication.md) ## Passports Create, update, suspend, archive, and bulk-import Digital Product Passports. Includes the parties block for economic-operator chains. - [Create a passport](https://www.tracepass.eu/docs/create-passport.md) - [Get a single passport](https://www.tracepass.eu/docs/get-passport.md) - [Render the passport QR](https://www.tracepass.eu/docs/passport-qr.md) - [Check passport compliance](https://www.tracepass.eu/docs/passport-compliance.md) - [Check passport registry readiness](https://www.tracepass.eu/docs/passport-registry-readiness.md) - [List passports](https://www.tracepass.eu/docs/list-passports.md) - [Update one field on a passport](https://www.tracepass.eu/docs/update-field.md) - [Upsert an economic-operator party](https://www.tracepass.eu/docs/upsert-party.md) - [Suspend a passport](https://www.tracepass.eu/docs/suspend-passport.md) - [Archive a passport (irreversible)](https://www.tracepass.eu/docs/archive-passport.md) - [Delete a passport permanently](https://www.tracepass.eu/docs/delete-passport.md) - [Batch-create passports](https://www.tracepass.eu/docs/batch-create-passports.md) ## Products The catalog layer — products, images, batches. One product can have many passports (one per serialised unit). - [Create a product](https://www.tracepass.eu/docs/create-product.md) - [Get a single product](https://www.tracepass.eu/docs/get-product.md) - [List products](https://www.tracepass.eu/docs/list-products.md) - [Update a product](https://www.tracepass.eu/docs/update-product.md) - [Upload a product image](https://www.tracepass.eu/docs/upload-product-image.md) - [Archive a product](https://www.tracepass.eu/docs/archive-product.md) - [Delete a product permanently](https://www.tracepass.eu/docs/delete-product.md) ## Templates The DPP category field schemas — discover what a compliant passport in each category requires before you build it: field counts and the governing regulation. - [List category templates](https://www.tracepass.eu/docs/list-templates.md) - [Get a category template](https://www.tracepass.eu/docs/get-template.md) ## Webhooks HMAC-signed event delivery for passport lifecycle events. Retry ladder, signature verification, replay protection. - [Webhooks](https://www.tracepass.eu/docs/webhooks.md) ## Exports Bulk JSON-LD tenant export — every product, passport, and template you own as one canonical document. - [Bulk JSON-LD tenant export](https://www.tracepass.eu/docs/tenant-export.md) ## EPCIS 2.0 GS1 EPCIS 2.0 supply-chain events — export a passport's event history, capture events from partners and ERP systems, and query the event store. - [Export a passport's EPCIS events](https://www.tracepass.eu/docs/passport-epcis-export.md) - [Capture EPCIS events](https://www.tracepass.eu/docs/capture-events.md) - [Poll a capture job](https://www.tracepass.eu/docs/capture-job.md) - [Query EPCIS events](https://www.tracepass.eu/docs/query-events.md) ## MCP server MCP server — AI assistants (Claude, Cursor, IDE agents) manage products, passports, EPCIS events directly. Hosted endpoint or local npm package. - [MCP server](https://www.tracepass.eu/docs/mcp.md) ## n8n community node Automate TracePass workflows in n8n without code — products, passports, EPCIS events. Free community node, installable from any n8n instance. - [n8n community node](https://www.tracepass.eu/docs/n8n.md) ## Errors & rate limits Reference: HTTP status codes (4xx vs 5xx), error envelope shape, free-tier daily call caps, and 429 retry guidance with exponential back-off. - [Errors & rate limits](https://www.tracepass.eu/docs/errors.md) --- --- title: Archive a passport (irreversible) description: Irreversibly archive a passport. Public viewer 404s, GS1 Digital Link stops resolving. Fires passport.archived webhook. Only for unshipped products. canonical: "https://www.tracepass.eu/docs/archive-passport" locale: en source: "https://www.tracepass.eu/docs/archive-passport" --- # Archive a passport (irreversible) > Irreversibly archive a passport. Public viewer 404s, GS1 Digital Link stops resolving. Fires passport.archived webhook. Only for unshipped products. ```http POST /api/v1/passports/{id}/archive ``` **Irreversible.** Public viewer returns 404, the GS1 Digital Link URL stops resolving, the QR code dies for good. Use ONLY for products that never shipped — archiving a passport for a product already in customers' hands breaks every QR scan they'll ever make of it. There's no DELETE verb on purpose: too easy to misfire as a destructive action via curl typo or a misconfigured client. The HTTP method is POST and the path includes the literal `archive` segment — both intentional friction. Counts as one v1 write. Honours `Idempotency-Key`. Fires the `passport.archived` webhook. ## Parameters | Name | In | Type | Required | Description | | --- | --- | --- | --- | --- | | `Authorization` | header | string | yes | `Bearer ` — either a `tp_` API key (Developer → API Keys; simplest, for server-to-server) or an OAuth 2.0 access token (Developer → OAuth Apps; for user-authorized apps, scoped + revocable). The Authentication page has the full OAuth flow and scope list. | | `Idempotency-Key` | header | string | no | UUID v4. | | `id` | path | ObjectId | yes | Passport ID. | ## Examples ```bash curl -sS -X POST \ https://app.tracepass.eu/api/v1/passports/6650b2c3d4e5f6a7b8c9d0e1/archive \ -H "Authorization: Bearer tp_REDACTED_xxxxxxxxxxxx" ``` ```typescript await fetch( `https://app.tracepass.eu/api/v1/passports/${id}/archive`, { method: "POST", headers: { Authorization: `Bearer ${process.env.TRACEPASS_API_KEY}` }, }, ); ``` ```python import os, requests res = requests.post( f"https://app.tracepass.eu/api/v1/passports/{passport_id}/archive", headers={"Authorization": f"Bearer {os.environ['TRACEPASS_API_KEY']}"}, ) res.raise_for_status() ``` ## Responses ### 200 — Archived ```json { "_id": "6650b2c3d4e5f6a7b8c9d0e1", "status": "archived", "archivedAt": "2026-05-09T17:00:00.000Z" } ``` ### 422 — Already archived ```json { "error": "Passport already archived" } ``` ### 404 — Not found ```json { "error": "Passport not found" } ``` ## Related - [Suspend a passport (reversible)](https://www.tracepass.eu/docs/suspend-passport.md) - [Get passport](https://www.tracepass.eu/docs/get-passport.md) --- --- title: Archive a product description: Soft-archive a product — hidden from listings, blocks new passports. Existing passports keep resolving. Reversible. 409 if non-archived passports remain. canonical: "https://www.tracepass.eu/docs/archive-product" locale: en source: "https://www.tracepass.eu/docs/archive-product" --- # Archive a product > Soft-archive a product — hidden from listings, blocks new passports. Existing passports keep resolving. Reversible. 409 if non-archived passports remain. ```http POST /api/v1/products/{id}/archive ``` Soft-archive. `Product.status` flips to `archived`; the product disappears from default listings (still visible with the `?showArchived=true` filter). Existing passports keep resolving — archive blocks NEW passport creation against this product going forward, it doesn't break any QR already in customers' hands. Returns `409 Conflict` when any non-archived passport still references the product — archive every passport first, then re-call this endpoint. Available on every paid plan. Counts as one v1 write. Honours `Idempotency-Key`. There's no DELETE verb here at the same path: `DELETE /api/v1/products/{id}` is the hard-delete endpoint, with stricter eligibility (zero passports of any status). Archive is the safe-default cleanup verb. ## Parameters | Name | In | Type | Required | Description | | --- | --- | --- | --- | --- | | `Authorization` | header | string | yes | `Bearer ` — either a `tp_` API key (Developer → API Keys; simplest, for server-to-server) or an OAuth 2.0 access token (Developer → OAuth Apps; for user-authorized apps, scoped + revocable). The Authentication page has the full OAuth flow and scope list. | | `Idempotency-Key` | header | string | no | UUID v4. | | `id` | path | ObjectId | yes | Product ID. | ## Examples ```bash curl -sS -X POST \ https://app.tracepass.eu/api/v1/products/6650b2c3d4e5f6a7b8c9d0e1/archive \ -H "Authorization: Bearer tp_REDACTED_xxxxxxxxxxxx" ``` ```typescript await fetch( `https://app.tracepass.eu/api/v1/products/${id}/archive`, { method: "POST", headers: { Authorization: `Bearer ${process.env.TRACEPASS_API_KEY}` }, }, ); ``` ```python import os, requests res = requests.post( f"https://app.tracepass.eu/api/v1/products/{product_id}/archive", headers={"Authorization": f"Bearer {os.environ['TRACEPASS_API_KEY']}"}, ) res.raise_for_status() ``` ## Responses ### 200 — Archived ```json { "_id": "6650b2c3d4e5f6a7b8c9d0e1", "name": "Demo product", "status": "archived", "updatedAt": "2026-05-23T17:00:00.000Z" } ``` ### 409 — Active passports ```json { "error": "Cannot archive product with 3 active passport(s). Archive every passport first." } ``` ### 404 — Not found ```json { "error": "Product not found" } ``` ## Related - [Delete a product permanently](https://www.tracepass.eu/docs/delete-product.md) - [Update product](https://www.tracepass.eu/docs/update-product.md) --- --- title: Authentication description: Two auth methods — API key (Bearer) and OAuth 2.0 with PKCE — plus Idempotency-Key for safe retries and per-plan rate limits on the v1 surface. canonical: "https://www.tracepass.eu/docs/authentication" locale: en source: "https://www.tracepass.eu/docs/authentication" --- # Authentication > Two auth methods — API key (Bearer) and OAuth 2.0 with PKCE — plus Idempotency-Key for safe retries and per-plan rate limits on the v1 surface. TracePass v1 supports two auth methods. An **API key** (a static Bearer token) is the simplest — best for server-to-server and ERP integrations. **OAuth 2.0 with PKCE** is for third-party apps and AI assistants that act on a user's behalf with scoped, revocable access. Both arrive as a Bearer token in the standard `Authorization`header; every write also accepts an `Idempotency-Key`for safe retries. Available on every plan including Free. Daily call caps apply only to Free (100/day) and Basic (200/day); Starter and above are unlimited. ## API keys Mint keys at **Developer → API keys** in the dashboard. Keys are workspace-scoped: every key is tied to one workspace and inherits its plan, limits, and audit log. Keys carry the `tp_` prefix followed by an opaque random suffix — there's no separate live / test prefix, and no env-namespaced sandbox. Test against your Free or Basic workspace if you need a non-production environment. Pass the key as a Bearer token on every request: ```bash curl -sS https://app.tracepass.eu/api/v1/products \ -H "Authorization: Bearer tp_REDACTED_xxxxxxxxxxxx" ``` **Tip —** A leaked key is one click to revoke — open Developer → API keys, hit **Revoke**, and the key starts returning 401 within seconds. Audit-log entries for the key remain so you can reconcile what was written under it. ## OAuth 2.0 (user-authorized apps) When you're building an app that other TracePass users connect — or an AI assistant a user authorizes — use OAuth 2.0 instead of asking them to paste an API key. The user approves specific scopes on a consent screen; the access token they generate is limited to the intersection of their dashboard role and the scopes granted. Register your app at **Developer → OAuth Apps** (or programmatically via Dynamic Client Registration at `/api/oauth/register`). We support the **authorization-code flow with PKCE** — public clients (SPA / mobile / MCP) need no secret; confidential server-side clients get one. ### The flow Discovery metadata lives at `/.well-known/oauth-authorization-server` (RFC 8414). The short version: (1) send the user to `/api/oauth/authorize` with your `client_id`, `redirect_uri`, requested `scope`, `state`, and a PKCE `code_challenge` (`S256`); (2) they approve, and we redirect back with a single-use `code`; (3) exchange it at `/api/oauth/token` with your `code_verifier` for a 15-minute access token (plus a refresh token if `offline_access` was granted). Refresh tokens rotate on every use; revoke at `/api/oauth/revoke` (RFC 7009). ### Scopes Request only what your app needs — the consent screen shows the user exactly these. A write scope additionally requires the authorizing user to have a write-capable dashboard role, so a viewer who grants `passports:write` still can't write. API keys, by contrast, are all-or-nothing and ignore scopes. | Scope | Grants | | --------------- | ------------------------------------------- | | passports:read | View products and digital product passports | | passports:write | Create, update, and publish passports | | documents:read | Read uploaded documents and extractions | | documents:write | Upload documents and run AI extractions | | suppliers:read | View supplier requests | | suppliers:write | Create and manage supplier requests | | offline\_access | Issue a refresh token (stay connected) | **Tip —** Users see and disconnect the apps they've authorized under **Developer → OAuth Apps → Connected Apps**; disconnecting revokes the app's tokens immediately. You can delete your own registered apps from the same screen. ## Idempotency-Key Every `POST`, `PATCH`, and `DELETE` on the v1 surface accepts an `Idempotency-Key` header. Send a UUID v4 (or any opaque string ≤ 255 chars) per logical operation; the platform stores the first response for 24 hours and replays it if the same key + same workspace shows up again. Network retries become safe — you won't double-create a passport because your HTTP client retried on a transient 5xx. ```bash curl -sS https://app.tracepass.eu/api/v1/passports \ -H "Authorization: Bearer tp_REDACTED_xxxxxxxxxxxx" \ -H "Idempotency-Key: 7b4f1e2c-9a3d-4e5b-8c1a-2d3e4f5a6b7c" \ -H "Content-Type: application/json" \ -d '{ "productId": "...", "gs1": { "gtin": "...", "serialNumber": "..." } }' ``` Reusing the same key with a **different request body** returns`422 Unprocessable Entity` with `error: "Idempotency-Key has already been used with a different request body. Use a new key for the new request, or reuse the original body."` — the platform doesn't silently overwrite, because that's almost always a client bug. Generate a fresh key for genuinely new operations. ## Rate limits Two ceilings apply per UTC day, per workspace: ### 1\. v1 write budget — \`maxV1WritesPerDay\` Counts every `POST` / `PATCH` / `DELETE` on the v1 surface. Reads aren't budgeted on this counter. ### 2\. v1 passport-read budget — \`maxV1PassportsPerDay\` Counts every `GET` on the passport endpoints (single read + paginated list). Separate from the write budget so an ERP pushing updates doesn't starve your read quota and vice versa. | Plan | Writes / day | Passport reads / day | | ---------- | ------------ | -------------------- | | Free | 100 | 100 | | Basic | 200 | 200 | | Starter | Unlimited | Unlimited | | Growth | Unlimited | Unlimited | | Scale | Unlimited | Unlimited | | Pro | Unlimited | Unlimited | | Enterprise | Unlimited | Unlimited | When you hit either ceiling the response is `429 Too Many Requests` with a body like `{ "error": "API rate limit: 200 writes/day via /api/v1. Currently 200 today; requested 1. Retry tomorrow (UTC) or upgrade your plan." }`. The window resets at 00:00 UTC; we don't support rolling windows because they make the limit harder to reason about downstream. A separate quota — `maxDpps` — caps total active DPPs in your workspace and is enforced via a `402` response with an `overage_required` body when the plan supports per-passport overage. See the [Create a passport](/docs/create-passport) endpoint for the overage flow. **Need more headroom?** Either upgrade your plan in the dashboard (instant) or contact [support@tracepass.eu](mailto:support@tracepass.eu) for an Enterprise quote. We don't do per-scan billing on the public passport viewer — only writes via this API count. ## What we don't support (yet) The OAuth **client-credentials** grant (machine identity with no user) and IP allow-listing are on the roadmap but not shipped. For pure server-to-server access today, use an API key — mint one per integration so you can revoke at the integration level. --- --- title: Batch-create passports description: "Up to 100 passports per call. Per-item status in the response. Same overage flow as single-create (402 + confirmOverage:true). Idempotency-Key supported." canonical: "https://www.tracepass.eu/docs/batch-create-passports" locale: en source: "https://www.tracepass.eu/docs/batch-create-passports" --- # Batch-create passports > Up to 100 passports per call. Per-item status in the response. Same overage flow as single-create (402 + confirmOverage:true). Idempotency-Key supported. ```http POST /api/v1/passports/batch ``` Create up to 100 passports in one call. Each item carries the same body shape as the single-create endpoint (`{ productId, gs1: { gtin, serialNumber }, parties?, confirmOverage? }`). Partial-success per item — each gets its own status in the response array. The whole batch consumes N writes upfront against your daily-write budget; if that would overflow, the entire batch returns 429 (no partial billing). The same applies to the DPP overage flow at the batch level — when the DPP quota would be exceeded, the batch returns 402 with `overage_required` and `confirmOverage: true` accepts the overage charge for the whole batch. Idempotency-Key applies to the whole batch — replaying the same key returns the original full result array. Cap is 100 items per call (matches Stripe's batch ceiling so partial-success responses stay manageable). ## Parameters | Name | In | Type | Required | Description | | --- | --- | --- | --- | --- | | `Authorization` | header | string | yes | `Bearer ` — either a `tp_` API key (Developer → API Keys; simplest, for server-to-server) or an OAuth 2.0 access token (Developer → OAuth Apps; for user-authorized apps, scoped + revocable). The Authentication page has the full OAuth flow and scope list. | | `Idempotency-Key` | header | string | no | UUID v4 — applies to the whole batch. | | `passports` | body | Array (1-100) | yes | 1–100 passport objects, each in the single-create body shape. | ## Examples ```bash curl -sS -X POST https://app.tracepass.eu/api/v1/passports/batch \ -H "Authorization: Bearer tp_REDACTED_xxxxxxxxxxxx" \ -H "Idempotency-Key: 7b4f1e2c-9a3d-4e5b-8c1a-2d3e4f5a6b7c" \ -H "Content-Type: application/json" \ -d '{ "passports": [ { "productId": "6650a1b2c3d4e5f6a7b8c9d0", "gs1": { "gtin": "04012345000016", "serialNumber": "BP-48V-100-000001" } }, { "productId": "6650a1b2c3d4e5f6a7b8c9d0", "gs1": { "gtin": "04012345000016", "serialNumber": "BP-48V-100-000002" } }, { "productId": "6650a1b2c3d4e5f6a7b8c9d0", "gs1": { "gtin": "04012345000016", "serialNumber": "BP-48V-100-000003" } } ] }' ``` ```typescript import { randomUUID } from "node:crypto"; const passports = serials.map((serial) => ({ productId: "6650a1b2c3d4e5f6a7b8c9d0", gs1: { gtin: "04012345000016", serialNumber: serial }, })); const res = await fetch("https://app.tracepass.eu/api/v1/passports/batch", { method: "POST", headers: { Authorization: `Bearer ${process.env.TRACEPASS_API_KEY}`, "Idempotency-Key": randomUUID(), "Content-Type": "application/json", }, body: JSON.stringify({ passports }), }); const { results, summary } = await res.json(); ``` ```python import os, uuid, requests passports = [ {"productId": product_id, "gs1": {"gtin": gtin, "serialNumber": s}} for s in serials ] res = requests.post( "https://app.tracepass.eu/api/v1/passports/batch", headers={ "Authorization": f"Bearer {os.environ['TRACEPASS_API_KEY']}", "Idempotency-Key": str(uuid.uuid4()), "Content-Type": "application/json", }, json={"passports": passports}, ) res.raise_for_status() body = res.json() print(body["summary"]) # {created, errors, total} ``` ## Responses ### 200 — Partial success ```json { "results": [ { "index": 0, "status": "created", "data": { "_id": "...", "gs1": { "...": "..." }, "status": "draft" } }, { "index": 1, "status": "error", "error": "Serial number already exists for this GTIN" }, { "index": 2, "status": "created", "data": { "...": "..." } } ], "summary": { "created": 2, "errors": 1, "total": 3 } } ``` ### 400 — Validation ```json { "error": "Validation error", "hint": "Send up to 100 passports per call." } ``` ### 402 — Overage required ```json { "error": "overage_required", "planLimit": 1000, "currentUsage": 950, "requested": 100, "extraPriceCents": 75, "message": "Batch would exceed DPP quota by 50. Retry with { confirmOverage: true } to accept the overage charge." } ``` ### 429 — Rate limit ```json { "error": "API rate limit: 200 writes/day via /api/v1. Currently 180 today; requested 25. Retry tomorrow (UTC) or upgrade your plan." } ``` ## Related - [Create a single passport](https://www.tracepass.eu/docs/create-passport.md) --- --- title: Capture EPCIS events description: GS1 EPCIS 2.0 capture endpoint. Submit ObjectEvent / TransformationEvent / AggregationEvent etc. via application/ld+json. Returns a capture-job id. canonical: "https://www.tracepass.eu/docs/capture-events" locale: en source: "https://www.tracepass.eu/docs/capture-events" --- # Capture EPCIS events > GS1 EPCIS 2.0 capture endpoint. Submit ObjectEvent / TransformationEvent / AggregationEvent etc. via application/ld+json. Returns a capture-job id. ```http POST /api/v1/epcis/capture ``` The GS1 EPCIS 2.0 Capture interface. Submit supply-chain events from partners, ERP systems, or shop-floor scanners and TracePass attaches them to the matching passports. The request body accepts four shapes: a full `EPCISDocument`, an `EPCISQueryDocument`, a single bare event, or a bare JSON-LD array of events. Send `Content-Type: application/ld+json`. Every event is validated against the EPCIS 2.0 schema, then each EPC in `epcList` / `quantityList` is resolved to a passport in your workspace. Valid events are stored and the call returns `202 Accepted` with a `captureJobId` — capture is asynchronous per the EPCIS 2.0 capture model, so poll the job (see `capture-job`) for the final outcome. Counts as one v1 write regardless of how many events the document carries. Volume metered against the plan's `maxEpcisEventsPerMonth` (1,000 on Basic up to 10,000,000 on Pro, 10 on Free, unlimited on Enterprise). When a single capture call would push the period total over the cap on a paid plan the endpoint returns `402 {"error":"epcis_events_overage_required"}` with `overageBlocks` + `totalOverageCents` populated — retry the same call with `"confirmOverage":true` in the body to opt into the per-1,000-event block charge. On Free the same overflow returns `402 {"error":"epcis_events_hard_block"}` with an upgrade CTA; no per-block overage path. The call is idempotent two ways — supply an `Idempotency-Key` header to make the whole request replay-safe, and the platform additionally de-duplicates on each event's EPCIS `eventID`, so re-sending a document that overlaps a prior capture will not double-store events or double-count against the meter. ## Parameters | Name | In | Type | Required | Description | | --- | --- | --- | --- | --- | | `Authorization` | header | string | yes | `Bearer ` — either a `tp_` API key (Developer → API Keys; simplest, for server-to-server) or an OAuth 2.0 access token (Developer → OAuth Apps; for user-authorized apps, scoped + revocable). The Authentication page has the full OAuth flow and scope list. | | `Idempotency-Key` | header | string | no | UUID v4 — replaying the same key returns the original capture result. Independent of the per-event `eventID` de-duplication. | | `body` | body | EPCISDocument \| EPCISQueryDocument \| EPCISEvent \| EPCISEvent\[\] | yes | JSON-LD payload sent with `Content-Type: application/ld+json`. Accepts a full EPCISDocument, an EPCISQueryDocument, a bare event, or a bare array of events. | | `confirmOverage` | body | boolean | no | Opt-in flag to accept the per-1,000-event block overage charge when a capture would exceed `maxEpcisEventsPerMonth`. Without it, the first over-cap call returns 402 with `overageBlocks` + `totalOverageCents` in the body — re-send the same payload with `confirmOverage:true` to acknowledge the charge and proceed. Free tier has no overage path; the upgrade-required hard block ignores this flag. | ## Examples ```bash curl -sS -X POST https://app.tracepass.eu/api/v1/epcis/capture \ -H "Authorization: Bearer tp_REDACTED_xxxxxxxxxxxx" \ -H "Idempotency-Key: 7b4f1e2c-9a3d-4e5b-8c1a-2d3e4f5a6b7c" \ -H "Content-Type: application/ld+json" \ -d '{ "@context": "https://ref.gs1.org/standards/epcis/2.0.0/epcis-context.jsonld", "type": "EPCISDocument", "schemaVersion": "2.0", "creationDate": "2026-05-09T12:00:00.000Z", "epcisBody": { "eventList": [ { "type": "ObjectEvent", "eventID": "ni:///sha-256;9f86d0...?ver=CBV2.0", "eventTime": "2026-05-09T11:58:00.000Z", "eventTimeZoneOffset": "+02:00", "epcList": ["https://id.tracepass.eu/p/01/04012345000016/21/BP-48V-100-000001"], "action": "OBSERVE", "bizStep": "shipping", "bizLocation": { "id": "https://id.tracepass.eu/loc/acme-batteries-de" } } ] } }' ``` ```typescript import { randomUUID } from "node:crypto"; const epcisDocument = { "@context": "https://ref.gs1.org/standards/epcis/2.0.0/epcis-context.jsonld", type: "EPCISDocument", schemaVersion: "2.0", creationDate: new Date().toISOString(), epcisBody: { eventList: [ { type: "ObjectEvent", eventID: "ni:///sha-256;9f86d0...?ver=CBV2.0", eventTime: "2026-05-09T11:58:00.000Z", eventTimeZoneOffset: "+02:00", epcList: ["https://id.tracepass.eu/p/01/04012345000016/21/BP-48V-100-000001"], action: "OBSERVE", bizStep: "shipping", bizLocation: { id: "https://id.tracepass.eu/loc/acme-batteries-de" }, }, ], }, }; const res = await fetch("https://app.tracepass.eu/api/v1/epcis/capture", { method: "POST", headers: { Authorization: `Bearer ${process.env.TRACEPASS_API_KEY}`, "Idempotency-Key": randomUUID(), "Content-Type": "application/ld+json", }, body: JSON.stringify(epcisDocument), }); if (res.status !== 202) throw new Error(`Capture failed: ${res.status}`); const { captureJobId } = await res.json(); // poll capture-job next ``` ```python import os, uuid, requests epcis_document = { "@context": "https://ref.gs1.org/standards/epcis/2.0.0/epcis-context.jsonld", "type": "EPCISDocument", "schemaVersion": "2.0", "creationDate": "2026-05-09T12:00:00.000Z", "epcisBody": { "eventList": [ { "type": "ObjectEvent", "eventID": "ni:///sha-256;9f86d0...?ver=CBV2.0", "eventTime": "2026-05-09T11:58:00.000Z", "eventTimeZoneOffset": "+02:00", "epcList": ["https://id.tracepass.eu/p/01/04012345000016/21/BP-48V-100-000001"], "action": "OBSERVE", "bizStep": "shipping", "bizLocation": {"id": "https://id.tracepass.eu/loc/acme-batteries-de"}, } ] }, } res = requests.post( "https://app.tracepass.eu/api/v1/epcis/capture", headers={ "Authorization": f"Bearer {os.environ['TRACEPASS_API_KEY']}", "Idempotency-Key": str(uuid.uuid4()), "Content-Type": "application/ld+json", }, json=epcis_document, ) res.raise_for_status() capture_job_id = res.json()["captureJobId"] # poll capture-job next ``` ## Responses ### 202 — Accepted ```json { "captureJobId": "6650c4d5e6f7a8b9c0d1e2f3", "status": "success", "eventCount": 1, "capturedCount": 1, "errors": [] } ``` ### 401 — Missing API key ```json { "error": "Missing or invalid API key" } ``` ### 402 — Subscription required ```json { "error": "Active paid subscription required" } ``` ### 403 — Add-on not enabled ```json { "error": "epcis_capture_not_available" } ``` ## Related - [Poll a capture job](https://www.tracepass.eu/docs/capture-job.md) - [Query EPCIS events](https://www.tracepass.eu/docs/query-events.md) --- --- title: Poll a capture job description: "Poll an EPCIS capture job's status, eventCount, capturedCount, and per-event errors[]. Use the captureJobId returned by the capture POST." canonical: "https://www.tracepass.eu/docs/capture-job" locale: en source: "https://www.tracepass.eu/docs/capture-job" --- # Poll a capture job > Poll an EPCIS capture job's status, eventCount, capturedCount, and per-event errors[]. Use the captureJobId returned by the capture POST. ```http GET /api/v1/epcis/capture/{id} ``` Reads the status of an asynchronous EPCIS capture job — the read side of the EPCIS 2.0 capture model. `POST /api/v1/epcis/capture` returns `202 Accepted` with a `captureJobId`; pass that id here to follow the job until it reaches a terminal state. The response carries `status`, the `eventCount` submitted, the `capturedCount` stored so far, and a per-event `errors` array (`{index, message}`) for any events that failed validation or EPC resolution. `createdAt` and `finishedAt` bracket the run — `finishedAt` is `null` while the job is still in progress. Counts as one read. Plan gate: EPCIS is included on every paid plan today, so the 403 path is only reachable on workspaces whose `epcisCaptureEnabled` flag has been disabled via per-tenant override. Unknown or expired job id returns `404`. ## Parameters | Name | In | Type | Required | Description | | --- | --- | --- | --- | --- | | `Authorization` | header | string | yes | `Bearer ` — either a `tp_` API key (Developer → API Keys; simplest, for server-to-server) or an OAuth 2.0 access token (Developer → OAuth Apps; for user-authorized apps, scoped + revocable). The Authentication page has the full OAuth flow and scope list. | | `id` | path | string | yes | The capture job id returned by `POST /api/v1/epcis/capture`. | ## Examples ```bash curl -sS https://app.tracepass.eu/api/v1/epcis/capture/6650c4d5e6f7a8b9c0d1e2f3 \ -H "Authorization: Bearer tp_REDACTED_xxxxxxxxxxxx" ``` ```typescript const res = await fetch( `https://app.tracepass.eu/api/v1/epcis/capture/${captureJobId}`, { headers: { Authorization: `Bearer ${process.env.TRACEPASS_API_KEY}` } }, ); if (res.status === 404) throw new Error("Capture job not found"); const job = await res.json(); if (job.status === "success") { console.log(`Captured ${job.capturedCount}/${job.eventCount} events`); } else if (job.status === "failed") { console.error(job.errors); // [{ index, message }] } ``` ```python import os, requests res = requests.get( f"https://app.tracepass.eu/api/v1/epcis/capture/{capture_job_id}", headers={"Authorization": f"Bearer {os.environ['TRACEPASS_API_KEY']}"}, ) res.raise_for_status() job = res.json() if job["status"] == "success": print(f"Captured {job['capturedCount']}/{job['eventCount']} events") elif job["status"] == "failed": print(job["errors"]) # [{ "index": ..., "message": ... }] ``` ## Responses ### 200 — OK ```json { "captureJobId": "6650c4d5e6f7a8b9c0d1e2f3", "status": "success", "eventCount": 12, "capturedCount": 12, "errors": [], "createdAt": "2026-05-09T12:00:00.000Z", "finishedAt": "2026-05-09T12:00:03.420Z" } ``` ### 401 — Missing API key ```json { "error": "Missing or invalid API key" } ``` ### 403 — Add-on not enabled ```json { "error": "epcis_capture_not_available" } ``` ### 404 — Not found ```json { "error": "Capture job not found" } ``` ## Related - [Capture EPCIS events](https://www.tracepass.eu/docs/capture-events.md) --- --- title: Create a passport description: "Create one passport bound to a product. GTIN + serial uniqueness enforced. 402 overage_required when over cap; confirmOverage:true to accept the charge." canonical: "https://www.tracepass.eu/docs/create-passport" locale: en source: "https://www.tracepass.eu/docs/create-passport" --- # Create a passport > Create one passport bound to a product. GTIN + serial uniqueness enforced. 402 overage_required when over cap; confirmOverage:true to accept the charge. ```http POST /api/v1/passports ``` Create a single Digital Product Passport. The passport is bound to a product (productId) and identified by a GS1 GTIN + serial number that's unique within that GTIN. New passports start in `draft` status — fields are populated via subsequent PATCH calls and the passport is published from the dashboard once review is complete. GTIN must be 14 digits with a valid GS1 check digit and not yet registered to another tenant. Counts as one v1 write AND consumes one DPP slot from your plan's `maxDpps` quota — when that quota is exhausted and your plan supports overage, the call returns 402 with an `overage_required` body; retry with `confirmOverage: true` to accept the per-passport charge. Honours the optional `Idempotency-Key` header — the platform replays the original 201 response for 24 hours on the same key, so a network retry is safe. ## Parameters | Name | In | Type | Required | Description | | --- | --- | --- | --- | --- | | `Authorization` | header | string | yes | `Bearer ` — either a `tp_` API key (Developer → API Keys; simplest, for server-to-server) or an OAuth 2.0 access token (Developer → OAuth Apps; for user-authorized apps, scoped + revocable). The Authentication page has the full OAuth flow and scope list. | | `Idempotency-Key` | header | string | no | UUID v4 (or any opaque string ≤ 255 chars) per logical operation. The first response is replayed for 24 hours. | | `productId` | body | ObjectId | yes | ID of the product the passport belongs to. Must belong to the API key's company. | | `gs1.gtin` | body | string (14 digits) | yes | GTIN-14 with a valid GS1 check digit. Must not already be registered by another tenant. | | `gs1.serialNumber` | body | string (1-100 chars) | yes | Serial unique within the GTIN. The most common pattern is the product model + a sequence (BP-48V-100-000001). | | `parties` | body | Record | no | Optional structural parties block. A map keyed by role — `manufacturer`, `importer`, `authorisedRepresentative`, `distributor`, `recycler`, `producerResponsibilityOrg`. Each value is a Party. See the Upsert party endpoint for the per-Party body shape. Roles can also be added or replaced after creation via PATCH /api/v1/passports/{id}/parties/{role}. | | `confirmOverage` | body | boolean | no | Accept the per-passport overage charge when the plan's `maxDpps` quota is already exhausted. Required only after a 402 response on a previous attempt. | ## Examples ```bash curl -sS https://app.tracepass.eu/api/v1/passports \ -H "Authorization: Bearer tp_REDACTED_xxxxxxxxxxxx" \ -H "Idempotency-Key: 7b4f1e2c-9a3d-4e5b-8c1a-2d3e4f5a6b7c" \ -H "Content-Type: application/json" \ -d '{ "productId": "6650a1b2c3d4e5f6a7b8c9d0", "gs1": { "gtin": "04012345000016", "serialNumber": "BP-48V-100-000001" } }' ``` ```typescript import { randomUUID } from "node:crypto"; const res = await fetch("https://app.tracepass.eu/api/v1/passports", { method: "POST", headers: { Authorization: `Bearer ${process.env.TRACEPASS_API_KEY}`, "Idempotency-Key": randomUUID(), "Content-Type": "application/json", }, body: JSON.stringify({ productId: "6650a1b2c3d4e5f6a7b8c9d0", gs1: { gtin: "04012345000016", serialNumber: "BP-48V-100-000001", }, }), }); if (!res.ok) throw new Error(`Create failed: ${res.status}`); const passport = await res.json(); console.log(passport.gs1.digitalLinkUri); ``` ```python import os, uuid, requests res = requests.post( "https://app.tracepass.eu/api/v1/passports", headers={ "Authorization": f"Bearer {os.environ['TRACEPASS_API_KEY']}", "Idempotency-Key": str(uuid.uuid4()), "Content-Type": "application/json", }, json={ "productId": "6650a1b2c3d4e5f6a7b8c9d0", "gs1": { "gtin": "04012345000016", "serialNumber": "BP-48V-100-000001", }, }, ) res.raise_for_status() passport = res.json() print(passport["gs1"]["digitalLinkUri"]) ``` ## Responses ### 201 — Created ```json { "_id": "6650b2c3d4e5f6a7b8c9d0e1", "companyId": "6650a0b1c2d3e4f5a6b7c8d9", "productId": "6650a1b2c3d4e5f6a7b8c9d0", "templateId": "6650a1b2c3d4e5f6a7b8c9d1", "gs1": { "gtin": "04012345000016", "serialNumber": "BP-48V-100-000001", "digitalLinkUri": "https://id.tracepass.eu/p/01/04012345000016/21/BP-48V-100-000001" }, "status": "draft", "completionPercentage": 32, "fieldCounts": { "total": 52, "empty": 35, "approved": 17, "pendingReview": 0, "flagged": 0 }, "fields": { "...": "...seeded from product defaults + template defaults + company prefill..." }, "createdAt": "2026-05-09T10:00:00.000Z" } ``` ### 400 — Validation error ```json { "error": "Validation error", "details": { "fieldErrors": { "gs1.gtin": ["GTIN must be 14 digits"] } } } ``` ### 402 — Overage required ```json { "error": "overage_required", "planLimit": 100, "currentUsage": 100, "extraPriceCents": 75, "message": "DPP quota reached. Retry with { confirmOverage: true } to accept the per-passport charge." } ``` ### 409 — Conflict ```json // GTIN owned by another tenant { "error": "This GTIN is already registered by another company. Contact support if this is an error." } // Or: serial collision within the GTIN { "error": "Serial number already exists for this GTIN" } ``` ### 429 — Rate limit ```json { "error": "API rate limit: 200 writes/day via /api/v1. Currently 200 today; requested 1. Retry tomorrow (UTC) or upgrade your plan." } ``` ## Related - [Update one field on a passport](https://www.tracepass.eu/docs/update-field.md) - [Attach an economic-operator party](https://www.tracepass.eu/docs/upsert-party.md) --- --- title: Create a product description: Create a product (SKU layer above passports). Category picks the template. Accepts imageUrls[] for CDN images (max 20). Idempotency-Key supported. canonical: "https://www.tracepass.eu/docs/create-product" locale: en source: "https://www.tracepass.eu/docs/create-product" --- # Create a product > Create a product (SKU layer above passports). Category picks the template. Accepts imageUrls[] for CDN images (max 20). Idempotency-Key supported. ```http POST /api/v1/products ``` Create a product. The category template is resolved automatically from the `category` slug — must match a seeded category (e.g. `batteries`, `textiles`, `jewelry`). Model strings are unique within the workspace. Counts as one v1 write. Honours `Idempotency-Key`. Optional `imageUrls` accepts an array of public HTTPS URLs (max 20 per product, max 2048 chars each); the customer's CDN remains canonical and TracePass doesn't re-host them. Use the multipart upload endpoint when you don't have CDN URLs ready. ## Parameters | Name | In | Type | Required | Description | | --- | --- | --- | --- | --- | | `Authorization` | header | string | yes | `Bearer ` — either a `tp_` API key (Developer → API Keys; simplest, for server-to-server) or an OAuth 2.0 access token (Developer → OAuth Apps; for user-authorized apps, scoped + revocable). The Authentication page has the full OAuth flow and scope list. | | `Idempotency-Key` | header | string | no | UUID v4 per logical operation. | | `name` | body | string (1-200) | yes | Display name. | | `model` | body | string (1-100) | yes | Model identifier. Must be unique within your workspace. | | `category` | body | string | yes | Seeded category slug — `batteries`, `textiles`, `jewelry`, `electronics`, `furniture`, `detergents`, `paints-coatings`, `packaging`, `toys`, `fmcg`, `tyres`, `iron-steel`, `construction`. | | `description` | body | string (≤ 2000) | no | Optional description. | | `defaultFieldValues` | body | object | no | Seed values applied to every passport created from this product. Each entry's key must exist on the category template. | | `imageUrls` | body | string\[\] (max 20) | no | Public HTTPS image URLs. Replaces the existing array on PATCH; appends on the multipart upload endpoint. | | `sourceLocale` | body | string (ISO 639-1) | no | Locale of `name` and `description`. Defaults to your workspace's `defaultSourceLocale` (typically `en`). | ## Examples ```bash curl -sS https://app.tracepass.eu/api/v1/products \ -H "Authorization: Bearer tp_REDACTED_xxxxxxxxxxxx" \ -H "Idempotency-Key: 7b4f1e2c-9a3d-4e5b-8c1a-2d3e4f5a6b7c" \ -H "Content-Type: application/json" \ -d '{ "name": "Li-Ion 48V Battery Pack", "model": "BP-48V-100", "category": "batteries", "defaultFieldValues": { "batteryChemistry": "NMC", "nominalVoltage": 48 } }' ``` ```typescript import { randomUUID } from "node:crypto"; const res = await fetch("https://app.tracepass.eu/api/v1/products", { method: "POST", headers: { Authorization: `Bearer ${process.env.TRACEPASS_API_KEY}`, "Idempotency-Key": randomUUID(), "Content-Type": "application/json", }, body: JSON.stringify({ name: "Li-Ion 48V Battery Pack", model: "BP-48V-100", category: "batteries", defaultFieldValues: { batteryChemistry: "NMC", nominalVoltage: 48 }, }), }); if (!res.ok) throw new Error(`Create failed: ${res.status}`); const product = await res.json(); ``` ```python import os, uuid, requests res = requests.post( "https://app.tracepass.eu/api/v1/products", headers={ "Authorization": f"Bearer {os.environ['TRACEPASS_API_KEY']}", "Idempotency-Key": str(uuid.uuid4()), "Content-Type": "application/json", }, json={ "name": "Li-Ion 48V Battery Pack", "model": "BP-48V-100", "category": "batteries", "defaultFieldValues": {"batteryChemistry": "NMC", "nominalVoltage": 48}, }, ) res.raise_for_status() ``` ## Responses ### 201 — Created ```json { "_id": "6650a1b2c3d4e5f6a7b8c9d0", "name": "Li-Ion 48V Battery Pack", "model": "BP-48V-100", "category": "batteries", "templateId": "6650a1b2c3d4e5f6a7b8c9d1", "defaultFieldValues": { "batteryChemistry": "NMC", "nominalVoltage": 48 }, "passportCount": 0, "status": "active", "createdAt": "2026-05-09T10:00:00.000Z" } ``` ### 400 — No template ```json { "error": "No template found for category: foo-bar" } ``` ### 409 — Duplicate model ```json { "error": "A product with this model already exists for your company" } ``` ## Related - [List products](https://www.tracepass.eu/docs/list-products.md) - [Update a product](https://www.tracepass.eu/docs/update-product.md) - [Upload product image](https://www.tracepass.eu/docs/upload-product-image.md) --- --- title: Delete a passport permanently description: Permanently delete an unpublished passport (status draft or in_review). Cascades extractions, agent sessions, supplier links, and R2 files. Paid plans only. canonical: "https://www.tracepass.eu/docs/delete-passport" locale: en source: "https://www.tracepass.eu/docs/delete-passport" --- # Delete a passport permanently > Permanently delete an unpublished passport (status draft or in_review). Cascades extractions, agent sessions, supplier links, and R2 files. Paid plans only. ```http DELETE /api/v1/passports/{id} ``` **Permanent and irreversible** — the passport row plus every cascaded dependent is removed from the database. Cascade includes AI extractions, agent-session state, supplier requests linked to this passport alone, scan + service events, and any uploaded documents whose only reference was this passport (documents shared across other passports/products stay). R2 storage under the passport's folder is swept too. **Only never-published passports are eligible.** A passport with status `draft` or `in_review` and `publishedAt: null` can be deleted; everything else returns `409 Conflict` with a `reason` field naming the policy. This is deliberate: the compliance moat protecting printed QRs in the wild is preserved — a passport that has ever resolved publicly cannot be quietly destroyed. **Paid-plan feature.** The endpoint returns `403 Forbidden` with `reason` on Free plans; use `POST /api/v1/passports/{id}/archive` instead — archive keeps the row in your audit trail and works on every plan. Counts as one v1 write. Honours `Idempotency-Key`. No webhook fires (the audit `billingEvents` entry is the trail). ## Parameters | Name | In | Type | Required | Description | | --- | --- | --- | --- | --- | | `Authorization` | header | string | yes | `Bearer ` — either a `tp_` API key (Developer → API Keys; simplest, for server-to-server) or an OAuth 2.0 access token (Developer → OAuth Apps; for user-authorized apps, scoped + revocable). The Authentication page has the full OAuth flow and scope list. | | `Idempotency-Key` | header | string | no | UUID v4. | | `id` | path | ObjectId | yes | Passport ID. | ## Examples ```bash curl -sS -X DELETE \ https://app.tracepass.eu/api/v1/passports/6650b2c3d4e5f6a7b8c9d0e1 \ -H "Authorization: Bearer tp_REDACTED_xxxxxxxxxxxx" ``` ```typescript const res = await fetch( `https://app.tracepass.eu/api/v1/passports/${id}`, { method: "DELETE", headers: { Authorization: `Bearer ${process.env.TRACEPASS_API_KEY}` }, }, ); if (res.status === 409) { // not eligible — read `reason` from the body const { reason } = await res.json(); console.warn("Cannot delete:", reason); } ``` ```python import os, requests res = requests.delete( f"https://app.tracepass.eu/api/v1/passports/{passport_id}", headers={"Authorization": f"Bearer {os.environ['TRACEPASS_API_KEY']}"}, ) if res.status_code == 409: print("Not eligible:", res.json().get("reason")) else: res.raise_for_status() ``` ## Responses ### 200 — Deleted ```json { "message": "Passport permanently deleted", "summary": { "passportId": "6650b2c3d4e5f6a7b8c9d0e1", "serialNumber": "SN-001", "gtin": "09506000134369", "deletedCounts": { "extractions": 3, "agentSessions": 1, "serviceEvents": 0, "scanEvents": 0, "ownershipTransfers": 0, "supplierRequestRefsRemoved": 0, "supplierRequestsDeleted": 0, "epcisEventRefsRemoved": 0, "epcisEventsDeleted": 0, "documentRefsRemoved": 1, "documentsDeleted": 1, "r2ObjectsDeleted": 4, "documentR2ObjectsDeleted": 1 }, "dppsActiveDelta": -1 } } ``` ### 403 — Plan gate ```json { "error": "Permanent delete is not available on your plan", "reason": "Hard-delete is a paid-plan feature. Use POST /api/v1/passports/{id}/archive instead." } ``` ### 409 — Not eligible ```json { "error": "Passport is not eligible for permanent deletion", "reason": "This passport has been published. Archive it instead — the QR remains traceable for audit." } ``` ### 404 — Not found ```json { "error": "Passport not found" } ``` ## Related - [Archive a passport (audit-safe alternative)](https://www.tracepass.eu/docs/archive-passport.md) - [Suspend a passport](https://www.tracepass.eu/docs/suspend-passport.md) --- --- title: Delete a product permanently description: Permanently delete a product with zero passports (any status). Unlinks shared documents, deletes orphan docs + R2 files. Paid plans only. Irreversible. canonical: "https://www.tracepass.eu/docs/delete-product" locale: en source: "https://www.tracepass.eu/docs/delete-product" --- # Delete a product permanently > Permanently delete a product with zero passports (any status). Unlinks shared documents, deletes orphan docs + R2 files. Paid plans only. Irreversible. ```http DELETE /api/v1/products/{id} ``` **Permanent and irreversible.** Removes the product row + any uploaded documents whose only reference was this product (documents linked to other products/passports stay, just with `productId` unset). R2 storage under `/products//` is swept. **Only products with ZERO passports of any status are eligible** — including archived. Returns `409 Conflict` with the live passport count in `reason` when ineligible. The rule preserves audit history: an archived passport carries the regulatory story ("we published this, then withdrew it") that would be orphaned if the parent product disappeared. **Paid-plan feature.** Returns `403 Forbidden` on Free plans; use `POST /api/v1/products/{id}/archive` instead — archive keeps the row for audit and works on every plan. Counts as one v1 write. Honours `Idempotency-Key`. No webhook (the `billingEvents` audit entry is the trail). ## Parameters | Name | In | Type | Required | Description | | --- | --- | --- | --- | --- | | `Authorization` | header | string | yes | `Bearer ` — either a `tp_` API key (Developer → API Keys; simplest, for server-to-server) or an OAuth 2.0 access token (Developer → OAuth Apps; for user-authorized apps, scoped + revocable). The Authentication page has the full OAuth flow and scope list. | | `Idempotency-Key` | header | string | no | UUID v4. | | `id` | path | ObjectId | yes | Product ID. | ## Examples ```bash curl -sS -X DELETE \ https://app.tracepass.eu/api/v1/products/6650b2c3d4e5f6a7b8c9d0e1 \ -H "Authorization: Bearer tp_REDACTED_xxxxxxxxxxxx" ``` ```typescript const res = await fetch( `https://app.tracepass.eu/api/v1/products/${id}`, { method: "DELETE", headers: { Authorization: `Bearer ${process.env.TRACEPASS_API_KEY}` }, }, ); if (res.status === 409) { const { reason } = await res.json(); console.warn("Cannot delete:", reason); } ``` ```python import os, requests res = requests.delete( f"https://app.tracepass.eu/api/v1/products/{product_id}", headers={"Authorization": f"Bearer {os.environ['TRACEPASS_API_KEY']}"}, ) if res.status_code == 409: print("Not eligible:", res.json().get("reason")) else: res.raise_for_status() ``` ## Responses ### 200 — Deleted ```json { "message": "Product permanently deleted", "summary": { "productId": "6650b2c3d4e5f6a7b8c9d0e1", "name": "Demo product", "deletedCounts": { "documentRefsUnlinked": 2, "documentsDeleted": 1, "r2ObjectsDeleted": 3, "documentR2ObjectsDeleted": 1 } } } ``` ### 403 — Plan gate ```json { "error": "Permanent delete is not available on your plan", "reason": "Hard-delete is a paid-plan feature. Use POST /api/v1/products/{id}/archive instead." } ``` ### 409 — Not eligible ```json { "error": "Product is not eligible for permanent deletion", "reason": "This product has 3 passports. Delete or archive every passport first." } ``` ### 404 — Not found ```json { "error": "Product not found" } ``` ## Related - [Archive a product](https://www.tracepass.eu/docs/archive-product.md) --- --- title: EPCIS 2.0 description: "GS1 EPCIS 2.0 supply-chain events — export a passport's event history, capture events from partners and ERP systems, and query the event store." canonical: "https://www.tracepass.eu/docs/epcis" locale: en source: "https://www.tracepass.eu/docs/epcis" --- # EPCIS 2.0 > GS1 EPCIS 2.0 supply-chain events — export a passport's event history, capture events from partners and ERP systems, and query the event store. GS1 EPCIS 2.0 supply-chain events — export a passport's event history, capture events from partners and ERP systems, and query the event store. ## Endpoints - [Export a passport's EPCIS events](https://www.tracepass.eu/docs/passport-epcis-export.md) — `GET /api/v1/passports/{id}/epcis` - [Capture EPCIS events](https://www.tracepass.eu/docs/capture-events.md) — `POST /api/v1/epcis/capture` - [Poll a capture job](https://www.tracepass.eu/docs/capture-job.md) — `GET /api/v1/epcis/capture/{id}` - [Query EPCIS events](https://www.tracepass.eu/docs/query-events.md) — `GET /api/v1/epcis/events` --- --- title: Errors & rate limits description: "Reference: HTTP status codes (4xx vs 5xx), error envelope shape, free-tier daily call caps, and 429 retry guidance with exponential back-off." canonical: "https://www.tracepass.eu/docs/errors" locale: en source: "https://www.tracepass.eu/docs/errors" --- # Errors & rate limits > Reference: HTTP status codes (4xx vs 5xx), error envelope shape, free-tier daily call caps, and 429 retry guidance with exponential back-off. Every error response carries the same JSON envelope, the HTTP status code matches the semantics, and the error string is stable enough to switch on. The list below is exhaustive — if you hit something not on it, please report it to [support@tracepass.eu](mailto:support@tracepass.eu). ## Envelope ```json { "error": "Validation error", "details": { "fieldErrors": { "model": ["Required"] } } } ``` `error` is always present and is a stable string — switch on it in your client. `details` is optional; when present its shape depends on the specific error (a flattened Zod result for validation, plan/usage numbers for an overage, role / permission name for a 403). ## Status codes | Status | When | Retry? | | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------- | | 400 | Validation error — body or query failed schema check; or unknown field key on a passport PATCH. | No (fix the request) | | 401 | Missing or revoked API key, or session expired. | No (mint a new key / re-auth) | | 402 | DPP quota exhausted on a passport-create call. Retry with \`confirmOverage: true\` if the plan supports overage. Also fired when an active subscription is required but past\_due/canceled. | Yes, with \`confirmOverage: true\` | | 403 | Plan-gate (e.g. v1 API on a Free plan) or workspace permission denied. | No | | 404 | Resource doesn't exist or is in a different workspace. | No | | 409 | Conflict — duplicate model on a product, GTIN registered to a different tenant, serial collision within a GTIN. | Sometimes (resolve the conflict, then retry) | | 410 | Resource was permanently removed (rare; mostly applies to public passport URLs after archive). | No | | 413 | Payload too large — applies to multipart image uploads (5 MB cap). | No | | 415 | Unsupported media type — image upload that isn't PNG / JPG / WebP. | No | | 422 | Idempotency-Key reused with a different request body. | No (generate a fresh key) | | 423 | Resource is suspended (public passport viewer only). | No | | 429 | Rate limit exceeded — daily writes or daily passport reads. | Yes (after the next UTC midnight) | | 500 | Unhandled server error. We're paged. | Yes (with backoff) | | 503 | Maintenance window or overload. Returns Retry-After. | Yes (after Retry-After) | ## Retry guidance For the “Yes” rows above: exponential backoff with jitter, capped at six attempts. We don't accept retries more aggressive than once-per-second on a single endpoint — anything faster won't hit the database (in-memory rate limiter rejects), but you'll burn your daily-write budget. The`Retry-After` header is set on every `503`; the rate-limit reset for `429` is always the next 00:00 UTC. **Tip —** Pair every retry with the same `Idempotency-Key` as the original — that's how you avoid double-creating a passport when the original write succeeded but the response was lost. ## Common error strings | Error string | Status | Meaning | | --------------------------------------------------------------------------------------------------------------------------------------------- | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | Validation error | 400 | Schema check failed. details.fieldErrors carries the per-field reasons (Zod flatten()). | | Invalid field key: | 400 | PATCH .../fields/ referenced a key that's not on the passport's template. | | No template found for category: | 400 | The category you sent isn't seeded — check the spelling against the public Buyer's Guide. | | A product with this model already exists for your company | 409 | Model strings are unique within a workspace. Pick a different model or update the existing product. | | This GTIN is already registered by another company. Contact support if this is an error. | 409 | GTINs are globally unique across tenants — two companies can't both own the same GTIN. | | Serial number already exists for this GTIN | 409 | Pick a different serial. Within a single GTIN, serials must be unique. | | Idempotency-Key has already been used with a different request body. Use a new key for the new request, or reuse the original body. | 422 | You sent the same key twice with different bodies. Generate a fresh key. | | overage\_required | 402 | DPP quota exhausted. Body carries planLimit + currentUsage + extraPriceCents. Retry with \`confirmOverage: true\` to accept the per-passport charge. | | API rate limit: N writes/day via /api/v1\. Currently X today; requested Y. Retry tomorrow (UTC) or upgrade your plan. | 429 | Daily v1 write budget exhausted. Wait or upgrade. | | API rate limit: N passports/day read via /api/v1\. Currently X today; requested Y. Retry tomorrow (UTC) or contact support for a bulk export. | 429 | Daily v1 passport-read budget exhausted. Wait, upgrade, or use the dashboard JSON-LD bulk export. | | Passport not found | 404 | Wrong ID or wrong workspace. Verify the API key matches the workspace that owns the passport. | We don't change the wording of an error string in a minor version. If we need a clearer string we add a sibling `code` field in the envelope (numeric, namespaced) and announce it in the regulatory changelog. Stable strings let you switch with confidence. --- --- title: Exports description: Bulk JSON-LD tenant export — every product, passport, and template you own as one canonical document. canonical: "https://www.tracepass.eu/docs/exports" locale: en source: "https://www.tracepass.eu/docs/exports" --- # Exports > Bulk JSON-LD tenant export — every product, passport, and template you own as one canonical document. Bulk JSON-LD tenant export — every product, passport, and template you own as one canonical document. ## Endpoints - [Bulk JSON-LD tenant export](https://www.tracepass.eu/docs/tenant-export.md) — `GET /api/exports/tenant` --- --- title: Get a single passport description: Read one passport by ID. ?lang resolves every field via the viewer-locale chain; ?format=full adds template labels, units, and access levels. canonical: "https://www.tracepass.eu/docs/get-passport" locale: en source: "https://www.tracepass.eu/docs/get-passport" --- # Get a single passport > Read one passport by ID. ?lang resolves every field via the viewer-locale chain; ?format=full adds template labels, units, and access levels. ```http GET /api/v1/passports/{id} ``` Read one passport by ID. Default response includes the full passport — translatable fields carry their `sourceLocale` and a per-locale `translations` map. Pass `?lang=` to have the server resolve every field through the public-viewer chain (viewer-locale translation → source-locale value → English → first-applied → universal source) and return one resolved value per field; the `translations` map is dropped from lang-resolved responses. Pass `?format=full` to additionally include template-derived field labels, units, and access levels alongside each value — useful for building a custom viewer or audit report. The two query params combine: `?format=full&lang=de` returns the labels in DE plus values resolved to DE. Alternate addressing: `GET /api/v1/passports/by-serial/{serial}` returns the same shape and accepts the same query params. There's also a `GET /api/v1/passports/{id}/qr` endpoint that returns a freshly-rendered SVG / PNG of the QR code — useful when you want our renderer instead of encoding `gs1.digitalLinkUri` yourself. ## Parameters | Name | In | Type | Required | Description | | --- | --- | --- | --- | --- | | `Authorization` | header | string | yes | `Bearer ` — either a `tp_` API key (Developer → API Keys; simplest, for server-to-server) or an OAuth 2.0 access token (Developer → OAuth Apps; for user-authorized apps, scoped + revocable). The Authentication page has the full OAuth flow and scope list. | | `id` | path | ObjectId | yes | Passport ID. | | `format` | query | string | no | Set to `full` to include template field labels, units, and access levels. | | `lang` | query | string (ISO 639-1) | no | Resolve field values to a single locale server-side. One of the 24 EU locales. | ## Examples ```bash # Default response — full data, consumer resolves locales itself curl -sS https://app.tracepass.eu/api/v1/passports/6650b2c3d4e5f6a7b8c9d0e1 \ -H "Authorization: Bearer tp_REDACTED_xxxxxxxxxxxx" # Single-locale response with template labels curl -sS \ "https://app.tracepass.eu/api/v1/passports/6650b2c3d4e5f6a7b8c9d0e1?format=full&lang=de" \ -H "Authorization: Bearer tp_REDACTED_xxxxxxxxxxxx" ``` ```typescript const url = new URL(`https://app.tracepass.eu/api/v1/passports/${id}`); url.searchParams.set("format", "full"); url.searchParams.set("lang", "de"); const res = await fetch(url, { headers: { Authorization: `Bearer ${process.env.TRACEPASS_API_KEY}` }, }); if (res.status === 404) return null; const passport = await res.json(); ``` ```python import os, requests res = requests.get( f"https://app.tracepass.eu/api/v1/passports/{passport_id}", headers={"Authorization": f"Bearer {os.environ['TRACEPASS_API_KEY']}"}, params={"format": "full", "lang": "de"}, ) res.raise_for_status() passport = res.json() ``` ## Responses ### 200 — Default ```json { "_id": "6650b2c3d4e5f6a7b8c9d0e1", "gs1": { "gtin": "04012345000016", "serialNumber": "BP-48V-100-000001", "digitalLinkUri": "https://id.tracepass.eu/p/01/04012345000016/21/BP-48V-100-000001" }, "status": "published", "completionPercentage": 87, "fields": { "batteryChemistry": { "value": "NMC", "source": "manual", "status": "approved", "accessLevel": "public", "sourceLocale": "en", "translations": { "de": { "value": "NMC", "source": "ai-haiku-4.5", "generatedAt": "2026-05-02T10:00:00.000Z" } } } } } ``` ### 200 — ?lang=de ```json { "_id": "6650b2c3d4e5f6a7b8c9d0e1", "gs1": { "...": "..." }, "status": "published", "fields": { "batteryChemistry": { "value": "NMC", "source": "manual", "sourceLocale": "en" } } } ``` ### 404 — Not found ```json { "error": "Passport not found" } ``` ## Related - [List passports](https://www.tracepass.eu/docs/list-passports.md) - [Create a passport](https://www.tracepass.eu/docs/create-passport.md) --- --- title: Get a single product description: Read one product by ID. Returns the full document including default field values, image URLs, template reference, and the running passportCount. canonical: "https://www.tracepass.eu/docs/get-product" locale: en source: "https://www.tracepass.eu/docs/get-product" --- # Get a single product > Read one product by ID. Returns the full document including default field values, image URLs, template reference, and the running passportCount. ```http GET /api/v1/products/{id} ``` Read one product by ID. Returns the full document including default field values, image URLs, template reference, and the running `passportCount`. Counts as one v1 read. ## Parameters | Name | In | Type | Required | Description | | --- | --- | --- | --- | --- | | `Authorization` | header | string | yes | `Bearer ` — either a `tp_` API key (Developer → API Keys; simplest, for server-to-server) or an OAuth 2.0 access token (Developer → OAuth Apps; for user-authorized apps, scoped + revocable). The Authentication page has the full OAuth flow and scope list. | | `id` | path | ObjectId | yes | Product ID. | ## Examples ```bash curl -sS https://app.tracepass.eu/api/v1/products/6650a1b2c3d4e5f6a7b8c9d0 \ -H "Authorization: Bearer tp_REDACTED_xxxxxxxxxxxx" ``` ```typescript const res = await fetch(`https://app.tracepass.eu/api/v1/products/${id}`, { headers: { Authorization: `Bearer ${process.env.TRACEPASS_API_KEY}` }, }); if (res.status === 404) return null; if (!res.ok) throw new Error(`Read failed: ${res.status}`); const product = await res.json(); ``` ```python import os, requests res = requests.get( f"https://app.tracepass.eu/api/v1/products/{product_id}", headers={"Authorization": f"Bearer {os.environ['TRACEPASS_API_KEY']}"}, ) if res.status_code == 404: raise SystemExit("Not found") res.raise_for_status() product = res.json() ``` ## Responses ### 200 — OK ```json { "_id": "6650a1b2c3d4e5f6a7b8c9d0", "name": "Li-Ion 48V Battery Pack", "model": "BP-48V-100", "category": "batteries", "templateId": "6650a1b2c3d4e5f6a7b8c9d1", "defaultFieldValues": { "batteryChemistry": "NMC", "nominalVoltage": 48 }, "imageUrls": [ "https://cdn.example.com/products/battery-pack-hero.jpg" ], "passportCount": 12, "status": "active", "createdAt": "2026-04-10T14:30:00.000Z", "updatedAt": "2026-04-12T09:15:00.000Z" } ``` ### 404 — Not found ```json { "error": "Product not found" } ``` ## Related - [List products](https://www.tracepass.eu/docs/list-products.md) - [Update a product](https://www.tracepass.eu/docs/update-product.md) --- --- title: Get a category template description: Get the full regulatory schema for one DPP category — every field with its key, type, required flag, access level, and governing regulation reference. canonical: "https://www.tracepass.eu/docs/get-template" locale: en source: "https://www.tracepass.eu/docs/get-template" --- # Get a category template > Get the full regulatory schema for one DPP category — every field with its key, type, required flag, access level, and governing regulation reference. ```http GET /api/v1/templates/{category} ``` Returns the full regulatory field schema for one DPP category — every field with its key, English label, data type, required flag, access level, validation bounds, enum options (where applicable), and the governing regulation article/annex (`regulationRef`). This is the lookup that powers compliance-aware integrations and the MCP server's compliance copilot. The projection is lean for API/AI consumers: it drops internal AI hints, the multilingual placeholder maps, and per-field sort bookkeeping, keeping the regulatory substance. Labels are returned in canonical English; the full localized label maps stay on the dashboard template API. `{category}` is one of the 13 category keys (battery, textile, electronics, construction, steel, detergents, paints-coatings, packaging, furniture, tyres, jewelry, toys, fmcg). An unknown category returns 404 with a `TEMPLATE_NOT_FOUND` code — list valid keys with `GET /api/v1/templates`. ## Parameters | Name | In | Type | Required | Description | | --- | --- | --- | --- | --- | | `Authorization` | header | string | yes | `Bearer ` — either a `tp_` API key (Developer → API Keys; simplest, for server-to-server) or an OAuth 2.0 access token (Developer → OAuth Apps; for user-authorized apps, scoped + revocable). The Authentication page has the full OAuth flow and scope list. | | `category` | path | string | yes | One of the 13 category keys, e.g. `battery`, `textile`, `electronics`. | ## Examples ```bash curl -sS https://app.tracepass.eu/api/v1/templates/battery \ -H "Authorization: Bearer tp_REDACTED_xxxxxxxxxxxx" ``` ```typescript const res = await fetch( "https://app.tracepass.eu/api/v1/templates/battery", { headers: { Authorization: `Bearer ${process.env.TRACEPASS_API_KEY}` } }, ); if (res.status === 404) throw new Error("Unknown category"); const template = await res.json(); ``` ```python import os, requests res = requests.get( "https://app.tracepass.eu/api/v1/templates/battery", headers={"Authorization": f"Bearer {os.environ['TRACEPASS_API_KEY']}"}, ) res.raise_for_status() template = res.json() ``` ## Responses ### 200 — Success ```json { "category": "battery", "categoryLabel": "Battery", "version": 1, "regulation": "EU Battery Regulation 2023/1542", "fieldCount": 119, "requiredFieldCount": 59, "requiredFieldCountByCategory": { "EV": 85, "LMT": 88, "industrial_gt_2kwh": 70 }, "fields": [ { "key": "batteryChemistry", "label": "Battery Chemistry", "dataType": "string", "required": true, "accessLevel": "public", "category": "materials_composition", "validation": { "required": true }, "regulationRef": { "article": "Art. 77", "annex": "Annex VI" } } ] } ``` ### 404 — Unknown category ```json { "error": "No template for category \"widgets\". Use GET /api/v1/templates to list valid categories.", "code": "TEMPLATE_NOT_FOUND" } ``` ## Related - [List category templates](https://www.tracepass.eu/docs/list-templates.md) - [Update a passport field](https://www.tracepass.eu/docs/update-field.md) --- --- title: List passports description: Paginated list of passports. Filter by productId, status, or free-text search across GTIN + serial. Counts against the daily passport-read budget. canonical: "https://www.tracepass.eu/docs/list-passports" locale: en source: "https://www.tracepass.eu/docs/list-passports" --- # List passports > Paginated list of passports. Filter by productId, status, or free-text search across GTIN + serial. Counts against the daily passport-read budget. ```http GET /api/v1/passports ``` Paginated list of passports the workspace owns. Filter by `productId`, `status`, or a free-text search across GTIN and serial number. Counts against the daily passport-read budget (`maxV1PassportsPerDay`); the response items use the same shape as the single-read endpoint but trimmed to the listing fields. ## Parameters | Name | In | Type | Required | Description | | --- | --- | --- | --- | --- | | `Authorization` | header | string | yes | `Bearer ` — either a `tp_` API key (Developer → API Keys; simplest, for server-to-server) or an OAuth 2.0 access token (Developer → OAuth Apps; for user-authorized apps, scoped + revocable). The Authentication page has the full OAuth flow and scope list. | | `page` | query | number (default 1) | no | 1-based page number. | | `limit` | query | number (1-100, default 20) | no | Items per page. | | `productId` | query | ObjectId | no | Filter by product. | | `status` | query | enum | no | `draft`, `in_review`, `approved`, `published`, `suspended`, `expired`, `archived`. | | `search` | query | string | no | Free-text across GTIN + serial. | ## Examples ```bash curl -sS \ "https://app.tracepass.eu/api/v1/passports?status=published&limit=50" \ -H "Authorization: Bearer tp_REDACTED_xxxxxxxxxxxx" ``` ```typescript const url = new URL("https://app.tracepass.eu/api/v1/passports"); url.searchParams.set("status", "published"); url.searchParams.set("limit", "50"); const res = await fetch(url, { headers: { Authorization: `Bearer ${process.env.TRACEPASS_API_KEY}` }, }); const { data } = await res.json(); ``` ```python import os, requests res = requests.get( "https://app.tracepass.eu/api/v1/passports", headers={"Authorization": f"Bearer {os.environ['TRACEPASS_API_KEY']}"}, params={"status": "published", "limit": 50}, ) res.raise_for_status() items = res.json()["data"]["items"] ``` ## Responses ### 200 — OK ```json { "data": { "items": [ { "_id": "6650b2c3d4e5f6a7b8c9d0e1", "productId": "6650a1b2c3d4e5f6a7b8c9d0", "gs1": { "gtin": "04012345000016", "serialNumber": "BP-48V-100-000001", "digitalLinkUri": "https://id.tracepass.eu/p/01/04012345000016/21/BP-48V-100-000001" }, "status": "published", "completionPercentage": 87, "publishedAt": "2026-04-11T10:00:00.000Z" } ], "total": 1, "page": 1, "limit": 50, "totalPages": 1 } } ``` ## Related - [Get a single passport](https://www.tracepass.eu/docs/get-passport.md) - [Create a passport](https://www.tracepass.eu/docs/create-passport.md) --- --- title: List products description: Paginated list of products (max 100/page), sorted by createdAt desc. Filter by category, status (active/archived), or free-text search across name + model. canonical: "https://www.tracepass.eu/docs/list-products" locale: en source: "https://www.tracepass.eu/docs/list-products" --- # List products > Paginated list of products (max 100/page), sorted by createdAt desc. Filter by category, status (active/archived), or free-text search across name + model. ```http GET /api/v1/products ``` Paginated list of every product the workspace owns, sorted by `createdAt` descending. Page size capped at 100. Filter by category slug, status (`active` / `archived`), or a free-text search across name + model. Counts as one v1 read against `maxV1PassportsPerDay` (the read-side budget — same counter as the passport list endpoint). Reads aren't counted against the write budget. ## Parameters | Name | In | Type | Required | Description | | --- | --- | --- | --- | --- | | `Authorization` | header | string | yes | `Bearer ` — either a `tp_` API key (Developer → API Keys; simplest, for server-to-server) or an OAuth 2.0 access token (Developer → OAuth Apps; for user-authorized apps, scoped + revocable). The Authentication page has the full OAuth flow and scope list. | | `page` | query | number (default 1) | no | 1-based page number. | | `limit` | query | number (1-100, default 20) | no | Items per page. | | `category` | query | string | no | Filter by category slug. | | `status` | query | string | no | `active` or `archived`. | | `search` | query | string | no | Free-text search across name and model. | ## Examples ```bash curl -sS \ "https://app.tracepass.eu/api/v1/products?category=batteries&page=1&limit=20" \ -H "Authorization: Bearer tp_REDACTED_xxxxxxxxxxxx" ``` ```typescript const url = new URL("https://app.tracepass.eu/api/v1/products"); url.searchParams.set("category", "batteries"); url.searchParams.set("limit", "20"); const res = await fetch(url, { headers: { Authorization: `Bearer ${process.env.TRACEPASS_API_KEY}` }, }); const { data } = await res.json(); ``` ```python import os, requests res = requests.get( "https://app.tracepass.eu/api/v1/products", headers={"Authorization": f"Bearer {os.environ['TRACEPASS_API_KEY']}"}, params={"category": "batteries", "limit": 20}, ) res.raise_for_status() data = res.json()["data"] ``` ## Responses ### 200 — OK ```json { "data": { "items": [ { "_id": "6650a1b2c3d4e5f6a7b8c9d0", "name": "Li-Ion 48V Battery Pack", "model": "BP-48V-100", "category": "batteries", "passportCount": 12, "status": "active", "createdAt": "2026-04-10T14:30:00.000Z" } ], "total": 1, "page": 1, "limit": 20, "totalPages": 1 } } ``` ## Related - [Create a product](https://www.tracepass.eu/docs/create-product.md) - [Get a single product](https://www.tracepass.eu/docs/get-product.md) --- --- title: List category templates description: List every DPP category template — field count, required-field count, governing regulation, and version. Discover requirements before you build a passport. canonical: "https://www.tracepass.eu/docs/list-templates" locale: en source: "https://www.tracepass.eu/docs/list-templates" --- # List category templates > List every DPP category template — field count, required-field count, governing regulation, and version. Discover requirements before you build a passport. ```http GET /api/v1/templates ``` Lists the DPP category templates — the regulatory field schemas (battery, textile, electronics, …). Each entry gives the category key, its English label, the total and required field counts, the governing regulation, and the template version. Templates are global reference data, not company-scoped. Use this to discover what a compliant passport in a category needs *before* you create products and passports. To read the full field-by-field schema for one category, call `GET /api/v1/templates/{category}`. `requiredFieldCount` is the category-agnostic figure. Where required-ness varies by product category the entry also carries `requiredFieldCountByCategory` — battery does, because the EU Battery Regulation asks different things of different battery types. Read that map rather than the flat number: for battery the flat count understates every in-scope category, because it ignores the fields that only become mandatory once a battery category is known. Note too that only EV, LMT and industrial batteries over 2 kWh need a battery passport at all; portable and SLI batteries are out of scope, so no field is required for them. This is a low-frequency discovery call, so it does not count against your daily read cap. Authentication is a `tp_` API key or an OAuth token with the `passports:read` scope. ## Parameters | Name | In | Type | Required | Description | | --- | --- | --- | --- | --- | | `Authorization` | header | string | yes | `Bearer ` — either a `tp_` API key (Developer → API Keys; simplest, for server-to-server) or an OAuth 2.0 access token (Developer → OAuth Apps; for user-authorized apps, scoped + revocable). The Authentication page has the full OAuth flow and scope list. | ## Examples ```bash curl -sS https://app.tracepass.eu/api/v1/templates \ -H "Authorization: Bearer tp_REDACTED_xxxxxxxxxxxx" ``` ```typescript const res = await fetch("https://app.tracepass.eu/api/v1/templates", { headers: { Authorization: `Bearer ${process.env.TRACEPASS_API_KEY}` }, }); const { templates } = await res.json(); ``` ```python import os, requests res = requests.get( "https://app.tracepass.eu/api/v1/templates", headers={"Authorization": f"Bearer {os.environ['TRACEPASS_API_KEY']}"}, ) res.raise_for_status() templates = res.json()["templates"] ``` ## Responses ### 200 — Success ```json { "templates": [ { "category": "battery", "categoryLabel": "Battery", "fieldCount": 119, "requiredFieldCount": 59, "requiredFieldCountByCategory": { "EV": 85, "LMT": 88, "industrial_gt_2kwh": 70 }, "regulation": "EU Battery Regulation 2023/1542", "version": 1 }, { "category": "textile", "categoryLabel": "Textile", "fieldCount": 60, "requiredFieldCount": 12, "regulation": "ESPR 2024/1781", "version": 2 } ] } ``` ## Related - [Get a category template](https://www.tracepass.eu/docs/get-template.md) - [Create a product](https://www.tracepass.eu/docs/create-product.md) --- --- title: MCP server description: MCP server — AI assistants (Claude, Cursor, IDE agents) manage products, passports, EPCIS events directly. Hosted endpoint or local npm package. canonical: "https://www.tracepass.eu/docs/mcp" locale: en source: "https://www.tracepass.eu/docs/mcp" --- # MCP server > MCP server — AI assistants (Claude, Cursor, IDE agents) manage products, passports, EPCIS events directly. Hosted endpoint or local npm package. The TracePass MCP server lets an AI assistant drive the TracePass platform directly — list and create products, build and audit Digital Product Passports, set economic-operator parties, and read or capture GS1 EPCIS supply-chain events. It speaks the full Model Context Protocol: tools, resources, and prompts. Connect a hosted `endpoint` or run it locally via `npx` — both authenticate with the same `tp_` API keys as the v1 API. Source on [GitHub](https://github.com/malinoto/tracepass-mcp-server), published as [tracepass-mcp-server](https://www.npmjs.com/package/tracepass-mcp-server) on npm. Listed in the official [MCP Registry](https://registry.modelcontextprotocol.io) as `eu.tracepass/tracepass`. ## What it is MCP is an open protocol that lets an AI assistant call external tools and read external data through a single, standard interface. The TracePass MCP server is a thin, stateless adapter in front of the TracePass v1 API — it has no database of its own; every tool call and resource read goes straight through to the same API your other integrations use, so authentication, plan gating, and rate limits all behave identically. There are two ways to connect it. The **hosted** server runs at `https://ai.tracepass.eu/mcp` over HTTP — nothing to install, always current. The **local** server is the `tracepass-mcp-server` npm package, launched as a subprocess by your MCP client and speaking MCP over stdio. ## Connecting (hosted) Point your MCP client at the hosted endpoint and pass your API key as a `Bearer` token. Mint a key in the dashboard under **Developer → API Keys** — it is the same `tp_` key the v1 API uses. Add this block to your client's MCP configuration: ```json { "mcpServers": { "tracepass": { "url": "https://ai.tracepass.eu/mcp", "headers": { "Authorization": "Bearer tp_YOUR_KEY" } } } } ``` ## Connecting (local / npx) For a local setup, your MCP client launches the npm package as a subprocess and talks to it over stdio. There is nothing to install ahead of time — `npx` fetches `tracepass-mcp-server` on first run. The API key is passed through the `TRACEPASS_API_KEY` environment variable instead of a header: ```json { "mcpServers": { "tracepass": { "command": "npx", "args": ["-y", "tracepass-mcp-server"], "env": { "TRACEPASS_API_KEY": "tp_YOUR_KEY" } } } } ``` ## Tools The TracePass v1 API operations are grouped into six tools. Each takes an `action` plus action-specific `args`, so the assistant picks the tool by domain and the operation by action: | Tool | Actions | | ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | tracepass\_products | list, get, create, updateCatalog operations — browse, read, and create or update products. | | tracepass\_passports | list, get, get\_by\_serial, compliance, registry\_readiness, create, suspend, suspend\_by\_serial, archive, archive\_by\_serial, get\_qr, get\_qr\_by\_serialThe passport lifecycle — list and read passports, look one up by serial number, create, suspend, archive, and fetch the QR code. | | tracepass\_passport\_fields | update, update\_by\_serialUpdate individual template fields on a passport. | | tracepass\_passport\_parties | set, removeSet or remove economic-operator parties (manufacturer, importer, recycler, and so on) on a passport. | | tracepass\_epcis | export, export\_by\_serial, capture, capture\_job, queryRead and write GS1 EPCIS 2.0 supply-chain events — export a passport's event history, capture new events, run a capture job, and query the event store. | | tracepass\_templates | list, getRead the regulatory schema for each DPP category — what a compliant passport must contain and the EU regulation behind each required field. Lets the assistant advise on requirements before you create anything. | **Some write actions cost money or are irreversible.** The server's tool descriptions tell the model this, but you should know it too: `tracepass_passports` with action `create` consumes a billable DPP slot on your plan — over-quota creation incurs a per-passport overage charge and only proceeds once the user agrees via `confirmOverage`. Action `archive` is irreversible; use `suspend` when you may need the passport back. The `tracepass_epcis` actions (`capture`, `query`, `export`) are included on every paid plan and metered by events-per-month per the plan table on [/pricing](https://www.tracepass.eu/pricing). ## Resources Resources are read-only entity data the user attaches as conversation context, addressed by a `tracepass://` URI. Two are static resources, the rest are resource templates the client completes with an id: * `tracepass://products` * `tracepass://product/{id}` * `tracepass://passport/{id}` * `tracepass://passport/{id}/epcis` * `tracepass://passport/{id}/compliance` * `tracepass://passport/{id}/registry-readiness` * `tracepass://templates` * `tracepass://template/{category}` ## Prompts Prompts are reusable DPP workflows the MCP client surfaces to the user, typically as slash-commands. Each seeds the conversation so the assistant carries out the task the way TracePass intends — for example, always confirming before it creates a billable passport: * `audit_passport` * `onboard_product` * `review_epcis_events` * `explain_dpp_requirements` * `compliance_gap_check` ## The compliance copilot in action Put together, the templates tool and the prompts turn the assistant into a DPP **compliance copilot** — it knows what each category's regulation requires, not just how to push data. Here is a representative session for a battery manufacturer: ```text You ▸ What does a compliant battery passport need, and which fields will be hardest to source? TracePass copilot ▸ Calling tracepass_templates(get, battery)… A battery DPP is governed by the EU Battery Regulation (EU) 2023/1542, mandatory from 18 Feb 2027. The template covers the Annex XIII field set. By access level: • Public (consumer-facing): manufacturer identity, battery category, weight, capacity, expected lifetime, recycled-content shares (Co, Pb, Li, Ni). — Art. 77, Annex VI • Restricted (authorised parties): full material composition, hazardous-substance breakdown, dismantling info. • Authority-only: conformity test reports, due-diligence data. Hardest to source up front: the recycled-content shares and the carbon-footprint declaration — those usually live with your cell supplier. Want me to draft a supplier request for them? You ▸ Yes — and gap-check passport SN-2026-00042 before I publish it. TracePass copilot ▸ Running the compliance_gap_check prompt… Against the battery schema, SN-2026-00042 is NOT publishable yet: ✗ carbonFootprintDeclaration — empty (required, Art. 7) ✗ recycledContentCobalt — empty (required, Annex VI) ✗ recycler party — not set ⚠ stateOfHealth — present but pending review Everything else is approved. Fix the two empty required fields and add the recycler party, and it's ready. Most important first: the carbon-footprint declaration — it blocks publishing and takes the longest to obtain. ``` **Tip —** Representative example. The assistant's answers come from the live category schema and your own passport data via the tools above — exact wording varies by model and client. --- --- title: n8n community node description: Automate TracePass workflows in n8n without code — products, passports, EPCIS events. Free community node, installable from any n8n instance. canonical: "https://www.tracepass.eu/docs/n8n" locale: en source: "https://www.tracepass.eu/docs/n8n" --- # n8n community node > Automate TracePass workflows in n8n without code — products, passports, EPCIS events. Free community node, installable from any n8n instance. [n8n-nodes-tracepass](https://www.npmjs.com/package/n8n-nodes-tracepass) is an n8n community node that lets you automate TracePass — products, Digital Product Passports, GS1 EPCIS 2.0 supply-chain events — directly from your n8n workflows. No code, declarative routing, free. Source on [GitHub](https://github.com/malinoto/n8n-nodes-tracepass). ## Install in n8n In any n8n instance (cloud or self-hosted), open **Settings → Community Nodes → Install** and enter the package name: ```text n8n-nodes-tracepass ``` Once installed, search for `TracePass` in the node panel. See n8n's [community-nodes installation guide](https://docs.n8n.io/integrations/community-nodes/installation/) for full instructions. ## Credential Create a **TracePass API** credential and paste a `tp_` API key (mint one in the TracePass dashboard under Developer → API Keys). The _Base URL_ defaults to `https://app.tracepass.eu` — change it only for a self-hosted or staging deployment. n8n's **Test** button verifies the key against a cheap read endpoint. ## Resources & operations Four resources mirror the v1 REST API. Each operation maps to one HTTP call (declarative `routing`), so the node carries zero runtime dependencies beyond what n8n provides. | Resource | Operations | | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Product | Create · Get · Get Many · Update | | Passport | Archive · Archive by Serial · Compliance · Create · Create Batch · Get · Get by Serial · Get Many · Get QR · Get QR by Serial · Registry Readiness · Suspend · Suspend by Serial · Update Field · Update Field by Serial | | EPCIS Event | Capture · Export · Export by Serial · Get Capture Job · Query | | Template | Get · Get Many | **Write-action safety.** Each operation's description names the risk — **Create** on _Passport_ consumes a billable plan DPP slot (use _Confirm Overage Charge_ to opt into the per-passport overage fee); **Archive** is irreversible and the public QR permanently 404s — use **Suspend** when a change might be undone. **EPCIS Capture / Query / Export** are included on every paid plan and metered by events-per-month per the plan table on [/pricing](https://www.tracepass.eu/pricing). ## Triggers TracePass also dispatches HMAC-signed webhooks for lifecycle events (`passport.published`, `extraction.completed`, `supplier.submitted`, `epcis.event.captured`, etc.). To use them as n8n triggers, configure a webhook subscription in the TracePass dashboard (Developer → Webhooks) pointing at an n8n **Webhook** trigger node — n8n's built-in node is all you need; no separate TracePass trigger node is required. ## Example workflows **Shopify → TracePass.** On a new Shopify order, create a passport (product mapped by SKU, serial = order id), then email the QR code to the customer. **Daily digest.** A Schedule trigger lists yesterday's passports and posts a summary to Slack. **CSV → passports.** Read a CSV or Excel sheet of serial numbers and create them with one _Create Batch_ call (up to 100 per call) instead of looping a create per row. **Supplier follow-up.** A Schedule trigger lists supplier requests older than seven days and sends reminders. * Shopify → TracePass * Daily analytics digest → Slack * CSV import → batch passports * Supplier follow-up reminders --- --- title: Check passport compliance description: Get a three-tier compliance verdict for one passport, with regulation-cited findings — gap-check, fix, re-check the read-fix-verify loop. canonical: "https://www.tracepass.eu/docs/passport-compliance" locale: en source: "https://www.tracepass.eu/docs/passport-compliance" --- # Check passport compliance > Get a three-tier compliance verdict for one passport, with regulation-cited findings — gap-check, fix, re-check the read-fix-verify loop. ```http GET /api/v1/passports/{id}/compliance ``` Returns a three-tier compliance verdict for one passport — `compliant`, `compliant_with_warnings`, or `incomplete` — together with regulation-cited findings, so an integration can gap-check a passport, fix the cited gaps, then call again to confirm. That read → fix → verify loop is the point: the response tells an agent exactly what to set next. Findings come from three tiers. **Static**: required template fields that are missing or unapproved, and required economic-operator parties that aren't set, are `critical`; field values that violate the template's format (pattern / enum / bounds) are `warning`. **Conditional**: per-category rules that are in force today — the battery passport scope under Regulation (EU) 2023/1542 Art. 77, SVHC disclosure under REACH Art. 33 / SCIP, the Declaration of Performance under Regulation (EU) 2024/3110 — plus the cross-cutting rule that a product placed on the EU market by a non-EU manufacturer needs an EU-established operator (Regulation (EU) 2019/1020 Art. 4). **Read `conditionalCoverage`.** It is `evaluated` when conditional rules ran for this category, or `static-only` when no binding conditional rule is in force yet (6 of the 13 categories today). When it is `static-only`, the absence of conditional findings does NOT mean the category has no future requirements — only that none are legally binding yet. A finding tagged `unverifiable_conditional` means a rule applies but the data needed to evaluate it (e.g. battery category, SVHC content) isn't on the passport — verify it manually. Read-only; counts as one v1 passport read against the daily cap. ## Parameters | Name | In | Type | Required | Description | | --- | --- | --- | --- | --- | | `Authorization` | header | string | yes | `Bearer ` — either a `tp_` API key (Developer → API Keys; simplest, for server-to-server) or an OAuth 2.0 access token (Developer → OAuth Apps; for user-authorized apps, scoped + revocable). The Authentication page has the full OAuth flow and scope list. | | `id` | path | ObjectId | yes | Passport ID. | ## Examples ```bash curl -sS \ https://app.tracepass.eu/api/v1/passports/6650b2c3d4e5f6a7b8c9d0e1/compliance \ -H "Authorization: Bearer tp_REDACTED_xxxxxxxxxxxx" ``` ```typescript const res = await fetch( `https://app.tracepass.eu/api/v1/passports/${id}/compliance`, { headers: { Authorization: `Bearer ${process.env.TRACEPASS_API_KEY}` } }, ); const verdict = await res.json(); if (verdict.verdict === "incomplete") { // Each critical finding names the field/party to set and cites the regulation. for (const f of verdict.critical) { console.log(`${f.target}: ${f.why} (${f.regulation ?? ""} ${f.article ?? ""})`); } } ``` ```python import os, requests res = requests.get( f"https://app.tracepass.eu/api/v1/passports/{passport_id}/compliance", headers={"Authorization": f"Bearer {os.environ['TRACEPASS_API_KEY']}"}, ) res.raise_for_status() verdict = res.json() for f in verdict["critical"]: print(f["target"], "—", f["why"], f.get("regulation", ""), f.get("article", "")) ``` ## Responses ### 200 — incomplete ```json { "verdict": "incomplete", "category": "battery", "conditionalCoverage": "evaluated", "critical": [ { "type": "conditional_missing", "severity": "critical", "target": "batteryUniqueIdentifier", "regulation": "(EU) 2023/1542", "article": "Art. 77", "ruleId": "BAT-1", "why": "This is an in-scope battery (EV); a battery passport with its unique identifier is mandatory.", "fix": "Provide batteryUniqueIdentifier — the battery passport's unique identifier (GS1 Digital Link)." } ], "warnings": [], "checkedRules": ["static:required-fields", "static:required-parties", "static:format", "BAT-1", "CC-1"], "completionPercentage": 72 } ``` ### 200 — compliant ```json { "verdict": "compliant", "category": "furniture", "conditionalCoverage": "static-only", "critical": [], "warnings": [], "checkedRules": ["static:required-fields", "static:required-parties", "static:format", "CC-1"], "completionPercentage": 100 } ``` ### 404 — Not found ```json { "error": "Passport not found" } ``` ## Related - [Get a single passport](https://www.tracepass.eu/docs/get-passport.md) - [Update a field](https://www.tracepass.eu/docs/update-field.md) - [Set an economic operator](https://www.tracepass.eu/docs/upsert-party.md) --- --- title: "Export a passport's EPCIS events" description: "Export one passport's full event history as a standards-valid GS1 EPCIS 2.0 EPCISDocument (JSON-LD). Drops straight into any EPCIS-aware tool." canonical: "https://www.tracepass.eu/docs/passport-epcis-export" locale: en source: "https://www.tracepass.eu/docs/passport-epcis-export" --- # Export a passport's EPCIS events > Export one passport's full event history as a standards-valid GS1 EPCIS 2.0 EPCISDocument (JSON-LD). Drops straight into any EPCIS-aware tool. ```http GET /api/v1/passports/{id}/epcis ``` Exports one passport's full event history — supply-chain, service, ownership, and captured events — as a single standards-valid GS1 EPCIS 2.0 `EPCISDocument` in JSON-LD. The document carries the GS1 `@context`, `type: "EPCISDocument"`, `schemaVersion: "2.0"`, and an `epcisBody.eventList` of every event TracePass holds for the passport. The passport's Digital Link URI is the EPC on each event, so the export drops straight into any EPCIS-aware repository or auditor toolchain. Alternate addressing: `GET /api/v1/passports/by-serial/{serial}/epcis` returns the same EPCISDocument for a passport addressed by its serial number instead of its ID — handy when your systems key on the GS1 serial rather than the TracePass ObjectId. Counts as one passport read. EPCIS export is available on Starter plans and up: on a plan without it the endpoint returns `403 {"error":"epcis_export_not_available"}`. An unknown passport id returns `404`. ## Parameters | Name | In | Type | Required | Description | | --- | --- | --- | --- | --- | | `Authorization` | header | string | yes | `Bearer ` — either a `tp_` API key (Developer → API Keys; simplest, for server-to-server) or an OAuth 2.0 access token (Developer → OAuth Apps; for user-authorized apps, scoped + revocable). The Authentication page has the full OAuth flow and scope list. | | `id` | path | ObjectId | yes | Passport ID. Use `GET /api/v1/passports/by-serial/{serial}/epcis` to address the passport by its GS1 serial number instead. | ## Examples ```bash # By passport ID curl -sS https://app.tracepass.eu/api/v1/passports/6650b2c3d4e5f6a7b8c9d0e1/epcis \ -H "Authorization: Bearer tp_REDACTED_xxxxxxxxxxxx" # By GS1 serial number curl -sS https://app.tracepass.eu/api/v1/passports/by-serial/BP-48V-100-000001/epcis \ -H "Authorization: Bearer tp_REDACTED_xxxxxxxxxxxx" ``` ```typescript const res = await fetch( `https://app.tracepass.eu/api/v1/passports/${passportId}/epcis`, { headers: { Authorization: `Bearer ${process.env.TRACEPASS_API_KEY}` } }, ); if (res.status === 404) return null; const epcisDocument = await res.json(); // EPCISDocument, schemaVersion 2.0 console.log(epcisDocument.epcisBody.eventList.length, "events"); ``` ```python import os, requests res = requests.get( f"https://app.tracepass.eu/api/v1/passports/{passport_id}/epcis", headers={"Authorization": f"Bearer {os.environ['TRACEPASS_API_KEY']}"}, ) res.raise_for_status() epcis_document = res.json() # EPCISDocument, schemaVersion 2.0 print(len(epcis_document["epcisBody"]["eventList"]), "events") ``` ## Responses ### 200 — OK ```json { "@context": "https://ref.gs1.org/standards/epcis/2.0.0/epcis-context.jsonld", "type": "EPCISDocument", "schemaVersion": "2.0", "creationDate": "2026-05-09T12:00:00.000Z", "epcisBody": { "eventList": [ { "type": "ObjectEvent", "eventID": "ni:///sha-256;9f86d0...?ver=CBV2.0", "eventTime": "2026-05-09T11:58:00.000Z", "eventTimeZoneOffset": "+02:00", "epcList": ["https://id.tracepass.eu/p/01/04012345000016/21/BP-48V-100-000001"], "action": "OBSERVE", "bizStep": "shipping", "bizLocation": { "id": "https://id.tracepass.eu/loc/acme-batteries-de" } } ] } } ``` ### 401 — Missing API key ```json { "error": "Missing or invalid API key" } ``` ### 403 — Not on plan ```json { "error": "epcis_export_not_available" } ``` ### 404 — Not found ```json { "error": "Passport not found" } ``` ## Related - [Query EPCIS events](https://www.tracepass.eu/docs/query-events.md) - [Bulk JSON-LD tenant export](https://www.tracepass.eu/docs/tenant-export.md) --- --- title: Render the passport QR description: "Render a passport's QR code as SVG, PNG, or JSON — optionally in the company brand colour or an explicit hex. Encodes the GS1 Digital Link URI." canonical: "https://www.tracepass.eu/docs/passport-qr" locale: en source: "https://www.tracepass.eu/docs/passport-qr" --- # Render the passport QR > Render a passport's QR code as SVG, PNG, or JSON — optionally in the company brand colour or an explicit hex. Encodes the GS1 Digital Link URI. ```http GET /api/v1/passports/{id}/qr ``` Returns a freshly-rendered QR code for the passport, encoding its `gs1.digitalLinkUri`. Use this when you want our renderer (consistent quiet zone, error correction, optional branding) instead of encoding the URI yourself. Defaults to `image/svg+xml`; `?format=png` returns a PNG and `?format=json` returns a `{ result: "" }` wrapper for embedding. By default the QR is black on a transparent background. Set `?useCompanyBranding=true` to use the company's brand colour, or pass `?color=FF6600` (6-char hex, no `#`) for an explicit foreground — an explicit `color` wins over branding. `?backgroundColor=FFFFFF` adds a solid backing (8-char hex = RGBA for partial transparency). Alternate addressing: `GET /api/v1/passports/by-serial/{serial}/qr` takes the same query params and accepts the `?gtin=` disambiguator when a serial isn't unique across your GTINs. Each call counts as one passport read against the daily cap. ## Parameters | Name | In | Type | Required | Description | | --- | --- | --- | --- | --- | | `Authorization` | header | string | yes | `Bearer ` — either a `tp_` API key (Developer → API Keys; simplest, for server-to-server) or an OAuth 2.0 access token (Developer → OAuth Apps; for user-authorized apps, scoped + revocable). The Authentication page has the full OAuth flow and scope list. | | `id` | path | ObjectId | yes | Passport ID. | | `format` | query | string | no | `svg` (default), `png`, or `json`. | | `useCompanyBranding` | query | boolean | no | Render the QR in the company's brand colour instead of black. | | `color` | query | string (hex, no #) | no | Explicit 6-char hex foreground — overrides company branding. | | `backgroundColor` | query | string (hex, no #) | no | Solid backing colour, 6- or 8-char hex (8 = RGBA). | ## Examples ```bash # SVG (default) curl -sS https://app.tracepass.eu/api/v1/passports/6650b2c3d4e5f6a7b8c9d0e1/qr \ -H "Authorization: Bearer tp_REDACTED_xxxxxxxxxxxx" -o passport-qr.svg # Branded PNG curl -sS \ "https://app.tracepass.eu/api/v1/passports/6650b2c3d4e5f6a7b8c9d0e1/qr?format=png&color=FF6600" \ -H "Authorization: Bearer tp_REDACTED_xxxxxxxxxxxx" -o passport-qr.png ``` ```typescript const url = new URL( `https://app.tracepass.eu/api/v1/passports/${id}/qr`, ); url.searchParams.set("format", "png"); url.searchParams.set("useCompanyBranding", "true"); const res = await fetch(url, { headers: { Authorization: `Bearer ${process.env.TRACEPASS_API_KEY}` }, }); const pngBytes = new Uint8Array(await res.arrayBuffer()); ``` ```python import os, requests res = requests.get( f"https://app.tracepass.eu/api/v1/passports/{passport_id}/qr", headers={"Authorization": f"Bearer {os.environ['TRACEPASS_API_KEY']}"}, params={"format": "png", "useCompanyBranding": "true"}, ) res.raise_for_status() open("passport-qr.png", "wb").write(res.content) ``` ## Responses ### 200 — SVG ```json ``` ### 200 — ?format=json ```json { "result": "" } ``` ### 400 — Bad colour ```json { "error": "Invalid color (expect hex without '#', e.g. FF6600)" } ``` ### 404 — Not found ```json { "error": "Passport not found" } ``` ## Related - [Get a single passport](https://www.tracepass.eu/docs/get-passport.md) - [Create a passport](https://www.tracepass.eu/docs/create-passport.md) --- --- title: Check passport registry readiness description: "Check whether a passport would pass the EU DPP Registry's formal submission gate — mandatory fields, formatting, and a resolvable link. Battery only." canonical: "https://www.tracepass.eu/docs/passport-registry-readiness" locale: en source: "https://www.tracepass.eu/docs/passport-registry-readiness" --- # Check passport registry readiness > Check whether a passport would pass the EU DPP Registry's formal submission gate — mandatory fields, formatting, and a resolvable link. Battery only. ```http GET /api/v1/passports/{id}/registry-readiness ``` Returns whether a passport would pass the **EU DPP Registry's formal submission gate** — `{ ready, findings[] }`. This is the registry's *mechanical* pre-submission check, distinct from and complementary to the substantive `/compliance` verdict: a passport can be registry-ready yet not substantively compliant, and vice-versa. Call it before submitting to the registry to catch formal gaps early. Five formal checks, each carried on the standard finding shape with a `REG-READY-*` `ruleId`. **`REG-READY-MANDATORY`**: every mandatory field that applies to this battery type is present and approved — applicability-aware, so a field not applicable to the battery's category (e.g. state-of-certified-energy on a non-EV battery) is not counted as missing, and an `unknown`-applicability field surfaces as a warning, not a block. **`REG-READY-FORMAT`**: filled fields are well-formed (types, enums, patterns, ranges). **`REG-READY-LINK`**: the passport's public link resolves — a live probe; on an unpublished passport this is an advisory warning rather than a block, since the preflight is meant to run before publishing. **`REG-READY-GRANULARITY`**: the passport carries a serial number — batteries register at item-level granularity, so a missing serial is a block. **`REG-READY-COMMODITY`**: the commodity code (CN/TARIC) is well-formed where the category carries one; batteries carry no commodity code, so for batteries this is an advisory warning only, never a block. `ready` is `true` only when there are zero critical findings; warnings never block readiness. **Battery passports only** in this version — a non-battery passport returns `ready: true` with a single `REG-READY-SCOPE` warning, because the registry's formal gate for other categories isn't modelled yet. Read-only; counts as one v1 passport read against the daily cap. ## Parameters | Name | In | Type | Required | Description | | --- | --- | --- | --- | --- | | `Authorization` | header | string | yes | `Bearer ` — either a `tp_` API key (Developer → API Keys; simplest, for server-to-server) or an OAuth 2.0 access token (Developer → OAuth Apps; for user-authorized apps, scoped + revocable). The Authentication page has the full OAuth flow and scope list. | | `id` | path | ObjectId | yes | Passport ID. | ## Examples ```bash curl -sS \ https://app.tracepass.eu/api/v1/passports/6650b2c3d4e5f6a7b8c9d0e1/registry-readiness \ -H "Authorization: Bearer tp_REDACTED_xxxxxxxxxxxx" ``` ```typescript const res = await fetch( `https://app.tracepass.eu/api/v1/passports/${id}/registry-readiness`, { headers: { Authorization: `Bearer ${process.env.TRACEPASS_API_KEY}` } }, ); const result = await res.json(); if (!result.ready) { // Each critical finding names the formal gap that blocks registry submission. for (const f of result.findings.filter((x) => x.severity === "critical")) { console.log(`${f.ruleId}: ${f.target ?? ""} — ${f.why}`); } } ``` ```python import os, requests res = requests.get( f"https://app.tracepass.eu/api/v1/passports/{passport_id}/registry-readiness", headers={"Authorization": f"Bearer {os.environ['TRACEPASS_API_KEY']}"}, ) res.raise_for_status() result = res.json() if not result["ready"]: for f in [x for x in result["findings"] if x["severity"] == "critical"]: print(f["ruleId"], f.get("target", ""), "—", f["why"]) ``` ## Responses ### 200 — not ready ```json { "ready": false, "findings": [ { "type": "missing_field", "severity": "critical", "target": "batteryUniqueIdentifier", "ruleId": "REG-READY-MANDATORY", "why": "A mandatory field that applies to this battery is missing.", "fix": "Provide batteryUniqueIdentifier before submitting to the registry." }, { "type": "unverifiable_conditional", "severity": "warning", "target": "https://id.tracepass.eu/p/01/...", "ruleId": "REG-READY-LINK", "why": "This passport isn't published yet, so the registry link can't be checked live." } ] } ``` ### 200 — ready ```json { "ready": true, "findings": [] } ``` ### 404 — Not found ```json { "error": "Passport not found" } ``` ## Related - [Compliance verdict](https://www.tracepass.eu/docs/passport-compliance.md) - [Get a single passport](https://www.tracepass.eu/docs/get-passport.md) - [Update a field](https://www.tracepass.eu/docs/update-field.md) --- --- title: Passports description: Create, update, suspend, archive, and bulk-import Digital Product Passports. Includes the parties block for economic-operator chains. canonical: "https://www.tracepass.eu/docs/passports" locale: en source: "https://www.tracepass.eu/docs/passports" --- # Passports > Create, update, suspend, archive, and bulk-import Digital Product Passports. Includes the parties block for economic-operator chains. Create, update, suspend, archive, and bulk-import Digital Product Passports. Includes the parties block for economic-operator chains. ## Endpoints - [Create a passport](https://www.tracepass.eu/docs/create-passport.md) — `POST /api/v1/passports` - [Get a single passport](https://www.tracepass.eu/docs/get-passport.md) — `GET /api/v1/passports/{id}` - [Render the passport QR](https://www.tracepass.eu/docs/passport-qr.md) — `GET /api/v1/passports/{id}/qr` - [Check passport compliance](https://www.tracepass.eu/docs/passport-compliance.md) — `GET /api/v1/passports/{id}/compliance` - [Check passport registry readiness](https://www.tracepass.eu/docs/passport-registry-readiness.md) — `GET /api/v1/passports/{id}/registry-readiness` - [List passports](https://www.tracepass.eu/docs/list-passports.md) — `GET /api/v1/passports` - [Update one field on a passport](https://www.tracepass.eu/docs/update-field.md) — `PATCH /api/v1/passports/{id}/fields/{key}` - [Upsert an economic-operator party](https://www.tracepass.eu/docs/upsert-party.md) — `PATCH /api/v1/passports/{id}/parties/{role}` - [Suspend a passport](https://www.tracepass.eu/docs/suspend-passport.md) — `POST /api/v1/passports/{id}/suspend` - [Archive a passport (irreversible)](https://www.tracepass.eu/docs/archive-passport.md) — `POST /api/v1/passports/{id}/archive` - [Delete a passport permanently](https://www.tracepass.eu/docs/delete-passport.md) — `DELETE /api/v1/passports/{id}` - [Batch-create passports](https://www.tracepass.eu/docs/batch-create-passports.md) — `POST /api/v1/passports/batch` --- --- title: Products description: The catalog layer — products, images, batches. One product can have many passports (one per serialised unit). canonical: "https://www.tracepass.eu/docs/products" locale: en source: "https://www.tracepass.eu/docs/products" --- # Products > The catalog layer — products, images, batches. One product can have many passports (one per serialised unit). The catalog layer — products, images, batches. One product can have many passports (one per serialised unit). ## Endpoints - [Create a product](https://www.tracepass.eu/docs/create-product.md) — `POST /api/v1/products` - [Get a single product](https://www.tracepass.eu/docs/get-product.md) — `GET /api/v1/products/{id}` - [List products](https://www.tracepass.eu/docs/list-products.md) — `GET /api/v1/products` - [Update a product](https://www.tracepass.eu/docs/update-product.md) — `PATCH /api/v1/products/{id}` - [Upload a product image](https://www.tracepass.eu/docs/upload-product-image.md) — `POST /api/v1/products/{id}/images` - [Archive a product](https://www.tracepass.eu/docs/archive-product.md) — `POST /api/v1/products/{id}/archive` - [Delete a product permanently](https://www.tracepass.eu/docs/delete-product.md) — `DELETE /api/v1/products/{id}` --- --- title: Query EPCIS events description: GS1 EPCIS 2.0 query endpoint. Search events via EQ_bizStep / GE_eventTime / MATCH_epc and the standard EPCIS query grammar. Returns an EPCISQueryDocument. canonical: "https://www.tracepass.eu/docs/query-events" locale: en source: "https://www.tracepass.eu/docs/query-events" --- # Query EPCIS events > GS1 EPCIS 2.0 query endpoint. Search events via EQ_bizStep / GE_eventTime / MATCH_epc and the standard EPCIS query grammar. Returns an EPCISQueryDocument. ```http GET /api/v1/epcis/events ``` Search your captured supply-chain events using EPCIS 2.0 query parameters. Eight are supported: `EQ_bizStep`, `EQ_disposition`, `EQ_eventType`, `MATCH_epc`, `EQ_bizLocation`, `EQ_readPoint`, `GE_eventTime` and `LT_eventTime`. Values may be `|`-separated to match any of several (`EQ_bizStep=shipping|receiving`). Any other parameter returns `400` rather than being silently ignored, so a typo fails loudly instead of widening your result set. Results come back as a standards-valid `EPCISQueryDocument` (`Content-Type: application/ld+json`), newest first, and only ever include events your own workspace captured and approved. A response caps at 1000 events; if there were more, `X-TracePass-Result-Truncated: true` is set — narrow the window with `GE_eventTime` / `LT_eventTime` to page through. Counts as one read. Plan gate: EPCIS query is included on every paid plan (and on Free against an empty index — useful for integration validation). The 403 `epcis_query_not_available` path is only reachable on workspaces whose `epcisCaptureEnabled` flag has been disabled via per-tenant override. A lapsed subscription returns `402`. The query node is provisioned on request rather than by default — until it is deployed for your workspace the endpoint returns `503 {"error":"epcis_query_node_unavailable"}`; contact support to have it stood up. ## Parameters | Name | In | Type | Required | Description | | --- | --- | --- | --- | --- | | `Authorization` | header | string | yes | `Bearer ` — either a `tp_` API key (Developer → API Keys; simplest, for server-to-server) or an OAuth 2.0 access token (Developer → OAuth Apps; for user-authorized apps, scoped + revocable). The Authentication page has the full OAuth flow and scope list. | | `EQ_bizStep` | query | string | no | Standard EPCIS query parameter — matches events whose `bizStep` equals the given CBV value (e.g. `shipping`, `receiving`). Passed through verbatim to the EPCIS query interface. | | `GE_eventTime` | query | string (ISO 8601) | no | Standard EPCIS query parameter — matches events whose `eventTime` is greater than or equal to the given timestamp. Pair with `LT_eventTime` for a window. Passed through verbatim. | | `MATCH_epc` | query | string | no | Standard EPCIS query parameter — matches events whose `epcList` contains the given EPC (a TracePass passport Digital Link URI). Passed through verbatim. | ## Examples ```bash # All shipping events for one passport in a time window curl -sS -G https://app.tracepass.eu/api/v1/epcis/events \ -H "Authorization: Bearer tp_REDACTED_xxxxxxxxxxxx" \ --data-urlencode "EQ_bizStep=shipping" \ --data-urlencode "GE_eventTime=2026-01-01T00:00:00.000Z" \ --data-urlencode "LT_eventTime=2026-06-01T00:00:00.000Z" \ --data-urlencode "MATCH_epc=https://id.tracepass.eu/p/01/04012345000016/21/BP-48V-100-000001" ``` ```typescript const url = new URL("https://app.tracepass.eu/api/v1/epcis/events"); url.searchParams.set("EQ_bizStep", "shipping"); url.searchParams.set("GE_eventTime", "2026-01-01T00:00:00.000Z"); url.searchParams.set("LT_eventTime", "2026-06-01T00:00:00.000Z"); url.searchParams.set( "MATCH_epc", "https://id.tracepass.eu/p/01/04012345000016/21/BP-48V-100-000001", ); const res = await fetch(url, { headers: { Authorization: `Bearer ${process.env.TRACEPASS_API_KEY}` }, }); if (res.status === 503) throw new Error("Query node not provisioned"); const queryDocument = await res.json(); // EPCISQueryDocument ``` ```python import os, requests res = requests.get( "https://app.tracepass.eu/api/v1/epcis/events", headers={"Authorization": f"Bearer {os.environ['TRACEPASS_API_KEY']}"}, params={ "EQ_bizStep": "shipping", "GE_eventTime": "2026-01-01T00:00:00.000Z", "LT_eventTime": "2026-06-01T00:00:00.000Z", "MATCH_epc": "https://id.tracepass.eu/p/01/04012345000016/21/BP-48V-100-000001", }, ) res.raise_for_status() query_document = res.json() # EPCISQueryDocument ``` ## Responses ### 200 — OK ```json { "@context": "https://ref.gs1.org/standards/epcis/2.0.0/epcis-context.jsonld", "type": "EPCISQueryDocument", "schemaVersion": "2.0", "creationDate": "2026-05-09T12:00:00.000Z", "epcisBody": { "queryResults": { "resultsBody": { "eventList": [ { "type": "ObjectEvent", "eventID": "ni:///sha-256;9f86d0...?ver=CBV2.0", "eventTime": "2026-05-09T11:58:00.000Z", "eventTimeZoneOffset": "+02:00", "epcList": ["https://id.tracepass.eu/p/01/04012345000016/21/BP-48V-100-000001"], "action": "OBSERVE", "bizStep": "shipping" } ] } } } } ``` ### 401 — Missing API key ```json { "error": "Missing or invalid API key" } ``` ### 402 — Subscription required ```json { "error": "Active paid subscription required" } ``` ### 403 — Add-on not enabled ```json { "error": "epcis_query_not_available" } ``` ### 503 — Query node unavailable ```json { "error": "epcis_query_node_unavailable" } ``` ## Related - [Capture EPCIS events](https://www.tracepass.eu/docs/capture-events.md) - [Export a passport's EPCIS events](https://www.tracepass.eu/docs/passport-epcis-export.md) --- --- title: Quickstart description: Create your first passport in five minutes — register, mint an API key, post a single passport, scan the QR. canonical: "https://www.tracepass.eu/docs/quickstart" locale: en source: "https://www.tracepass.eu/docs/quickstart" --- # Quickstart > Create your first passport in five minutes — register, mint an API key, post a single passport, scan the QR. Five minutes from signup to a draft Digital Product Passport. This guide ships the smallest possible working example — one product, one passport, no parties, no webhooks. Layer those in once you've seen the round-trip. ## Before you start You need a TracePass workspace on **any plan, including Free** — v1 API access is on every tier. Only Free (100/day) and Basic (200/day) have a daily call cap; Starter and above are unlimited. Sign up at [app.tracepass.eu/register](https://app.tracepass.eu/register), then come back here. The examples below assume the production base URL `https://app.tracepass.eu`; substitute your own host if you're running self-hosted. ## 1\. Mint an API key 1. Open **Developer → API keys** in the dashboard. 2. Click **New key**, give it a label (“Quickstart” works), and copy the secret. Keys start with the `tp_` prefix followed by an opaque random suffix — store them in your secret manager, not in source control. 3. Every API call carries the key as a Bearer token in the standard`Authorization` header. We'll mask it as`tp_REDACTED_xxxxxxxxxxxx` everywhere below. ## 2\. Create a product Passports always belong to a product, and a product is bound to a category template that drives field validation, JSON-LD emission, and the public viewer's rendering. Categories are seeded — pick the slug that matches your goods. For batteries it's `batteries`; for textiles, `textiles`; for jewelry, `jewelry`. The full list is in the public Buyer's Guide. ```bash curl -sS https://app.tracepass.eu/api/v1/products \ -H "Authorization: Bearer tp_REDACTED_xxxxxxxxxxxx" \ -H "Content-Type: application/json" \ -d '{ "name": "48V Li-Ion Pack", "model": "BP-48V-100", "category": "batteries" }' ``` The 201 response includes a `_id` — that's your product handle. Hold onto it for step 3. ## 3\. Create a passport A passport is one serialised unit of a product. Set `productId` to the product you just created, supply a 14-digit GS1 GTIN (with valid check digit) plus a serial unique within the GTIN. The passport materialises in `draft` status — fields are populated via the per-field PATCH endpoint, then the passport is published from the dashboard once review is complete. ```bash curl -sS https://app.tracepass.eu/api/v1/passports \ -H "Authorization: Bearer tp_REDACTED_xxxxxxxxxxxx" \ -H "Content-Type: application/json" \ -d '{ "productId": "6650a1b2c3d4e5f6a7b8c9d0", "gs1": { "gtin": "04012345000016", "serialNumber": "BP-48V-100-000001" } }' ``` The 201 response carries `gs1.digitalLinkUri` — the GS1 Digital Link URL you can encode into a QR code today, even before the passport is published. Until publish the URL returns a 503 placeholder; after publish it serves the public viewer (HTML by default, `application/ld+json` on content negotiation). ## 4\. Scan the QR After you've filled out fields and published the passport from the dashboard, open `gs1.digitalLinkUri` in a browser — that's exactly what an end consumer or a regulator's mobile scanner would render. The same URL with `Accept: application/ld+json` returns the JSON-LD document for machine consumers (auditors, EPREL ingestion, the upcoming EU DPP registry). ```bash curl -sSL https://id.tracepass.eu/p/01/04012345000016/21/BP-48V-100-000001 \ -H "Accept: application/ld+json" ``` ### Where next You now have one passport. The two follow-ups most teams ship next are: (a) attach economic-operator parties so the regulator's required-roles check passes — see the [Upsert party](/docs/upsert-party) endpoint; (b) wire a webhook so your ERP learns about lifecycle changes (publish, suspend, archive) — see the [Webhooks](/docs/webhooks) section. **Tip —** Treat every `POST` / `PATCH` / `DELETE` as idempotent by sending an `Idempotency-Key` header with a UUID v4 your client generates per logical operation. The platform replays the original response for 24 hours on the same key, so a network retry is safe. --- --- title: Suspend a passport description: Reversibly suspend a passport — public viewer returns HTTP 423 with structured body. Use for recalls, disputes, holds, product-quality investigations. canonical: "https://www.tracepass.eu/docs/suspend-passport" locale: en source: "https://www.tracepass.eu/docs/suspend-passport" --- # Suspend a passport > Reversibly suspend a passport — public viewer returns HTTP 423 with structured body. Use for recalls, disputes, holds, product-quality investigations. ```http POST /api/v1/passports/{id}/suspend ``` Reversible suspend. The public viewer flips to the suspended state page (HTTP 423 with structured body); QR scans effectively die without the URL going to 404. Use for recalls, disputes, internal holds, or product-quality investigations. Republish from the dashboard once resolved. Optional body `{ reason: string }` — surfaces in the `passport.suspended` webhook payload and the dashboard audit trail (truncated at 500 chars). Empty body is fine; the suspend still fires the webhook. Counts as one v1 write. Honours `Idempotency-Key`. The matching `POST /api/v1/passports/by-serial/{serial}/suspend` is the by-serial alternate. ## Parameters | Name | In | Type | Required | Description | | --- | --- | --- | --- | --- | | `Authorization` | header | string | yes | `Bearer ` — either a `tp_` API key (Developer → API Keys; simplest, for server-to-server) or an OAuth 2.0 access token (Developer → OAuth Apps; for user-authorized apps, scoped + revocable). The Authentication page has the full OAuth flow and scope list. | | `Idempotency-Key` | header | string | no | UUID v4. | | `id` | path | ObjectId | yes | Passport ID. | | `reason` | body | string (≤ 500) | no | Free-text suspension reason. | ## Examples ```bash curl -sS -X POST \ https://app.tracepass.eu/api/v1/passports/6650b2c3d4e5f6a7b8c9d0e1/suspend \ -H "Authorization: Bearer tp_REDACTED_xxxxxxxxxxxx" \ -H "Content-Type: application/json" \ -d '{ "reason": "Quality investigation pending — batch BB-2026-04-12." }' ``` ```typescript await fetch( `https://app.tracepass.eu/api/v1/passports/${id}/suspend`, { method: "POST", headers: { Authorization: `Bearer ${process.env.TRACEPASS_API_KEY}`, "Content-Type": "application/json", }, body: JSON.stringify({ reason: "Quality investigation pending" }), }, ); ``` ```python import os, requests res = requests.post( f"https://app.tracepass.eu/api/v1/passports/{passport_id}/suspend", headers={"Authorization": f"Bearer {os.environ['TRACEPASS_API_KEY']}"}, json={"reason": "Quality investigation pending"}, ) res.raise_for_status() ``` ## Responses ### 200 — Suspended ```json { "_id": "6650b2c3d4e5f6a7b8c9d0e1", "status": "suspended", "suspendedAt": "2026-05-09T16:00:00.000Z", "suspensionReason": "Quality investigation pending — batch BB-2026-04-12." } ``` ### 422 — Wrong status ```json { "error": "Cannot suspend passport in status 'archived'" } ``` ### 404 — Not found ```json { "error": "Passport not found" } ``` ## Related - [Archive a passport (irreversible)](https://www.tracepass.eu/docs/archive-passport.md) - [Get passport](https://www.tracepass.eu/docs/get-passport.md) --- --- title: Templates description: "The DPP category field schemas — discover what a compliant passport in each category requires before you build it: field counts and the governing regulation." canonical: "https://www.tracepass.eu/docs/templates" locale: en source: "https://www.tracepass.eu/docs/templates" --- # Templates > The DPP category field schemas — discover what a compliant passport in each category requires before you build it: field counts and the governing regulation. The DPP category field schemas — discover what a compliant passport in each category requires before you build it: field counts and the governing regulation. ## Endpoints - [List category templates](https://www.tracepass.eu/docs/list-templates.md) — `GET /api/v1/templates` - [Get a category template](https://www.tracepass.eu/docs/get-template.md) — `GET /api/v1/templates/{category}` --- --- title: Bulk JSON-LD tenant export description: Full workspace export as one JSON-LD document — every product, passport, and template reference. Dashboard JWT only (admin role); not API-key reachable. canonical: "https://www.tracepass.eu/docs/tenant-export" locale: en source: "https://www.tracepass.eu/docs/tenant-export" --- # Bulk JSON-LD tenant export > Full workspace export as one JSON-LD document — every product, passport, and template reference. Dashboard JWT only (admin role); not API-key reachable. ```http GET /api/exports/tenant ``` Returns every product, every passport (regardless of status), and every referenced category template the workspace owns, as one JSON-LD document. The shape mirrors the public passport viewer's per-passport JSON-LD emission, wrapped in a tenant envelope with metadata about the export run. **Not API-key reachable.** Auth is dashboard JWT (admin role) + paying-customer gate — same trust level as deleting the company. The pragmatic flow is: open Settings → Data export in the dashboard and click "Export tenant". Programmatic access requires a session cookie issued by `/api/auth/login`. Synchronous response with `Content-Disposition: attachment; filename="tracepass-tenant-export--.jsonld"`. Includes evidence-document URLs but not the document bytes themselves; fetch those separately if you need offline copies. No pagination — all-or-nothing. ## Parameters | Name | In | Type | Required | Description | | --- | --- | --- | --- | --- | | `Cookie` | header | string | yes | Dashboard session cookie (`tp_session=...`) issued by `/api/auth/login`. Browsers attach it automatically when the export is initiated from the dashboard. | | `Accept` | header | string | no | `application/ld+json` (default) or `application/json`. Byte-equivalent — only the response Content-Type changes. | ## Examples ```bash # In practice: open Settings -> Data export in the dashboard. # For curl, capture the session cookie after a login first: curl -sS -L \ --cookie "tp_session=$TRACEPASS_SESSION_COOKIE" \ -H "Accept: application/ld+json" \ -o tenant-export.jsonld \ https://app.tracepass.eu/api/exports/tenant ``` ```typescript import { createWriteStream } from "node:fs"; import { Readable } from "node:stream"; import { finished } from "node:stream/promises"; // session cookie captured from a prior /api/auth/login call const cookie = process.env.TRACEPASS_SESSION_COOKIE!; const res = await fetch("https://app.tracepass.eu/api/exports/tenant", { headers: { Cookie: `tp_session=${cookie}`, Accept: "application/ld+json", }, }); if (!res.ok || !res.body) throw new Error(`Export failed: ${res.status}`); const dest = createWriteStream("tenant-export.jsonld"); await finished(Readable.fromWeb(res.body).pipe(dest)); ``` ```python import os, requests cookie = os.environ["TRACEPASS_SESSION_COOKIE"] with requests.get( "https://app.tracepass.eu/api/exports/tenant", cookies={"tp_session": cookie}, headers={"Accept": "application/ld+json"}, stream=True, ) as res: res.raise_for_status() with open("tenant-export.jsonld", "wb") as fh: for chunk in res.iter_content(chunk_size=1024 * 64): fh.write(chunk) ``` ## Responses ### 200 — OK ```json { "@context": "https://app.tracepass.eu/schemas/tenant-export-v1.jsonld", "@type": "TenantExport", "exportedAt": "2026-05-09T12:00:00.000Z", "company": { "_id": "...", "name": "Acme Batteries Ltd", "country": "DE" }, "counts": { "products": 12, "passports": 4327, "templates": 3 }, "products": [ { "...": "...one entry per product..." } ], "passports": [ { "...": "...one entry per passport, with full fieldValues + parties..." } ], "templates": [ { "id": "...", "category": "batteries", "version": "v3" } ] } ``` ### 401 — Not signed in ```json { "error": "Authentication required" } ``` ### 402 — Subscription required ```json { "error": "Active paid subscription required" } ``` ### 403 — Forbidden ```json { "error": "admin role required" } ``` ## Related - [Create a passport](https://www.tracepass.eu/docs/create-passport.md) --- --- title: Update one field on a passport description: Patch one field on a passport with audit trail entry. Defaults to status approved; override to ai_suggested or supplier to route into the review queue. canonical: "https://www.tracepass.eu/docs/update-field" locale: en source: "https://www.tracepass.eu/docs/update-field" --- # Update one field on a passport > Patch one field on a passport with audit trail entry. Defaults to status approved; override to ai_suggested or supplier to route into the review queue. ```http PATCH /api/v1/passports/{id}/fields/{key} ``` Patch a single field on a passport. The value is validated against the field key (must exist on the passport's template) and persisted with an audit trail entry tagged `via API key `. Use this in preference to writing the whole `fields` map when you only need to update one number — it's a smaller write and the per-field audit entry is what dashboard reviewers see. Writes default to `status: "approved"` — API-key-driven integrations are trusted by convention (unlike dashboard editors, where non-admins write `pending_review`). Override with `source: "ai_suggested"` or `source: "supplier"` if you want the value to land in the review queue instead. An alternate addressing form exists at PATCH /api/v1/passports/by-serial/{serial}/fields/{key} — same body, same response, useful when your ERP only knows the customer-side serial. Counts as one v1 write. Honours `Idempotency-Key`. ## Parameters | Name | In | Type | Required | Description | | --- | --- | --- | --- | --- | | `Authorization` | header | string | yes | `Bearer ` — either a `tp_` API key (Developer → API Keys; simplest, for server-to-server) or an OAuth 2.0 access token (Developer → OAuth Apps; for user-authorized apps, scoped + revocable). The Authentication page has the full OAuth flow and scope list. | | `Idempotency-Key` | header | string | no | UUID v4 per logical operation. | | `id` | path | ObjectId | yes | Passport ID. To address by serial instead, use PATCH /api/v1/passports/by-serial/{serial}/fields/{key}. | | `key` | path | string | yes | Field key (camelCase) as defined on the passport's template — e.g. `nominalVoltage`, `batteryChemistry`, `recycledContentCobalt`. 400 if the key isn't on the template. | | `value` | body | string \| number \| boolean \| array \| object | yes | New value. The platform doesn't reformat strings into numbers — send the value in the type the template field expects. | | `source` | body | enum | no | Tag the origin of the value. One of: `manual`, `ai_suggested`, `ai_approved`, `reference_db`, `supplier`, `system`. Default `manual`. `ai_suggested` and `supplier` land in the review queue; everything else writes as approved. | | `sourceLocale` | body | string (ISO 639-1) | no | Locale of the value (one of the 24 EU locales). Drives translation direction + the public viewer's language resolution. Defaults to the passport's `sourceLocale` when omitted. | ## Examples ```bash curl -sS -X PATCH \ https://app.tracepass.eu/api/v1/passports/6650b2c3d4e5f6a7b8c9d0e1/fields/ratedCapacity \ -H "Authorization: Bearer tp_REDACTED_xxxxxxxxxxxx" \ -H "Content-Type: application/json" \ -d '{ "value": 5.24 }' ``` ```typescript await fetch( `https://app.tracepass.eu/api/v1/passports/${id}/fields/ratedCapacity`, { method: "PATCH", headers: { Authorization: `Bearer ${process.env.TRACEPASS_API_KEY}`, "Content-Type": "application/json", }, body: JSON.stringify({ value: 5.24 }), }, ); ``` ```python import os, requests res = requests.patch( f"https://app.tracepass.eu/api/v1/passports/{passport_id}/fields/ratedCapacity", headers={"Authorization": f"Bearer {os.environ['TRACEPASS_API_KEY']}"}, json={"value": 5.24}, ) res.raise_for_status() ``` ## Responses ### 200 — Updated ```json { "field": { "value": 5.24, "source": "manual", "status": "approved", "accessLevel": "public", "sourceLocale": "en", "lastUpdatedAt": "2026-05-09T10:30:00.000Z", "lastUpdatedBy": "api_key:tp_89b2482d" }, "version": 4 } ``` ### 400 — Invalid field key ```json { "error": "Invalid field key: notARealField" } ``` ### 404 — Not found ```json { "error": "Passport not found" } ``` ## Related - [Create a passport](https://www.tracepass.eu/docs/create-passport.md) - [Attach an economic-operator party](https://www.tracepass.eu/docs/upsert-party.md) --- --- title: Update a product description: Update product fields by sending only what changes. imageUrls REPLACES the existing array (your CMS stays canonical). Idempotency-Key supported. canonical: "https://www.tracepass.eu/docs/update-product" locale: en source: "https://www.tracepass.eu/docs/update-product" --- # Update a product > Update product fields by sending only what changes. imageUrls REPLACES the existing array (your CMS stays canonical). Idempotency-Key supported. ```http PATCH /api/v1/products/{id} ``` Patch one or more product fields. Send only the keys you want to change — omitted fields stay untouched. The whole-array semantics on `imageUrls` are intentional: your CMS is the canonical image set, so a PATCH with `imageUrls: ["a","b"]` replaces whatever was there. To append a single image without rewriting the list, use the multipart upload endpoint instead. Counts as one v1 write. Honours `Idempotency-Key`. `model` uniqueness is re-checked when changed; `description: null` clears the description (distinct from omitting the key). ## Parameters | Name | In | Type | Required | Description | | --- | --- | --- | --- | --- | | `Authorization` | header | string | yes | `Bearer ` — either a `tp_` API key (Developer → API Keys; simplest, for server-to-server) or an OAuth 2.0 access token (Developer → OAuth Apps; for user-authorized apps, scoped + revocable). The Authentication page has the full OAuth flow and scope list. | | `Idempotency-Key` | header | string | no | UUID v4. | | `id` | path | ObjectId | yes | Product ID. | | `name` | body | string (1-200) | no | Display name. | | `model` | body | string (1-100) | no | Model identifier. Uniqueness re-checked when changed. | | `description` | body | string \| null (≤ 2000) | no | Pass `null` to clear. | | `defaultFieldValues` | body | object | no | Replaces seed values for future passports. | | `imageUrls` | body | string\[\] (max 20) | no | Replaces the full image array. | | `status` | body | enum | no | `active` or `archived`. | | `sourceLocale` | body | string (ISO 639-1) | no | Update the locale of `name` / `description`. | ## Examples ```bash curl -sS -X PATCH \ https://app.tracepass.eu/api/v1/products/6650a1b2c3d4e5f6a7b8c9d0 \ -H "Authorization: Bearer tp_REDACTED_xxxxxxxxxxxx" \ -H "Content-Type: application/json" \ -d '{ "name": "Li-Ion 48V Battery Pack (revised)", "imageUrls": ["https://cdn.example.com/new-hero.jpg"] }' ``` ```typescript await fetch(`https://app.tracepass.eu/api/v1/products/${id}`, { method: "PATCH", headers: { Authorization: `Bearer ${process.env.TRACEPASS_API_KEY}`, "Content-Type": "application/json", }, body: JSON.stringify({ name: "Li-Ion 48V Battery Pack (revised)", imageUrls: ["https://cdn.example.com/new-hero.jpg"], }), }); ``` ```python import os, requests res = requests.patch( f"https://app.tracepass.eu/api/v1/products/{product_id}", headers={"Authorization": f"Bearer {os.environ['TRACEPASS_API_KEY']}"}, json={ "name": "Li-Ion 48V Battery Pack (revised)", "imageUrls": ["https://cdn.example.com/new-hero.jpg"], }, ) res.raise_for_status() ``` ## Responses ### 200 — Updated ```json { "_id": "6650a1b2c3d4e5f6a7b8c9d0", "name": "Li-Ion 48V Battery Pack (revised)", "imageUrls": ["https://cdn.example.com/new-hero.jpg"], "updatedAt": "2026-05-09T15:30:00.000Z" } ``` ### 404 — Not found ```json { "error": "Product not found" } ``` ### 409 — Duplicate model ```json { "error": "A product with this model already exists for your company" } ``` ## Related - [Create a product](https://www.tracepass.eu/docs/create-product.md) - [Upload product image](https://www.tracepass.eu/docs/upload-product-image.md) --- --- title: Upload a product image description: "Multipart upload of a single image to the product. PNG/JPG/WebP, ≤5 MB, max 20 images. No Idempotency-Key (multipart can't be hashed safely)." canonical: "https://www.tracepass.eu/docs/upload-product-image" locale: en source: "https://www.tracepass.eu/docs/upload-product-image" --- # Upload a product image > Multipart upload of a single image to the product. PNG/JPG/WebP, ≤5 MB, max 20 images. No Idempotency-Key (multipart can't be hashed safely). ```http POST /api/v1/products/{id}/images ``` Upload a single image file (multipart/form-data, field name `file`) and append it to the product's `imageUrls` array. Use this when you don't have a CDN URL ready — the image lands in our R2 bucket and the public URL is returned in the response. PNG / JPG / WebP only, max 5 MB per file, max 20 images per product. **No Idempotency-Key support** — multipart bodies aren't safely hashable. Client should check existence + skip if retrying. The matching `DELETE /api/v1/products/{id}/images/{index}` removes a single image by zero-based index. ## Parameters | Name | In | Type | Required | Description | | --- | --- | --- | --- | --- | | `Authorization` | header | string | yes | `Bearer ` — either a `tp_` API key (Developer → API Keys; simplest, for server-to-server) or an OAuth 2.0 access token (Developer → OAuth Apps; for user-authorized apps, scoped + revocable). The Authentication page has the full OAuth flow and scope list. | | `Content-Type` | header | string | yes | `multipart/form-data` with the boundary parameter set by your HTTP client. | | `id` | path | ObjectId | yes | Product ID. | | `file` | body | binary (PNG / JPG / WebP, ≤ 5 MB) | yes | Image bytes posted as the `file` form field. | ## Examples ```bash curl -sS -X POST \ https://app.tracepass.eu/api/v1/products/6650a1b2c3d4e5f6a7b8c9d0/images \ -H "Authorization: Bearer tp_REDACTED_xxxxxxxxxxxx" \ -F "file=@./battery-hero.jpg" ``` ```typescript import { readFile } from "node:fs/promises"; const file = await readFile("./battery-hero.jpg"); const form = new FormData(); form.set("file", new Blob([file], { type: "image/jpeg" }), "battery-hero.jpg"); const res = await fetch( `https://app.tracepass.eu/api/v1/products/${id}/images`, { method: "POST", headers: { Authorization: `Bearer ${process.env.TRACEPASS_API_KEY}` }, body: form, }, ); if (!res.ok) throw new Error(`Upload failed: ${res.status}`); const { imageUrl, imageUrls } = await res.json(); ``` ```python import os, requests with open("battery-hero.jpg", "rb") as fh: res = requests.post( f"https://app.tracepass.eu/api/v1/products/{product_id}/images", headers={"Authorization": f"Bearer {os.environ['TRACEPASS_API_KEY']}"}, files={"file": ("battery-hero.jpg", fh, "image/jpeg")}, ) res.raise_for_status() data = res.json() print(data["imageUrl"]) ``` ## Responses ### 201 — Uploaded ```json { "imageUrl": "https://r2.tracepass.eu//products//images/.jpg", "imageUrls": [ "https://existing-image-1.jpg", "https://r2.tracepass.eu//products//images/.jpg" ] } ``` ### 400 — No file ```json { "error": "No file provided. Send as multipart/form-data with field name 'file'." } ``` ### 413 — Too large ```json { "error": "Image must be under 5MB" } ``` ### 415 — Unsupported ```json { "error": "Unsupported MIME type — accepts image/png, image/jpeg, image/webp" } ``` ### 422 — Cap reached ```json { "error": "Product already has 20 images (max). Delete one first." } ``` ## Related - [Update a product (replace imageUrls)](https://www.tracepass.eu/docs/update-product.md) - [Create a product](https://www.tracepass.eu/docs/create-product.md) --- --- title: Upsert an economic-operator party description: Set or replace one economic-operator party on a passport (manufacturer, importer, distributor, authorised representative). GLN validated. Audit-logged. canonical: "https://www.tracepass.eu/docs/upsert-party" locale: en source: "https://www.tracepass.eu/docs/upsert-party" --- # Upsert an economic-operator party > Set or replace one economic-operator party on a passport (manufacturer, importer, distributor, authorised representative). GLN validated. Audit-logged. ```http PATCH /api/v1/passports/{id}/parties/{role} ``` Create or replace the Party for a single role on a passport. The role path segment determines the slot you're writing — `manufacturer`, `importer`, `authorisedRepresentative`, `distributor`, `recycler`, `producerResponsibilityOrg`. Sending the same role twice is an upsert: the existing block is replaced atomically. Identity is fully expressed by the body: `legalName` (required), `gln` (GS1 Global Location Number — strongly recommended for multi-role disambiguation), `country` (ISO 3166-1 alpha-2), `legacyOperatorId` (VAT / EORI / supplier code as a free-text fallback), `url`. At least one of `gln` or `legacyOperatorId` must be set — without an identifier the Party doesn't actually identify anyone. When two roles share the same `gln`, the JSON-LD emission collapses them into one party with multiple roles. Counts as one v1 write. Honours `Idempotency-Key`. The Battery Regulation requires at least { manufacturer, importer (if applicable), recycler } before a passport is accepted; the platform's regulatory-completeness scorecard surfaces missing roles in the dashboard. The matching `DELETE /api/v1/passports/{id}/parties/{role}` removes a role idempotently. ## Parameters | Name | In | Type | Required | Description | | --- | --- | --- | --- | --- | | `Authorization` | header | string | yes | `Bearer ` — either a `tp_` API key (Developer → API Keys; simplest, for server-to-server) or an OAuth 2.0 access token (Developer → OAuth Apps; for user-authorized apps, scoped + revocable). The Authentication page has the full OAuth flow and scope list. | | `Idempotency-Key` | header | string | no | UUID v4 per logical operation. | | `id` | path | ObjectId | yes | Passport ID. | | `role` | path | enum | yes | One of: `manufacturer`, `importer`, `authorisedRepresentative`, `distributor`, `recycler`, `producerResponsibilityOrg`. Roles outside this list return 400. | | `legalName` | body | string (1-200 chars) | yes | Legal entity name as it appears in the commercial register. Required — a Party with no name doesn't help any procurement reader, regardless of which identifier it carries. | | `gln` | body | string (13 digits) | no | GS1 Global Location Number with valid mod-10 check digit. Strongly recommended — when two roles share the same `gln`, the JSON-LD emits a single party with both roles attached. Must validate as a real GLN; partial / digits-only strings return 400. | | `country` | body | string (ISO 3166-1 alpha-2) | no | Two-letter uppercase country code — e.g. `DE`, `BG`, `FR`. | | `legacyOperatorId` | body | string (1-120 chars) | no | Free-text fallback identifier for parties that don't have a GLN — VAT number, EORI, supplier code, or any internal ID your ERP carries. Required when `gln` is omitted. | | `url` | body | string (URL, max 500 chars) | no | Organisation page — typically the company website or a corporate-info subpage. | ## Examples ```bash curl -sS -X PATCH \ https://app.tracepass.eu/api/v1/passports/6650b2c3d4e5f6a7b8c9d0e1/parties/recycler \ -H "Authorization: Bearer tp_REDACTED_xxxxxxxxxxxx" \ -H "Content-Type: application/json" \ -d '{ "legalName": "EuroBat Recyclers GmbH", "gln": "4012345678901", "country": "DE", "url": "https://eurobat-recyclers.example" }' ``` ```typescript await fetch( `https://app.tracepass.eu/api/v1/passports/${id}/parties/recycler`, { method: "PATCH", headers: { Authorization: `Bearer ${process.env.TRACEPASS_API_KEY}`, "Content-Type": "application/json", }, body: JSON.stringify({ legalName: "EuroBat Recyclers GmbH", gln: "4012345678901", country: "DE", url: "https://eurobat-recyclers.example", }), }, ); ``` ```python import os, requests res = requests.patch( f"https://app.tracepass.eu/api/v1/passports/{passport_id}/parties/recycler", headers={"Authorization": f"Bearer {os.environ['TRACEPASS_API_KEY']}"}, json={ "legalName": "EuroBat Recyclers GmbH", "gln": "4012345678901", "country": "DE", "url": "https://eurobat-recyclers.example", }, ) res.raise_for_status() ``` ## Responses ### 200 — Upserted ```json { "role": "recycler", "party": { "legalName": "EuroBat Recyclers GmbH", "gln": "4012345678901", "country": "DE", "url": "https://eurobat-recyclers.example", "status": "active" }, "version": 5 } ``` ### 400 — Validation error ```json { "error": "Validation error", "details": { "fieldErrors": { "gln": ["Party must have at least one identifier (gln or legacyOperatorId)"] } } } ``` ### 404 — Not found ```json { "error": "Passport not found" } ``` ## Related - [Create a passport (parties at create time)](https://www.tracepass.eu/docs/create-passport.md) - [Update one field on a passport](https://www.tracepass.eu/docs/update-field.md) --- --- title: Webhooks description: HMAC-signed event delivery for passport lifecycle events. Retry ladder, signature verification, replay protection. canonical: "https://www.tracepass.eu/docs/webhooks" locale: en source: "https://www.tracepass.eu/docs/webhooks" --- # Webhooks > HMAC-signed event delivery for passport lifecycle events. Retry ladder, signature verification, replay protection. TracePass POSTs JSON-bodied events to your URL when passports, extractions, or supplier requests change state. Every delivery is HMAC-SHA-256 signed with a per-endpoint secret you control, retried on a fixed exponential ladder, and carries a stable`X-TracePass-Event-Id`for replay protection. ## Configuring an endpoint Open **Developer → Webhooks** in the dashboard. Add your URL, copy the per-endpoint signing secret (returned once at creation — capture it then, roll by delete + recreate), and select which events to deliver. You can have multiple endpoints — typically one for staging, one for production. The dashboard's **Send test** button fires a `webhook.test` envelope so you can wire the receiver before real events flow. ## Events | Event | Fires when | | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | passport.published | A passport transitions to status=published. | | passport.suspended | A passport is suspended via API or UI. The public viewer flips to a suspended state. | | passport.expired | A published passport's expiresAt timestamp passes (daily cron). Used by the revenue-protection moat after 30-day cancellation grace. | | passport.archived | A passport is archived. The public viewer returns 404 (404 not 410 — the URL behaves as if it never existed). | | extraction.completed | The multi-agent AI extraction pipeline finishes for a passport. Body carries the extraction id for follow-up reads. | | extraction.failed | An extraction session is beyond the 1h resume window without recovery — the orchestrator marks it failed. | | supplier.submitted | A supplier completes the token-auth supplier portal submission for one of your supplier requests. | | epcis.event.captured | One or more EPCIS 2.0 events are captured for a passport via the capture endpoint. | **Tip —** Per-subscription daily cap is a flat 10,000 deliveries to defend against a misconfigured endpoint chewing the queue. Hitting that cap pauses delivery for that endpoint until the next UTC day; nothing is lost — undelivered events stay in the queue and resume on the next tick. ## Verifying signatures Every request carries the signing trio: | Header | Value | | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | X-TracePass-Signature | v1=. | | X-TracePass-Timestamp | Unix seconds at signing time. Reject deliveries whose timestamp is more than 5 minutes off your clock — that's the replay-protection window. | | X-TracePass-Event | Event type name (e.g. passport.published). Lets your receiver dispatch without parsing JSON. | | X-TracePass-Event-Id | Stable across retries — dedupe on this. Mirrors the body's \`id\` field. | | X-TracePass-Delivery-Id | Per-attempt id. Use it for support correlation, not deduplication. | Re-compute the signature over `${timestamp}.${rawBody}` — the timestamp is concatenated with a literal `.` separator before the raw bytes. Don't reserialise the JSON; whitespace differences will flip the HMAC. Compare with a constant-time check. ### Node / TypeScript ```typescript import { createHmac, timingSafeEqual } from "node:crypto"; import express from "express"; const app = express(); const SECRET = process.env.TRACEPASS_WEBHOOK_SECRET!; // Capture the RAW body — needed for HMAC verification. app.post("/tracepass-webhook", express.raw({ type: "application/json" }), (req, res) => { const sigHeader = String(req.headers["x-tracepass-signature"] ?? ""); const ts = String(req.headers["x-tracepass-timestamp"] ?? ""); // 5-minute replay window. const now = Math.floor(Date.now() / 1000); if (Math.abs(now - Number(ts)) > 300) { return res.status(400).send("stale"); } // Parse the v1= envelope. const m = /^v1=([0-9a-f]+)$/i.exec(sigHeader); if (!m) return res.status(400).send("malformed signature header"); const provided = Buffer.from(m[1], "hex"); // HMAC over `${timestamp}.${body}`. const expected = createHmac("sha256", SECRET) .update(`${ts}.`) .update(req.body) .digest(); if ( provided.length !== expected.length || !timingSafeEqual(provided, expected) ) { return res.status(400).send("bad signature"); } const event = JSON.parse(req.body.toString("utf8")); // ... your handler ... res.status(200).send("ok"); }); ``` ### Python ```python import hmac, hashlib, os, time from flask import Flask, request, abort app = Flask(__name__) SECRET = os.environ["TRACEPASS_WEBHOOK_SECRET"].encode() @app.post("/tracepass-webhook") def handler(): sig_header = request.headers.get("X-TracePass-Signature", "") ts = request.headers.get("X-TracePass-Timestamp", "0") if abs(int(time.time()) - int(ts)) > 300: abort(400, "stale") if not sig_header.startswith("v1="): abort(400, "malformed signature header") provided = bytes.fromhex(sig_header[3:]) raw = request.get_data() expected = hmac.new(SECRET, f"{ts}.".encode() + raw, hashlib.sha256).digest() if not hmac.compare_digest(provided, expected): abort(400, "bad signature") event = request.get_json() # ... your handler ... return "ok", 200 ``` ### Go ```go func handler(w http.ResponseWriter, r *http.Request) { sigHeader := r.Header.Get("X-TracePass-Signature") ts := r.Header.Get("X-TracePass-Timestamp") tsInt, _ := strconv.ParseInt(ts, 10, 64) if math.Abs(float64(time.Now().Unix()-tsInt)) > 300 { http.Error(w, "stale", http.StatusBadRequest); return } if !strings.HasPrefix(sigHeader, "v1=") { http.Error(w, "malformed signature header", http.StatusBadRequest); return } provided, err := hex.DecodeString(strings.TrimPrefix(sigHeader, "v1=")) if err != nil { http.Error(w, "malformed signature header", http.StatusBadRequest); return } body, _ := io.ReadAll(r.Body) mac := hmac.New(sha256.New, []byte(os.Getenv("TRACEPASS_WEBHOOK_SECRET"))) mac.Write([]byte(ts + ".")) mac.Write(body) expected := mac.Sum(nil) if !hmac.Equal(provided, expected) { http.Error(w, "bad signature", http.StatusBadRequest); return } // parse body, dispatch event … w.WriteHeader(http.StatusOK) } ``` ## Retry ladder Delivery is considered successful when your endpoint returns a `2xx` within 10 seconds. Anything else (network error, timeout, 4xx, 5xx) triggers a retry on this fixed schedule, seven attempts total: | Attempt | Delay after previous attempt | | ----------- | ------------------------------ | | 1 (initial) | Immediate when the event fires | | 2 | 1 minute | | 3 | 5 minutes | | 4 | 30 minutes | | 5 | 2 hours | | 6 | 12 hours | | 7 (final) | 24 hours | After attempt 6 the delivery is parked in the dashboard's webhook event log with status `failed`; you can replay it manually from there. Delivery history retention is plan-scaled: Basic 30d, Starter 60, Growth 90, Scale 180, Pro 365, Enterprise 730\. The TTL is computed at insert from the company's plan, so changing plans doesn't retroactively expire old deliveries. ## Replay protection Treat `X-TracePass-Event-Id` as a deduplication key. It mirrors the body's `id` field, repeats across retries on purpose (so your receiver can no-op when it's already processed the event), and never repeats across distinct events. A SQL `UNIQUE` on the column, or a Redis `SET NX` with a 7-day TTL, both work. **Why the timestamp matters:** signature alone doesn't protect against a captured-and-replayed delivery. The 5-minute timestamp window plus eventId deduplication is the pair you need — drop either one and the attack surface widens. Stripe, Twilio, GitHub all enforce both; we follow the convention. --- --- title: Digital Product Passport field-by-field guides description: Free field-by-field Digital Product Passport guides for batteries, textiles, electronics and packaging — every mandatory EU field and where its data comes from. canonical: "https://www.tracepass.eu/guides" locale: en source: "https://www.tracepass.eu/guides" --- # Digital Product Passport field-by-field guides > Free field-by-field Digital Product Passport guides for batteries, textiles, electronics and packaging — every mandatory EU field and where its data comes from. Each guide breaks a single product category's Digital Product Passport down to the field level: what data is mandatory, which article of the regulation requires it, and where in your existing systems that data usually lives. They're the same field maps TracePass uses to generate a passport — published as free PDFs so you can scope the work before committing to any tool. Across the four categories, TracePass maps 412 mandatory Digital Product Passport fields — every one tied to the article that requires it. ## Guides by product category - [All the mandatory fields of the EU Battery Passport, mapped field-by-field.](https://www.tracepass.eu/guides/battery.md): Field-by-field guide to every mandatory data point required by EU Battery Regulation 2023/1542. Free PDF, 7 sections, with regulation references. - [All 60 fields of the EU textile passport, mapped to source data.](https://www.tracepass.eu/guides/textile.md): Field-by-field guide to the 60 mandatory data points for the EU textile DPP under ESPR. Material composition, durability, eco-score, supply-chain due diligence. - [All 167 fields of the EU electronics passport, with regulation references.](https://www.tracepass.eu/guides/electronics.md): Field-by-field guide to all 167 mandatory data points for the EU electronics DPP under ESPR + EPREL. Smartphones, white goods, servers, repairability. - [All 66 fields of the EU packaging DPP, tied to PPWR articles.](https://www.tracepass.eu/guides/packaging.md): Field-by-field guide to the 66 mandatory data points for the EU packaging DPP under PPWR 2025/40. Recyclability classes, recycled content, sorting, SoC. ## Related - [EU DPP regulations, tracked article-by-article](https://www.tracepass.eu/regulatory) ## Frequently asked questions ### Are the guides free to download? Yes. Every guide is a free PDF — no payment required. We ask for an email so we can send the file and let you know when the underlying regulation changes. ### Where does the field data in the guides come from? Each field is taken directly from the EU regulation for that product category (e.g. the EU Battery Regulation 2023/1542 for batteries) and cross-checked against the active TracePass passport template for that category. ### Which product categories are covered? Batteries, textiles, electronics and packaging today, with more added as their delegated acts and field requirements are finalised under the EU's ESPR framework. ### Do I need a Digital Product Passport for my product? If you place a product in one of the regulated categories on the EU market, almost certainly yes — the DPP is being phased in category by category. The battery passport is first, mandatory from February 2027; textiles, electronics and others follow under ESPR through 2027–2030. Each guide states the deadline for its category. ### How many fields does my category's passport need? It varies by category: the EU battery passport carries the mandatory Annex XIII fields, textiles 60, electronics 167, and packaging 66. Each guide lists every field and the regulation article that requires it. Maintained by the TracePass team · Last reviewed 19 June 2026 --- --- title: All the mandatory fields of the EU Battery Passport, mapped field-by-field. description: Field-by-field guide to every mandatory data point required by EU Battery Regulation 2023/1542. Free PDF, 7 sections, with regulation references. canonical: "https://www.tracepass.eu/guides/battery" locale: en source: "https://www.tracepass.eu/guides/battery" --- # All the mandatory fields of the EU Battery Passport, mapped field-by-field. > Field-by-field guide to every mandatory data point required by EU Battery Regulation 2023/1542. Free PDF, 7 sections, with regulation references. Battery makers and importers must publish a Annex XIII digital passport by 18 February 2027 under Regulation (EU) 2023/1542. This guide breaks all mandatory fields across 7 sections with regulation references and source-data guidance for each field. - Regulation: EU Battery Regulation 2023/1542 - Mandatory from: February 2027 - Fields covered: 119 - Guide length: 21 pages ## Who needs to file a battery passport Regulation (EU) 2023/1542 applies from 18 February 2027 to: - EV batteries — every battery used to propel an electric vehicle (full or hybrid). - Industrial batteries above 2 kWh — stationary storage, telecom, UPS, large mobile equipment. - LMT batteries — e-bike, e-scooter, e-moped batteries above 25 V or 250 W. - SLI (starter) batteries — partially in scope from August 2025; full DPP from Feb 2027. --- --- title: All 60 fields of the EU textile passport, mapped to source data. description: Field-by-field guide to the 60 mandatory data points for the EU textile DPP under ESPR. Material composition, durability, eco-score, supply-chain due diligence. canonical: "https://www.tracepass.eu/guides/textile" locale: en source: "https://www.tracepass.eu/guides/textile" --- # All 60 fields of the EU textile passport, mapped to source data. > Field-by-field guide to the 60 mandatory data points for the EU textile DPP under ESPR. Material composition, durability, eco-score, supply-chain due diligence. Field-by-field guide to the textile Digital Product Passport under ESPR. Material composition, durability, French Anti-Waste Eco-Score, supply-chain due diligence — with regulation references and where to find each value. - Regulation: EU ESPR — Textile DPP - Mandatory from: 2028–2029 - Fields covered: 60 - Guide length: 16 pages ## Who needs to file a textile passport Textile DPP enters force progressively from 2028 under the Ecodesign for Sustainable Products Regulation (ESPR): - Apparel manufacturers and brand owners placing textiles on the EU market. - Importers of finished garments and home textiles into the EU. - Footwear, including the upper-construction and outsole-material declarations. - France's Anti-Waste Eco-Score is already in force for clothing — covered in the same template fields so the DPP doubles as the eco-score input. --- --- title: All 167 fields of the EU electronics passport, with regulation references. description: Field-by-field guide to all 167 mandatory data points for the EU electronics DPP under ESPR + EPREL. Smartphones, white goods, servers, repairability. canonical: "https://www.tracepass.eu/guides/electronics" locale: en source: "https://www.tracepass.eu/guides/electronics" --- # All 167 fields of the EU electronics passport, with regulation references. > Field-by-field guide to all 167 mandatory data points for the EU electronics DPP under ESPR + EPREL. Smartphones, white goods, servers, repairability. The most field-heavy DPP category. Per-product-type fields for smartphones, washing machines, refrigerators, servers, plus repairability scores, energy-efficiency labels, hazardous-substance declarations, and EPREL integration. - Regulation: EU ESPR — Electronics DPP - Mandatory from: 2028–2029 - Fields covered: 167 - Guide length: 35 pages ## Who needs to file an electronics passport Electronics DPP enters force from 2028 under ESPR, with EPREL energy-label integration mandatory across the same product set: - Consumer electronics: smartphones, tablets, laptops, displays — placed on the EU market by any economic operator. - White goods: washing machines, refrigerators, dishwashers — with the existing EPREL energy label data flowing into the DPP. - Servers and data-centre equipment — under the broader ESPR scope expansion. - All categories carry hazardous-substance + critical-raw-material disclosures alongside the per-type performance fields. --- --- title: All 66 fields of the EU packaging DPP, tied to PPWR articles. description: Field-by-field guide to the 66 mandatory data points for the EU packaging DPP under PPWR 2025/40. Recyclability classes, recycled content, sorting, SoC. canonical: "https://www.tracepass.eu/guides/packaging" locale: en source: "https://www.tracepass.eu/guides/packaging" --- # All 66 fields of the EU packaging DPP, tied to PPWR articles. > Field-by-field guide to the 66 mandatory data points for the EU packaging DPP under PPWR 2025/40. Recyclability classes, recycled content, sorting, SoC. Packaging recyclability grading applies from August 2026 and the full packaging Digital Product Passport from 2030 under PPWR (Regulation (EU) 2025/40). This guide maps the 66 fields — recyclability classes A/B/C, recycled content minimums, sorting + disposal instructions, and substances of concern. - Regulation: EU PPWR 2025/40 - Mandatory from: August 2026 (recyclability) / 2030 (full DPP) - Fields covered: 66 - Guide length: 17 pages ## Who needs to file a packaging passport PPWR (Packaging and Packaging Waste Regulation) applies progressively from 2026 to: - Packaging fillers and brand-owners who place packaged products on the EU market — primary obligation rests here. - Packaging manufacturers selling empty packaging into the EU — must provide the upstream data. - Importers bringing packaged goods into the EU — same primary-obligation logic as fillers. - Reusable-packaging operators — separate set of fields covering reuse cycles + return-system data. --- --- title: Resources description: Guides and explainers on EU Digital Product Passports, ESPR, and the Battery Regulation. canonical: "https://www.tracepass.eu/resources" locale: en source: "https://www.tracepass.eu/resources" --- # Resources > Guides and explainers on EU Digital Product Passports, ESPR, and the Battery Regulation. Articles on Digital Product Passport compliance from the TracePass team. - [What Is a Digital Product Passport? (And What It Isn't)](https://www.tracepass.eu/resources/what-is-a-digital-product-passport.md): Plain-language definition of the EU Digital Product Passport — what it is, what it isn't, who must file one, and the timeline for the 12 covered categories. - [Collecting DPP Data from Suppliers: The Bottleneck Nobody Talks About](https://www.tracepass.eu/resources/collecting-dpp-data-from-suppliers.md): 60% of a DPP project timeline is supplier data collection, not the regulation. The four process changes that shrink a 16-week effort to 2 weeks. - [EU Battery Regulation 2023/1542: February 2027 Compliance Guide](https://www.tracepass.eu/resources/eu-battery-regulation-february-2027.md): Battery passports become mandatory in February 2027. What the regulation requires, which batteries are in scope, and what manufacturers need to prepare now. - [DPP Software vs Compliance Consulting: What Actually Fills the Fields](https://www.tracepass.eu/resources/dpp-software-vs-consulting.md): A battery DPP is Annex XIII; electronics, 167 fields. Cost and timeline hinge on how they get filled — a consulting project, or an automated pipeline. - [Textile Digital Product Passport: What Brands Must Prepare](https://www.tracepass.eu/resources/textile-digital-product-passport.md): Textiles are an ESPR priority for the EU Digital Product Passport. What a textile DPP will require, the honest timeline, and how to prepare now. - [When Does My Product Need a DPP? ESPR Timeline by Group](https://www.tracepass.eu/resources/when-does-my-product-need-a-dpp.md): Batteries need a DPP by 18 Feb 2027. Other ESPR groups await delegated acts. Find your group, your date, and the honest caveats. - [Second-Life Batteries: Do They Need a New DPP?](https://www.tracepass.eu/resources/second-life-battery-passport.md): Repurposing an EV battery for storage is a new placing on the market — it generally needs a new battery passport linked to the original. - [A Bulgarian jeweller puts Digital Product Passports on its pieces](https://www.tracepass.eu/resources/vantony-jewellery-dpp-pilot.md): How Vantony, a Bulgarian fine-jewellery brand, became a TracePass design partner — putting provenance and materials data on every piece, before any mandate. - [Why a Tier-1 Supplier Declaration Isn't Enough for a DPP](https://www.tracepass.eu/resources/why-supplier-declarations-fail-dpp.md): A tier-1 supplier declaration tells you what your direct supplier asserts — not what's verifiable or upstream. Why DPP data needs evidence and chain depth. - [Where Do You Fill In a Digital Product Passport?](https://www.tracepass.eu/resources/dove-si-compila-il-dpp.md): No EU portal accepts DPP data. You build a DPP on a compliant platform: pick a template, fill the fields, and publish — generating a GS1 Digital Link QR code. - [Do Lamps Need a Digital Product Passport?](https://www.tracepass.eu/resources/brauchen-lampen-einen-dpp.md): Lamps have no binding DPP deadline. ESPR sets no requirements directly — obligations need a delegated act, none adopted for lamps or electronics yet. - [Battery Regulation: Three Distinct Documentation Obligations](https://www.tracepass.eu/resources/battery-regulation-accompanying-documentation.md): Art. 13 labelling, Annex VIII technical docs, and the Art. 77 passport are three distinct obligations under EU Reg 2023/1542, with staggered dates. --- --- title: "What Is a Digital Product Passport? (And What It Isn't)" description: "Plain-language definition of the EU Digital Product Passport — what it is, what it isn't, who must file one, and the timeline for the 12 covered categories." canonical: "https://www.tracepass.eu/resources/what-is-a-digital-product-passport" locale: en source: "https://www.tracepass.eu/resources/what-is-a-digital-product-passport" --- # What Is a Digital Product Passport? (And What It Isn't) > Plain-language definition of the EU Digital Product Passport — what it is, what it isn't, who must file one, and the timeline for the 12 covered categories. If you sell anything physical into the EU, the phrase 'Digital Product Passport' is going to land in your inbox sometime in the next two years. Mostly the explanations you'll get are either too vague (it's basically a QR code) or too jargon-loaded (a structured data instance under Article 9 of Regulation (EU) 2024/1781). This post is the one I wish someone had handed me on day one — what a DPP actually is, what it isn't, and how to know whether you have to care about it. ## The plain-language definition A Digital Product Passport (DPP) is a structured set of data about a specific physical product, accessible to anyone who scans a QR code (or taps an NFC tag) on the product itself. It includes things like what the product is made of, where the materials came from, how energy-efficient it is, how to repair or recycle it, and who's responsible for it on the EU market. The legal grounding sits in the Ecodesign for Sustainable Products Regulation (ESPR — Regulation (EU) 2024/1781), which entered force in July 2024 and rolls out per product category on a staggered timeline. ESPR is the umbrella; underneath it sit category-specific regulations like the EU Battery Regulation (2023/1542), the Construction Products Regulation (2024/3110), the Packaging and Packaging Waste Regulation (2025/40), and others. Each of these adds its own field set, deadline, and enforcement mechanism — but the data model is shared across all of them, accessed through the same QR code. ## Why does the EU mandate one Three reasons stack on top of each other. First, sustainability: the European Green Deal needs concrete enforcement mechanics, and the DPP is the data layer that makes claims like 'recycled content of 30%' verifiable instead of marketing. Second, circular economy: products that include disassembly instructions, parts availability windows, and material composition can actually be repaired and recycled instead of landfilled. Third, market surveillance: customs officers, market-surveillance authorities, and recyclers all need the same machine-readable data, and asking each of them to maintain a separate database collapses under its own weight. The DPP is the EU's bet on a single shared layer for all three. ## Which products need a DPP, and when ESPR's first delegated acts cover specific categories. Below is the rollout that's been announced or formally scheduled, in the order it lands. Categories not listed here are still in the pipeline — the long-term scope reaches roughly 30 product groups by the end of the decade. - Batteries (EV, industrial >2 kWh, LMT) — Feb 2027 under EU Reg 2023/1542. SLI starter batteries from Aug 2025 (partial). - Iron & steel — 2027–2028 under ESPR + CBAM. - Textiles & footwear — 2028–2029 under ESPR. - Electronics (smartphones, tablets, displays, white goods, servers) — 2028–2029 under ESPR + EPREL. - Construction products — phased from 2026 under EU Reg 2024/3110 (CPR). - Packaging — Aug 2026 (recyclability A/B/C classes) and 2030 (full DPP) under PPWR 2025/40. - Tyres — under EU Reg 2020/740 + ESPR. - Furniture & mattresses — under ESPR + EUDR (timber traceability). - Detergents — 23 September 2029 under the Detergents Regulation (EU) 2026/405. - Paints & coatings — no passport mandated; VOC limits under Directive 2004/42/EC, plus REACH + CLP. - Toys — under the revised Toy Safety Regulation + ESPR. - FMCG — under ESPR + FIC for food labelling. - Jewellery — under ESPR + RJC + Kimberley Process. ## What information actually goes IN a DPP Field counts vary per category — a battery passport carries the mandatory fields, electronics goes up to 167 (because per-product-type extras for smartphones / washing machines / refrigerators / servers stack in the same template), textiles is 60, packaging is 66. But the structure is the same across categories, organised into a few consistent groups: - Identity: GTIN, model number, manufacturer name, batch / serial number — anchors the passport to a specific physical unit. - Materials & composition: substances, recycled content percentages, critical raw materials, hazardous substance disclosures (REACH SVHC, RoHS, POPs). - Performance: energy efficiency, durability test results, expected lifetime, repairability score (where applicable). - Carbon footprint: a PEF (Product Environmental Footprint) declaration covering each lifecycle stage from raw materials to end-of-life. - Supply chain due diligence: country-of-origin disclosures for risk-flagged inputs (cobalt, lithium, conflict minerals, deforestation-risk timber). - End-of-life: removability, dismantling, recyclability classes, sorting / disposal instructions. - Compliance metadata: CE marking reference, conformity-assessment-body details, declaration-of-conformity number. ## What a DPP is NOT Half the confusion in the market comes from people defaulting to a thing they already know — a barcode, an ESG report, a marketing landing page — and squinting until the DPP fits. It usually doesn't. To save you a meeting: - It is NOT a barcode. A barcode encodes a product identifier. A DPP is a structured dataset that the GS1 Digital Link QR code resolves to. The QR is the door; the DPP is the room behind it. - It is NOT a marketing datasheet. The fields are mandated by regulation, formats are prescribed (often per Annex of a specific regulation), and authorities — not your marketing team — define what's accurate. - It is NOT an ESG report. An ESG report is annual, company-level, qualitative-leaning. A DPP is per-product, machine-readable, and updated whenever the underlying product or its supply chain changes. - It is NOT a QR code that links to your product page. Linking the QR to a marketing landing page would render the whole regulation unenforceable. The DPP is hosted at a regulated endpoint with tiered access — public, restricted (partners), and authority (regulators / recyclers). - It is NOT a replacement for your ERP, PIM, or PLM. Those stay your source of truth internally; the DPP is the public-facing structured projection of a slice of that data, kept in sync. - It is NOT the same as France's Triman, the EU Energy Label, or the REACH SVHC list. Those are individual labelling / disclosure schemes, some of which feed INTO the DPP — but the DPP is a wider data instance that subsumes them. - It is NOT optional after the deadline for your category. There's no transition period beyond what the implementing acts spell out — products without a passport cannot legally be placed on the EU market. > **Want a concrete example? Here's the Annex XIII battery passport** > > Free 26-page PDF: every field of the battery passport with its regulation reference and where to find the value in your supplier docs. The category with the soonest deadline (Feb 2027) and the most concrete data model — useful even if your product is in a different category, since the patterns repeat. > > [Download the battery guide](https://www.tracepass.eu/guides/battery) ## Who is responsible for filing it The economic operator placing the product on the EU market — manufacturer, importer, or authorised representative. Not the cell supplier in Korea, not the contract assembler in Vietnam, not the EU distributor reselling already-passported units. The first party that brings the finished product across the EU border is the legal owner of the passport, accountable for accuracy, completeness, and ongoing maintenance for the product's full lifetime. If you import EV batteries from a non-EU manufacturer, you (the importer) are the economic operator, even though you didn't make the cells. ## How is a DPP technically delivered A QR code on the product (sometimes also an NFC tag) encodes a GS1 Digital Link URI — a structured URL that contains the product's GTIN and serial number. Scanning the code resolves to a regulated host, which serves the structured passport data via three access tiers: public (consumer view), restricted (business partners with tokens), and authority (regulators, recyclers, market surveillance — full access including supply-chain due-diligence evidence). The same passport, three audiences, three different views. The hosting endpoint can be the manufacturer's own infrastructure or a SaaS platform; either way it must remain accessible for the product's full lifetime. ## How to know if you're affected — quick check Three yes/no questions. If you answer yes to all three, you have a DPP project on your hands and the deadline is closer than it feels. - Do you place a physical product on the EU market — meaning you (or your importer) bring it across the border to be sold to an EU customer? Yes / no. - Does that product fall in one of the 13 categories above (or a related one in the ESPR pipeline)? Yes / no. - Is the deadline for your category in the next 24 months? Yes / no. ## First steps if it does affect you - Pick the relevant category guide and read the field list end-to-end. The free PDFs above (battery, textile, electronics, packaging) cover the four highest-priority categories. Other categories follow the same shape. - Map every field to a likely source: internal (your QC + product data), supplier-provided (datasheets, SDS, test reports, EPDs), or external (PEF assessor, certification body, public registry). - Flag every field where 'we don't have this data' is the honest answer. Those are your project blockers — they need either a supplier ask or a third-party study, and both take 4–12 weeks. - Decide who owns the passport internally — usually a compliance / regulatory affairs lead, working with R&D and supply-chain. The decision is who's accountable when an authority asks; not who fills in the cells. - Pick a hosting strategy: build vs SaaS. The data layer is regulated; the UI presenting it is your call. Most teams pick SaaS for the first DPP rollout because building a multi-tenant passport host with three access tiers is 6+ months of engineering they don't need to repeat. > **Bookmark this — there's no central EU "What is a DPP" page (yet)** > > The European Commission's Digital Product Passport portal at europa.eu is still under construction (planned 2026). For now, the canonical references are scattered across EUR-Lex regulation texts and individual JRC working documents. This post is the closest thing to a single-page primer we've found — feel free to share it with the rest of your team, no attribution needed. ## FAQ ### What's the difference between a Digital Product Passport and a barcode? A barcode encodes a product identifier — a GTIN, EAN, or similar. It points at a product but contains no information about it. A DPP is the structured dataset that the QR-code-encoded GS1 Digital Link URI resolves to. The QR is the door; the DPP is the room behind it. The DPP carries dozens to hundreds of mandatory fields covering identity, materials, performance, supply chain, and end-of-life — all per EU regulation. ### Is the DPP the same as ESPR / Battery Regulation / PPWR? No — those regulations create the obligation, the DPP is the data instance the obligation produces. ESPR (Regulation (EU) 2024/1781) is the umbrella; underneath it sit category-specific regulations like the EU Battery Regulation 2023/1542, the Construction Products Regulation 2024/3110, and the PPWR 2025/40. Each adds its own field set + deadline + enforcement; the DPP is the shared output format across all of them. ### Which products need a DPP first? Batteries are the headline first deadline — 18 February 2027 for EV, industrial >2 kWh, and LMT (light means of transport) batteries under EU Reg 2023/1542. Iron & steel and textiles follow in 2027–2029. Detergents have their own statutory date — 23 September 2029 under Regulation (EU) 2026/405. Construction products, electronics, packaging, tyres, furniture, paints & coatings, toys, FMCG, and jewellery all roll out progressively from 2026 through ~2031 under ESPR + their category-specific regulations. ### Who fills in the DPP — the manufacturer, the importer, or the supplier? The economic operator placing the product on the EU market — typically the manufacturer (if EU-based) or the importer (if non-EU manufacturer). Suppliers and component vendors are not directly in scope; they are upstream sources for data the operator must publish. About 40–70 % of mandatory DPP fields originate upstream of the economic operator, so supplier engagement is the critical path even though the operator owns the legal obligation. ### Is the data inside a DPP public? Partially. The DPP has three access tiers: public (consumer view, accessible to anyone scanning the QR), restricted (business partners with access tokens), and authority (regulators, recyclers, market surveillance — full access including supply-chain due-diligence evidence). Confidential business information goes in the restricted or authority tiers; consumer-relevant fields (composition, repairability, end-of-life) are public. ### Does my product need a DPP if I only sell within Bulgaria / Germany / France? Yes — DPP scope is the EU market, not specific member states. If you place a covered product on any EU-member-state market (including your home market), the obligation applies. The same passport works across all 27 member states; there's no per-country variant. ### Is there a transition period if I miss the deadline? No formal transition period beyond what implementing acts spell out. From the cut-off date for your category, products without a passport cannot legally be placed on the EU market — meaning customs can refuse them, market surveillance can pull them from shelves, and the importer / manufacturer faces administrative and (in serious cases) criminal liability. Stockpiles of pre-deadline product can usually be sold through, but new placements must comply. --- --- title: "Collecting DPP Data from Suppliers: The Bottleneck Nobody Talks About" description: 60% of a DPP project timeline is supplier data collection, not the regulation. The four process changes that shrink a 16-week effort to 2 weeks. canonical: "https://www.tracepass.eu/resources/collecting-dpp-data-from-suppliers" locale: en source: "https://www.tracepass.eu/resources/collecting-dpp-data-from-suppliers" --- # Collecting DPP Data from Suppliers: The Bottleneck Nobody Talks About > 60% of a DPP project timeline is supplier data collection, not the regulation. The four process changes that shrink a 16-week effort to 2 weeks. When a compliance team plans a Digital Product Passport rollout, the timeline usually allocates 2 weeks for 'reading the regulation' and 2 weeks for 'setting up the passport'. The remaining three to four months, nobody plans for — but that's where the actual project lives. It's supplier data collection: chasing cell manufacturers, dye-house operators, resin formulators, and tier-2 packaging converters for test reports, material declarations, and carbon footprints. Here's the shape of that work, the four things that make it harder than it looks, and the process changes that shrink a 16-week effort into roughly two. ## How much of a DPP actually comes from suppliers For a battery passport, of all mandatory fields, roughly 47 originate outside your company: cell supplier provides the chemistry, hazardous-substance declarations, and internal-resistance curves; the cathode/anode raw-material suppliers provide origin + due-diligence evidence for cobalt, lithium, nickel, and natural graphite; the electrolyte supplier provides the SDS. For a textile DPP it's similar proportions but across more tiers — dye house, fabric mill, yarn spinner, fibre grower — each with two or three fields that only they can supply. The rule of thumb: 40–70% of a DPP's data exists upstream of the economic operator. If your DPP project plan doesn't have a three-month supplier-outreach block, the plan is wrong. ## Why it's harder than a spreadsheet-and-email workflow The naïve approach — send every supplier a 30-page Excel template — looks reasonable on day one and collapses by week three. Four reasons it doesn't work at scale: - Tier-2 and tier-3 suppliers don't know their customer's customer is covered by EU DPP. They see an unfamiliar form, deprioritise it, and your compliance team ends up cold-emailing in a language the supplier doesn't work in. - The data exists — in QC records, test-report PDFs, supplier-system exports — but not in the shape your form asks for. A supplier with everything you need can still reply 'we don't have this' because translating their internal taxonomy to your form is a day of work. - Evidence is a PDF, not a value. EU DPP mandates evidence links (test reports, EPDs, SDS files, conformity certificates). A form field that says 'enter recycled content %' without asking for the PDF that proves it is incomplete — and a field that asks for both is twice the friction. - Response rate for cold 'please fill in this form' emails is typically 15–25%. Chasing the remaining 75% takes longer than the original outreach. ## What the 16-week email workflow actually looks like Week 1–2: identify suppliers, draft the request, translate to three languages, attach the template. Week 3: send. Week 4: chase the non-responders. Week 5–6: triage the first 8 replies — half are incomplete, one is the wrong format entirely (PDF of handwritten notes). Week 7–10: chase again, reconcile inconsistent units (kWh vs Wh, kg vs g, % vs ratio), ask clarifying questions. Week 11–14: second wave of chasing for supporting evidence files (the form had a value but no PDF). Week 15: QA sweep — catch the supplier who used 2022 SVHC list instead of the current one. Week 16: feed cleaned data into the passport. You've now used the entire calendar budget on what was scheduled as a two-week task. > **Doing this for batteries? Get the field map** > > Free 26-page PDF: every one of the mandatory battery-passport fields with its source-data origin (datasheet, SDS, PEF study, supplier declaration) and regulation reference. Useful for adapting the same approach to other DPP categories. > > [Download the guide](https://www.tracepass.eu/guides/battery) ## What collapses the loop Four process changes do most of the work: - Token-based access, no signup. The supplier clicks a unique link in their email and lands on a pre-filled form for their specific material. No account to create, no password to forget, no IT-team approval to wait for. Response rate jumps from ~20% to 60–70%. - Supplier's language by default. Detect the supplier's country from the contact metadata, render the form in their language, auto-translate the fields. A Chinese cell-factory QC manager is 5× more likely to fill a form in Chinese than in English. - PDF-in, values-out. Let the supplier upload the document they already have (datasheet, test report, SDS), and extract the values automatically instead of asking them to re-type. 'Upload this SDS' is a 10-second ask; 'transcribe the 14 fields on page 3 of this SDS into my spreadsheet' is a 20-minute one. - Live dashboard for your compliance team showing every supplier's response state. Stops the weekly email ritual of 'who have we not heard from'. Makes it obvious where to spend the chase-budget. ## What suppliers actually respond to Most cold supplier requests fail because the framing is wrong, not because the supplier is unwilling. Imagine you run quality control at a lithium-cell factory in Korea: you receive 30 emails per day from buyer companies, half of them asking for data in formats that conflict with each other. An unfamiliar 30-page Excel template from a brand you've barely heard of lands somewhere between the bottom of the pile and the trash. The patterns that actually move response rates from 20% to 60–70%: - Lead with the regulation, not the form. "EU Battery Regulation 2023/1542 requires us to publish your X by Feb 2027" lands harder than "please fill in this template". The supplier's compliance team can act on the first; their sales-support intern reading the second has to escalate. - Scope the request to THEIR product, not your full schema. If the supplier provides 4 of the mandatory fields, ask for those 4 with prefilled product names. Asking for the whole set invites "this isn't ours" replies. - Make the deadline real and shared. "We need this by 30 March because our type-approval submission lands 18 April" travels up the chain better than "as soon as possible". - Offer a small reciprocal value: a copy of the published passport, an extract of the carbon-footprint methodology you used, or a downloadable certificate that proves due diligence on their end. Nothing transformative; just enough that the request feels like a 2-way relationship. ## When the supplier is asking YOU Half the SaaS literature treats DPP supplier-data collection as a one-way street: brand asks, supplier provides. In practice every economic operator is downstream of someone and upstream of someone else. The same textile mill that's collecting cotton-origin data from its yarn supplier is being asked for fabric-composition data by its apparel-brand customer. The same battery-pack manufacturer chasing cell-chemistry data from Korea is being asked for pack-level performance data by the EV OEM placing the vehicle on the EU market. Two practical implications: first, the data you're collecting from your suppliers can usually be republished cleanly to your downstream customer with minimal additional effort — same fields, same format. Second, your downstream customer's compliance team is going through exactly what you are. If you can serve your data via a token-based portal in their language, you skip 12 weeks of email threads and they'll thank you for it. The platforms that win the long game are the ones that make this two-sided. ## Common process mistakes Mistakes I've watched repeat across roughly twenty DPP rollouts in different categories: - Treating the first DPP rollout as a project rather than an operational capability. The first 5 SKUs are a project; the next 500 — and the ones rolling onto the market every month after — need a process owner, not a Gantt chart. - Letting marketing draft the supplier-facing emails. Marketing optimises for engagement; supplier compliance reads engagement as fluff and discards it. Compliance- or quality-team voice converts at roughly 3× the rate. - No dedicated email address. Sending from a personal name@yourcompany.com gets filtered as spam by tier-2/tier-3 supplier MTAs. Use a dedicated dpp@ or compliance@ alias with a configured SPF + DKIM record. Half the "supplier didn't reply" cases are actually "supplier never received it". - Asking for data the regulation doesn't require. Compliance teams add nice-to-haves to the request because the supplier portal lets them. Each unnecessary field drops response rate by 5–10%. - Not separating draft data from approved data. A passport with values from 12 different reviewers, none of them flagged as approved-by-X, is not auditable. The simplest fix: a status flag per field — `pending_review`, `approved`, `flagged` — with the reviewer ID stamped on every transition. Authorities will eventually ask. > **How TracePass ships this** > > TracePass includes a built-in supplier portal that implements the four changes above: token-per-supplier invite links, localised forms in 24 EU languages, AI extraction from uploaded PDFs (datasheets, test reports, SDS, EPDs), and a live dashboard of every outstanding supplier request. Growth plan and above include the portal; the electronics, battery, and textile category pages list the data fields the portal is already wired for. ## FAQ ### How much DPP data comes from suppliers vs internal sources? 40–70% of mandatory Digital Product Passport data exists upstream of the economic operator. For a battery passport specifically, roughly 47 of the mandatory fields require data from cell suppliers, raw-material suppliers (cobalt, lithium, nickel, natural graphite), and electrolyte suppliers. Textile DPPs follow similar proportions across more tiers (dye house, fabric mill, yarn spinner, fibre grower). ### How long does supplier data collection take for a DPP? Typical first DPP via an email-and-spreadsheet workflow: 12–16 weeks. With token-based supplier portals, per-language forms, and PDF-in-values-out evidence handling, that compresses to roughly 2 weeks for repeat collections. The first round always takes longer than subsequent rounds because supplier relationships and field-mapping are being established. ### What response rate should I expect for cold supplier DPP requests? 15–25% for cold 'fill in this form' emails, particularly for tier-2 and tier-3 suppliers unfamiliar with EU DPP scope. Response rates rise to 60–80% when suppliers receive a per-language secure portal, partial-submit support, and EU regulation context in the request. ### Can AI extract DPP data from supplier datasheets automatically? Yes — AI can extract structured field values from supplier PDFs (datasheets, SDS files, IEC test reports, EPDs) once the supplier has provided the document. AI cannot generate data the supplier hasn't published, so the supplier-engagement step still happens; AI accelerates the post-receipt parsing rather than the request itself. --- --- title: "EU Battery Regulation 2023/1542: February 2027 Compliance Guide" description: Battery passports become mandatory in February 2027. What the regulation requires, which batteries are in scope, and what manufacturers need to prepare now. canonical: "https://www.tracepass.eu/resources/eu-battery-regulation-february-2027" locale: en source: "https://www.tracepass.eu/resources/eu-battery-regulation-february-2027" --- # EU Battery Regulation 2023/1542: February 2027 Compliance Guide > Battery passports become mandatory in February 2027. What the regulation requires, which batteries are in scope, and what manufacturers need to prepare now. Every EV, industrial (>2 kWh), and LMT battery placed on the EU market from 18 February 2027 must ship with a machine-readable Digital Product Passport carrying the mandatory data fields (Annex XIII, Regulation (EU) 2023/1542); without it the product cannot be placed on the market. This guide covers which batteries are in scope, what all mandatory fields require in practice, and what manufacturers should start doing now. ## Which batteries are in scope Regulation (EU) 2023/1542 covers three categories where the passport is mandatory from February 2027: electric vehicle batteries, industrial batteries above 2 kWh capacity, and light means of transport batteries (e-bikes, e-scooters, e-mopeds). Portable batteries (consumer electronics) and SLI (starter, lighting, ignition) batteries remain outside the passport requirement for now, though other parts of the regulation — labelling, collection targets, recycled-content minimums — still apply. ## What's in the mandatory fields The passport is not a marketing datasheet. It's a structured dataset accessible via QR code on the physical product, with tiered access: public (anyone scanning), restricted (business partners with tokens), and authority (regulators, recyclers, market surveillance). The mandatory fields map to the TracePass battery template as follows: TracePass battery template — Annex XIII field groups | Field group | Count | Primary source document(s) | | --- | --- | --- | | General info | 15 | Manufacturer records, economic-operator ID, notified-body cert | | Composition & materials | 7 | BoM, SVHC/REACH declarations, cell-supplier datasheets | | Carbon footprint | 7 | PEF study (external assessor) | | Performance & durability | 41 | IEC 61960 / 62619 test reports, BMS data | | Labels & markings | 9 | CE / conformity docs, label artwork | | Supply-chain due diligence | 3 | Cobalt/graphite/lithium/nickel provenance + risk assessment | | Repair, repurposing, recycling | 12 | Service docs, dismantling instructions, state-of-health | > **Want every field, mapped to source data?** > > Free 26-page PDF — every battery passport field with its regulation reference (Article + Annex) and where to find the value in your supplier datasheets, IEC test reports, SVHC declarations, and PEF studies. Generated from the live TracePass battery template. > > [Download the guide](https://www.tracepass.eu/guides/battery) ## Where does the data actually come from? Roughly half the battery passport — about 47 of all mandatory fields — originates outside your own company: supplier declarations, cell-maker datasheets, external PEF assessors, and certified recyclers. In TracePass onboarding we consistently see 60–70% of the required data already exists somewhere in the organisation; the citable gap is the supplier-sourced half. ## Who is responsible The economic operator — whoever places the battery on the EU market, which usually means the manufacturer or the importer. A distributor reselling batteries already carrying a passport does not create a new one; their obligation is to check that a passport exists before placing on the market. Where a component battery cell supplier provides the cells but the pack is assembled elsewhere, the pack manufacturer is the economic operator for the finished battery's passport. ## Field walkthrough — what each section actually contains The mandatory fields are clinically named in the regulation but ordinary in content. A few examples — the kind of thing your compliance team will trace through datasheets, IEC test reports, supplier declarations, and the PEF study — to anchor what "a battery passport field" actually means in practice: - **batteryUniqueIdentifier** — a GS1 Digital Link URI that uniquely points at the specific battery unit (e.g. https://id.gs1.eu/01//21/). Source: your GS1 registration + serial-number generation. The single field that turns a passport from "per-model" to "per-individual". - **carbonFootprintRawMaterialAcquisition** — kg CO₂e per kWh from the raw-materials phase of the lifecycle, calculated via PEF methodology. Source: the PEF study (€8K–€25K via an external assessor, 2–6 weeks). One field; six weeks of work upstream. - **recycledContentCobalt** — percentage of cobalt in the cell that came from recycled sources, with chain-of-custody evidence required. Source: cell-supplier declaration backed by mass-balance accounting from a certified recycler. The first time you ask for this, expect a 4-week scramble. - **expectedLifetimeYears** / **expectedLifetimeFullCycles** — manufacturer-stated lifespan with the test conditions that justify it. Source: your IEC 61960 / IEC 62619 test report. The field most often blocked because the test program ran on an earlier revision. - **dismantlingInformation** — a URL pointing to a public PDF / video / instruction set explaining how the battery is removed from the host device for replacement or recycling. Source: your service-documentation team. Most teams realise they have repair instructions but not dismantling instructions; those are different documents. ## Compliance-team mistakes and how to avoid them Patterns I've watched repeat across battery-passport rollouts. None of these are deal-breakers; all of them cost weeks if you hit them late instead of planning around them: - Starting the PEF study after design freeze. PEF takes 2–6 weeks via an external assessor and needs the bill-of-materials at the cell level. Teams that kick it off in the same week as type-approval submission lose 4–6 weeks they didn't budget. Start the PEF when you start the IEC test campaign. - Mixing units in the supplier-data layer. Cell suppliers report capacity in Ah, energy in Wh, and resistance in mΩ. Pack-level data needs kWh, kg, and Ω. The unit conversion isn't hard but the version drift between supplier exports and your DPP template silently breaks the field. Pin units in the supplier portal and reject inconsistent inputs at intake, not at QA sweep. - Using a stale SVHC list. The REACH SVHC candidate list updates twice a year (typically Jan and Jul). A passport published in February that lists "compliant per the 2024 SVHC list" is technically out of date by the time it's printed on the QR-code label. Auto-pull the current list at publish time, not at template-design time. - Treating the passport as one-and-done. Once published, the passport must remain accurate for the battery's full lifetime. If you change cell chemistry mid-production, the passport for that production batch onward needs to update — and the older passports need to remain available for the units already in market. Most teams forget about the second part. - Forgetting the GS1 setup until late. Without a registered GS1 GTIN + a Digital Link resolver, you literally cannot generate a valid passport URL. GS1 membership for a small EU manufacturer is €500–€1500/year (varies per country) and the registration process takes 1–4 weeks. Start that before the data-collection sprint, not after. ## Cost ranges — what you'll actually spend Indicative costs for a single battery model going through first-time DPP compliance. Numbers shift with model complexity, supplier responsiveness, and whether you're EU- or non-EU-based, but the order of magnitude is stable: Indicative costs — first battery model through DPP compliance | Cost / effort item | Typical range | Basis (TracePass observation) | | --- | --- | --- | | **PEF study** (Product Environmental Footprint) | €8K–€25K; 2–6 weeks | External assessor required; reusable across model variants with same cell chemistry and supply chain | | **Conformity assessment + notified-body fees** | €5K–€15K | Often already in the CE-marking budget; DPP adds little incremental cost here | | **Internal compliance team time** | 240–400 person-hours (first DPP); 40–80 h per subsequent variant | Once supplier relationships and field-mapping are established, repeat-model effort drops sharply | | **Software / passport-hosting platform** | €0–€2K/month | Free/Basic tiers (≤25 DPPs/month, ≤€49/mo); AI-assisted extraction typically €350–€500/month for mid-volume manufacturers | | **GS1 membership + Digital Link resolver** | €500–€1,500/year | Per-country; scales with company turnover; custom-domain resolver adds €2K–€5K one-time if needed | | **Translation + multilingual hosting** | €0.10–€0.30 per word per locale (DIY) | Most platforms include 24-language hosting; DIY compliance-grade translation runs €0.10–€0.30/word | ## Where to start today If you place batteries on the EU market and February 2027 is inside your product-development horizon, start by inventorying all mandatory fields against what your organisation already has. Most manufacturers find 60–70% of the data exists — scattered across datasheets, supplier certificates, EPD reports, and internal QA documents. The gap is usually recycled-content percentages, per-kWh carbon footprint (requires a PEF calculation), and supply-chain due-diligence evidence. That gap is where you'll spend the next 18 months, and it's why a platform like TracePass exists: to collapse the last-mile data-wrangling step so your compliance team isn't still emailing suppliers in January 2027. [View a live battery Digital Product Passport example](https://app.tracepass.eu/p/01/99999999999997/21/6B27A0000001) > **Not legal advice** > > This guide summarises the key requirements of Regulation (EU) 2023/1542 for orientation purposes. Implementing acts, delegated acts, and national transpositions may add detail. For binding interpretation consult EUR-Lex and your national competent authority. ## FAQ ### When does the EU Battery Regulation passport requirement apply? Battery passports become mandatory on 18 February 2027 for every EV battery, industrial battery above 2 kWh, and light means of transport (LMT) battery placed on the EU market under Regulation (EU) 2023/1542. Products without a passport cannot be placed on the EU market after that date. ### Which batteries need a Digital Product Passport? Three categories: electric vehicle batteries, industrial batteries above 2 kWh capacity, and LMT batteries (e-bikes, e-scooters, e-mopeds). Portable consumer batteries and SLI starter batteries remain outside the passport requirement, though other parts of Regulation 2023/1542 still apply (labelling, collection targets, recycled-content minimums). ### How many fields are required in the battery passport? The mandatory data fields per Annex XIII of Regulation (EU) 2023/1542, organised into general info (15), materials & composition (8), carbon footprint (7), performance & durability (54), labels & markings (11), supply chain due diligence (3), and end-of-life (21). ### Who is responsible for the battery passport? The economic operator placing the battery on the EU market — manufacturer, importer, or authorised representative — is responsible for the accuracy, completeness, and ongoing maintenance of the passport for the battery's full lifetime. Cell suppliers and component vendors are not directly in scope; they are upstream sources for data the operator must publish. ### What's the typical cost of producing a battery passport? Major variable costs are the PEF (Product Environmental Footprint) study (€8K–€25K via an external assessor, 2–6 weeks), the conformity assessment if required for the specific battery type, and the data-collection effort across suppliers (3–4 months of compliance-team time on the first DPP, falling sharply for repeat models). Platform/software costs are usually a small fraction of the total — TracePass plans start at €49/month for manual entry, €350/month for AI-assisted extraction. --- --- title: "DPP Software vs Compliance Consulting: What Actually Fills the Fields" description: A battery DPP is Annex XIII; electronics, 167 fields. Cost and timeline hinge on how they get filled — a consulting project, or an automated pipeline. canonical: "https://www.tracepass.eu/resources/dpp-software-vs-consulting" locale: en source: "https://www.tracepass.eu/resources/dpp-software-vs-consulting" --- # DPP Software vs Compliance Consulting: What Actually Fills the Fields > A battery DPP is Annex XIII; electronics, 167 fields. Cost and timeline hinge on how they get filled — a consulting project, or an automated pipeline. Every Digital Product Passport is, underneath, a structured dataset: the mandatory Annex XIII fields for an EU battery passport, 167 for an electronics DPP under ESPR + EPREL. The regulation tells you which fields. It does not tell you how to fill them — and that is the entire decision. The market splits into two answers: hire a compliance consultancy to assemble the data as a project, or run an automated pipeline that reads the documents you already have. They differ not in marketing but in mechanics, cost shape, and who owns the passport after launch. ## The two models, in one sentence each Consulting-heavy: a firm runs a discovery project — workshops, spreadsheets, supplier emails — and hands back a completed passport (and an invoice) at the end. Agent-first: a platform ingests your existing documents (datasheets, EPREL entries, test reports, SVHC declarations), maps each value to its regulated field automatically, and requests only what's genuinely missing from suppliers. The first sells you labour; the second sells you a repeatable process you keep. ## Where the fields actually come from This is the part both models have to solve, and it's worth being concrete. Take the EU battery passport's mandatory Annex XIII fields. Most are not new information you must invent — they are values that already exist in documents you hold or can request: - Cell chemistry, capacity, voltage, internal resistance → the cell supplier's datasheet - Carbon footprint per kWh → your PEF study (Product Environmental Footprint) - Critical raw materials (lithium, cobalt, nickel, natural graphite) → supply-chain due-diligence records - CE marking, conformity assessment body → your Declaration of Conformity and test reports - Recycled content, collection and recycling info → your own production and end-of-life data A consulting project gathers these by hand: someone reads each PDF, types the value into a spreadsheet, chases the supplier for the gaps, and repeats it per product. An automated pipeline reads the same PDFs, extracts the values, and writes them straight into the mapped fields — leaving only the genuinely-missing ones to request. The data source is identical. What differs is whether a person retypes it once per product, or a process does it every time. ## Why the field count matters more at 167 than at 95 An electronics DPP under ESPR carries roughly 167 fields, drawing on your EPREL registration, CE test reports, RoHS and WEEE data, and spec sheets. Whichever model you pick, the cost of the manual approach scales with field count × product count. A consultancy charging by the project quotes a battery passport lower than an electronics one (167 fields) for the same reason a removals firm charges by the box: more units of manual work. The automated approach inverts that — once the 167-field template is mapped to your document types, the marginal cost of the next product is close to zero. The field count stops being a cost driver and becomes a one-time setup. ## Who owns the passport after launch A passport is not done at launch. The delegated acts under both the Battery Regulation and ESPR keep evolving; fields get added, methodologies change, and a passport must stay accurate for the life of the product. With a consulting project, the deliverable is a snapshot — when the rules shift, you commission another engagement. With a platform, template updates land in place and your existing passports flag the new empty fields for you to fill on your own schedule. The question to ask any provider is not 'can you produce a compliant passport?' but 'who maintains it in 2028, and what does that cost?' ## When consulting is still the right call This isn't an argument that consulting has no place. If you have a handful of complex products, no internal documents in order, and need the underlying PEF study or conformity assessment done from scratch, a consultancy does work software cannot: it produces the source data, not just the passport around it. The honest split is — consulting to create data that doesn't exist yet (a PEF study, a due-diligence audit); a platform to assemble, publish, and maintain data that does. Most manufacturers facing 2027 already hold most of their data; their bottleneck is assembly and upkeep, which is the part automation removes. > **The one-line test** > > Ask whether the work is creating data that doesn't exist (consulting's job) or assembling and maintaining data you already have (a platform's job). For most manufacturers approaching the 2027 deadline, it's overwhelmingly the latter. ## FAQ ### Is a DPP platform cheaper than a compliance consultant? For assembling and maintaining passports from data you already hold, yes — usually by a wide margin, because platform cost is a flat subscription while consulting scales with field count and product count. TracePass plans start at €49/month for manual entry and €350/month for AI-assisted extraction. Consulting is better value only when you need source data created from scratch (a PEF study, a conformity assessment), which a platform doesn't produce. ### How many fields are in a Digital Product Passport? It depends on the product category. An EU battery passport under Regulation 2023/1542 carries the mandatory Annex XIII fields. An electronics DPP under ESPR + EPREL has roughly 167. Textiles, construction products, and other categories have their own field sets, defined by each product's delegated act. ### Can software really fill the fields automatically? For the fields whose values already exist in documents you hold — datasheets, EPREL registrations, test reports, SVHC declarations — yes: the platform extracts the value and writes it to the mapped field. Fields whose values genuinely don't exist yet (or live only with a supplier) can't be invented; the platform identifies those and requests them, rather than leaving you to discover the gaps manually. ### Who is responsible if the passport data is wrong? The economic operator placing the product on the EU market — manufacturer, importer, or authorised representative — is legally responsible for the passport's accuracy, regardless of whether a consultant or a platform helped assemble it. That's why ownership and maintenance after launch matter: you carry the liability for the life of the product. --- --- title: "Textile Digital Product Passport: What Brands Must Prepare" description: Textiles are an ESPR priority for the EU Digital Product Passport. What a textile DPP will require, the honest timeline, and how to prepare now. canonical: "https://www.tracepass.eu/resources/textile-digital-product-passport" locale: en source: "https://www.tracepass.eu/resources/textile-digital-product-passport" --- # Textile Digital Product Passport: What Brands Must Prepare > Textiles are an ESPR priority for the EU Digital Product Passport. What a textile DPP will require, the honest timeline, and how to prepare now. Textiles and footwear are named as a priority product group in the EU's ESPR working plan, adopted on 16 April 2025 — so a textile Digital Product Passport is coming. But there is no hard compliance date yet: requirements are commonly expected around 2027-2028 and will only become binding when the European Commission adopts the relevant delegated act under ESPR (Regulation (EU) 2024/1781). The smart move in 2026 is to start collecting multi-tier supplier data now, because that — not the QR code — is the real bottleneck. ## Textiles are an ESPR priority — but exact DPP dates aren't set yet Textiles and footwear are named among the first priority product groups in the ESPR working plan, which the European Commission adopted on 16 April 2025. That gives the sector a strong signal: a Digital Product Passport is coming. What it does not give yet is a hard compliance date. Under ESPR (Regulation (EU) 2024/1781), the binding requirements for any product group only become law when the Commission adopts the relevant delegated act. For textiles, that delegated act has not been published, so any specific deadline you see quoted today is a projection, not a legal obligation. Treat the commonly cited 2027-2028 window as planning guidance, and verify against the delegated act when it lands. ## What a textile DPP is expected to require The exact data model will be defined in the delegated act, but the direction of travel is clear from the ESPR text, the EU Strategy for Sustainable and Circular Textiles, and parallel passport regimes. Apparel and fashion brands should expect a textile DPP to carry product-level and item-level data that today lives in scattered datasheets, lab reports and supplier emails. The categories below are the ones most consistently signalled, so they are the safest to start collecting now. - Fibre composition — full percentage breakdown (e.g. 80% cotton / 20% polyester), aligned with existing textile labelling rules - Country of manufacture and key processing stages — where the product was spun, woven/knitted, dyed/finished and assembled - Recycled content — share of pre- and post-consumer recycled fibre, with a basis for the claim - Chemical and SVHC information — substances of very high concern present above threshold, consistent with REACH - Care, durability and repair — care instructions, repairability and where to get repairs - Recyclability and end-of-life — fibre recyclability and disassembly/take-back guidance - Microfibre shedding — disclosure where relevant to the product type ## The real bottleneck: multi-tier supply-chain data Most of what a textile DPP needs does not exist inside the brand. It is scattered across a supply chain that typically runs fibre grower → spinner → mill (weaver/knitter) → dye house → garment maker → brand. Fibre origin and recycled content sit at the grower and spinner tiers. Chemical and SVHC data sit at the dye house and finisher. The brand at the top of the chain often has visibility only one tier down, to its direct supplier. That structural gap — not the QR code, not the publishing layer — is what makes textile DPP compliance hard. You cannot publish a fibre-composition or microfibre claim you cannot trace. ## Why supplier data, not technology, is what slows brands down Brands often assume the hard part is building or buying passport software. In practice, the passport is the easy 20%. The hard 80% is collecting verifiable upstream data from suppliers who use different languages, formats, and systems — and who may not yet understand what ESPR will ask of them. A textile collection can involve dozens of styles, each with several components and multiple upstream suppliers, so the data-collection effort scales fast. Brands that win will be the ones that start mapping their tiers and chasing supplier data now, well before the delegated act sets a deadline. ## How an automated pipeline plus a supplier portal handles the tiers TracePass is built around this exact problem. You upload the documents you already hold — datasheets, test certificates, EPREL entries, lab reports — and AI extraction reads them and fills the regulated textile fields automatically, each with a confidence score and a source attribution back to the original document. A person on your team reviews and approves before anything is published, so the audit trail stays human-controlled. For the fields you do not hold, a supplier portal invites your spinner, mill or dye house to submit the missing data directly, tier by tier, so upstream information flows into the same passport without endless email chains. The output is a published GS1 Digital Link QR passport — EU-hosted, ready for the EU Central DPP Registry that goes live on 19 July 2026. > **Key takeaway** > > A textile DPP is confirmed as a direction under the ESPR working plan (adopted 16 April 2025), with requirements commonly expected around 2027-2028 but not yet hard-dated — the binding timeline waits on a delegated act. The work that takes longest is collecting verifiable multi-tier supplier data, so start mapping suppliers and gathering fibre, chemical and recycled-content evidence now, not when the deadline is set. ## What apparel and fashion brands should do in 2026 The honest answer is that you cannot finalise a textile DPP today, because the field-by-field legal spec is still pending. But you can do the work that the deadline will not give you time for later. Map your supply chain to the tier level. Identify which suppliers hold fibre origin, recycled-content and chemical data. Centralise the documents you already have, and open a channel to chase the rest. Brands that treat 2026 as a data-foundation year, rather than waiting for the delegated act, will publish passports calmly instead of scrambling. TracePass currently powers passports for the jewellery brand Vantony, and the same upload-extract-review-publish flow applies directly to textiles. ## FAQ ### When will a textile Digital Product Passport become mandatory? No exact date is fixed yet. Textiles are a priority product group in the ESPR working plan adopted on 16 April 2025, and requirements are commonly expected around 2027-2028. They only become legally binding when the European Commission adopts the relevant delegated act under ESPR (Regulation (EU) 2024/1781), so treat any specific date as a projection until that act is published. ### What data will a textile DPP need to contain? The final list awaits the delegated act, but the most consistently signalled fields are fibre composition, country of manufacture and processing stages, recycled content, chemical/SVHC information consistent with REACH, care/durability/repair guidance, recyclability and end-of-life information, and microfibre shedding where relevant. ### Why is supplier data the hardest part of textile DPP compliance? Most required data lives upstream, across a chain of fibre grower, spinner, mill, dye house and garment maker. Brands usually have visibility only one tier down. Collecting verifiable data from suppliers in different languages, formats and systems is roughly 80% of the effort, while building or publishing the passport itself is the easy part. ### How does TracePass help apparel brands prepare a textile DPP? You upload documents you already hold — datasheets, certificates, EPREL entries, lab reports — and AI extraction fills the regulated fields with a confidence score and source attribution. A reviewer approves before publishing, and a supplier portal collects missing upstream data tier by tier. The output is a GS1 Digital Link QR passport, EU-hosted, ready for the EU Central DPP Registry going live on 19 July 2026. ### What should fashion brands do in 2026 if the deadline is not set? Use 2026 as a data-foundation year. Map your supply chain to the tier level, identify which suppliers hold fibre-origin, recycled-content and chemical data, centralise the documents you already have, and open a channel to chase the rest — so you can publish calmly once the delegated act sets a deadline. --- --- title: When Does My Product Need a DPP? ESPR Timeline by Group description: Batteries need a DPP by 18 Feb 2027. Other ESPR groups await delegated acts. Find your group, your date, and the honest caveats. canonical: "https://www.tracepass.eu/resources/when-does-my-product-need-a-dpp" locale: en source: "https://www.tracepass.eu/resources/when-does-my-product-need-a-dpp" --- # When Does My Product Need a DPP? ESPR Timeline by Group > Batteries need a DPP by 18 Feb 2027. Other ESPR groups await delegated acts. Find your group, your date, and the honest caveats. Most products do not need a Digital Product Passport (DPP) yet. Under the ESPR (Regulation (EU) 2024/1781), the DPP rolls out one product group at a time, each switched on by its own delegated act. The single firm deadline today is batteries: mandatory from 18 February 2027 under the EU Battery Regulation (EU) 2023/1542. Other priority groups — textiles, electronics, furniture, iron and steel, tyres, detergents — are on the ESPR working plan, but most of their dates are not yet final and await delegated acts. To answer "does my product need a DPP, and by when", find your ESPR group and track its delegated act. Most products do not need a Digital Product Passport (DPP) yet. The EU's Ecodesign for Sustainable Products Regulation (ESPR, Regulation (EU) 2024/1781) introduces the DPP product group by product group, each activated by its own delegated act. The one firmly dated obligation today is the battery passport: mandatory from 18 February 2027 under the EU Battery Regulation (EU) 2023/1542. For every other priority group (textiles and apparel, electronics and ICT, furniture, iron and steel, tyres, detergents), DPP requirements are expected under the ESPR working plan but most exact dates are not yet final and await delegated acts. To know whether your product needs a DPP, identify your ESPR product group, then track the delegated act that sets its rules and timeline. ## How ESPR decides which products need a DPP ESPR is a framework regulation: it is already in force, but it does not impose DPP obligations on any product on its own. Instead, the European Commission selects priority product groups and then issues a separate delegated act for each one. That delegated act is what actually defines the ecodesign requirements, the exact data fields the passport must carry, the carrier (a QR or data-carrier linked via GS1 Digital Link), and the application date. So the practical question is never just "does ESPR apply to me" but "has a delegated act been adopted for my product group, and what date does it set". ## Batteries: the one hard deadline (18 February 2027) Batteries are governed not by ESPR but by the standalone EU Battery Regulation (EU) 2023/1542, and they are first in line. From 18 February 2027, every EV battery, light means of transport (LMT) battery, and industrial battery with a capacity above 2 kWh placed on the EU market must carry a digital battery passport accessible via a QR code. The passport must hold structured data on origin, material composition, carbon footprint, performance over the battery's life, and end-of-life and recycling information. If you place these batteries on the market, this is a fixed legal date, not a projection. ## The ESPR priority groups and what we know about their dates The ESPR working plan names the product groups the Commission intends to address first. Textiles and apparel are explicitly a priority group, and first textile DPP requirements are commonly cited for roughly 2027 to 2028 — but they are not yet hard-dated, because the delegated act has not been finalised. The same caution applies across the board: these groups are on the roadmap, but their precise application dates depend on delegated acts that are still in preparation. Treat any single calendar date you see quoted for non-battery groups as an expectation, not a settled obligation, until the relevant act is published in the Official Journal. - Batteries (EV, LMT, industrial >2 kWh) — mandatory 18 February 2027 under Reg (EU) 2023/1542. Hard-dated. - Textiles and apparel — priority ESPR group; first requirements expected ~2027-2028 under the working plan, exact date awaits the delegated act. - Electronics and ICT — named priority group; timeline expected under the ESPR working plan, not yet hard-dated. - Furniture — named priority group; timeline expected under the ESPR working plan, not yet hard-dated. - Iron and steel — named priority group; timeline expected under the ESPR working plan, not yet hard-dated. - Tyres and detergents — named priority groups; timelines expected under the ESPR working plan, not yet hard-dated. ## A four-step method to find your group and your date You can answer "does my product need a DPP and by when" yourself with a repeatable check. First, classify your product against the ESPR working plan and the Battery Regulation scope — batteries are governed separately. Second, find whether a delegated act has been adopted for that group; if none exists yet, you have no DPP obligation today, only a roadmap to watch. Third, read the application date and transition period in that act, since obligations typically apply to products placed on the market from a stated date. Fourth, re-check periodically, because delegated acts are adopted on a rolling basis through roughly 2027 to 2030. ## The EU Central DPP Registry goes live 19 July 2026 One date that is fixed for everyone is the launch of the EU Central DPP Registry, scheduled to be operational from 19 July 2026 under Article 13 of ESPR. The registry is a directory, not a data store: given a product's unique identifier via GS1 Digital Link, it returns the location of that product's passport, which remains hosted by the manufacturer or their platform. It will also hold unique identifiers and customs commodity codes for products entering free circulation. The registry going live does not by itself make any product group's DPP mandatory — that still depends on each group's delegated act — but it is the backbone every passport will plug into. > **Key takeaway** > > Only one DPP deadline is hard today: batteries on 18 February 2027 under Reg (EU) 2023/1542. The EU Central DPP Registry goes live 19 July 2026. Every other group (textiles, electronics, furniture, steel, tyres, detergents) is on the ESPR working plan but awaits a delegated act, so its date is an expectation, not a settled obligation. ## Why early preparation pays even without a fixed date The hardest part of a DPP is rarely the QR code — it is assembling accurate, source-attributed product data, much of which sits with upstream suppliers. That work takes months regardless of the legal date, so the absence of a final deadline for your group is not a reason to wait. This is where TracePass helps: you upload the documents you already hold — datasheets, certificates, EPREL entries — and the AI extracts and fills the regulated fields, each with a confidence score and a link back to its source. A human reviews and approves before anything is published, and a supplier portal collects the missing upstream data you cannot fill yourself. TracePass is EU-hosted, with plans that scale from a Free tier (3 passports) to Basic at €49/mo and Starter at €350/mo, which adds AI extraction — and there is no per-scan or per-SKU billing, so a passport that gets scanned a million times costs the same as one that is never scanned. Early adopters such as the jewellery brand Vantony use it to publish GS1 Digital Link QR passports today, building the data discipline now that any future delegated act will demand. ## FAQ ### Does my product need a Digital Product Passport right now? Almost certainly not yet, unless you place EV, light-means-of-transport, or industrial batteries above 2 kWh on the EU market — those need a battery passport from 18 February 2027. For all other product groups, a DPP only becomes mandatory once the European Commission adopts the delegated act that covers your ESPR group, and most of those acts are still in preparation. ### What is the first hard DPP deadline? The battery passport under the EU Battery Regulation (EU) 2023/1542, mandatory from 18 February 2027 for EV, LMT, and industrial batteries with a capacity above 2 kWh. It is the only firmly dated DPP obligation today; all ESPR product-group dates depend on delegated acts. ### When will textiles need a DPP? Textiles and apparel are a priority group under the ESPR working plan, and first requirements are commonly cited for roughly 2027 to 2028. However, the exact date is not yet settled — it awaits the delegated act for textiles. Until that act is published in the Official Journal, any specific textile DPP date should be treated as an expectation. ### What is the EU Central DPP Registry and when does it launch? It is a directory, scheduled to be operational from 19 July 2026 under Article 13 of ESPR, that maps a product's unique identifier (via GS1 Digital Link) to the location of its passport. It does not store the passports themselves and does not by itself make any group's DPP mandatory; each group's obligation still comes from its own delegated act. ### How do I find the DPP date for my specific product? Classify your product against the ESPR working plan and the Battery Regulation scope, then check whether a delegated act has been adopted for that group. If one exists, read its application date and transition period; if none exists yet, you have no obligation today, only a roadmap. Re-check periodically, since acts are adopted on a rolling basis through roughly 2027 to 2030. ### Should I prepare before my group has a fixed date? Yes. The slow part of a DPP is collecting accurate, source-attributed data, much of it from upstream suppliers, which takes months regardless of the legal date. Tools like TracePass let you extract regulated fields from existing documents with confidence scores and source links, route missing data through a supplier portal, and publish GS1 Digital Link QR passports now. --- --- title: "Second-Life Batteries: Do They Need a New DPP?" description: Repurposing an EV battery for storage is a new placing on the market — it generally needs a new battery passport linked to the original. canonical: "https://www.tracepass.eu/resources/second-life-battery-passport" locale: en source: "https://www.tracepass.eu/resources/second-life-battery-passport" --- # Second-Life Batteries: Do They Need a New DPP? > Repurposing an EV battery for storage is a new placing on the market — it generally needs a new battery passport linked to the original. Short answer: yes — in most cases a repurposed or remanufactured battery needs a new battery passport, not the old one. Under the EU Battery Regulation, taking an EV battery and giving it a second life as stationary storage is treated as placing a new product on the market. The repurposer becomes the responsible economic operator, and the new passport must be linked back to the original so the battery's full history travels with it. ## Does a second-life battery need a new passport? Yes, generally. The EU Battery Regulation (Regulation (EU) 2023/1542) is explicit on this point. Where a battery has undergone preparation for re-use, preparation for repurposing, repurposing or remanufacturing, that battery must have a NEW battery passport, and the obligation to fulfil passport requirements transfers to the economic operator that places the repurposed battery on the market or puts it into service. The new passport must be linked to the passport (or passports) of the original battery. So the practical rule is: a meaningful second life triggers a new passport — but not a blank one. It inherits a documented lineage. ## Why repurposing counts as a new placing on the market The trigger is not a coat of paint or a new label — it is a change of identity and intended use. An EV traction battery designed for vehicle propulsion that is reconfigured into a stationary energy storage system is, in regulatory terms, a different product serving a different application. That act of making it available on the EU market for the first time in its new form is a placing on the market. Once that happens, the regulation's conformity and passport obligations attach again, and they attach to whoever did the repurposing — not the original car maker. > **Key takeaway** > > Repurposing an EV battery into stationary storage = a new placing on the market. The repurposer becomes the responsible economic operator and must issue a NEW battery passport, linked back to the original. Lineage is preserved through linking, not by reusing the old passport. The battery passport requirement applies from 18 February 2027. ## Who is accountable: the repurposer becomes the economic operator This is the part teams underestimate. The regulation shifts the full weight of passport responsibility to the entity that places the second-life battery on the market. If you take used EV modules and build storage cabinets from them, you are not a downstream reseller — you are the economic operator on the hook for the new passport, the relevant conformity steps for the new product, and keeping unit-level data accurate. You cannot point back to the carmaker. Their obligations covered the battery's first life; yours cover its second. ## What changes in the passport for a second-life battery Some data carries over unchanged — chemistry, material composition, the cells' manufacturing origin. Other fields are reset, updated, or added to reflect the battery's new identity and condition. The most consequential are the status and performance fields, because a second-life buyer is paying for remaining usable life, not nameplate capacity. - Status: original use → re-used / repurposed / remanufactured (the battery's lifecycle state) - State of health (SOH) and remaining/estimated capacity at the point of repurposing - Charge-cycle count and, where tracked, temperature and notable-event history - The repurposing entity — identity of the new responsible economic operator - New warranty terms and new expected service life for the second-life application - Link to the original battery passport(s) so the full lineage is traceable ## Why the original passport's history matters A second-life market only works if buyers can trust what they are buying. The original passport's record — manufacturing data, chemistry, and accumulated usage signals like cycle count and state of health — is exactly the information a repurposer needs to grade modules and a buyer needs to price risk. That is why the regulation requires linking rather than discarding: the new passport answers "what is this now?" while the link answers "what was it, and how hard was it worked?" Without that lineage, second-life trade falls back on guesswork, which is precisely the friction the passport is designed to remove. ## Where the rules are still being detailed — be honest about it Be precise here: the core obligations above are set in the regulation's text, but several secondary-use mechanics depend on implementing and delegated acts and technical specifications that are still being finalised. The exact data-format and access-role specifications for the passport, and the fine detail of how original and second-life passports interlink and how SOH is reported, are being worked out. Treat the principles as fixed and the precise field formats as firming up. A defensible approach is to capture more provenance than you think you need now, so you are not re-collecting it once the specifications land. ## How TracePass keeps the lineage with passport versioning and a durable URL The clean way to handle a second life is a durable identifier plus versioning. With a GS1 Digital Link QR, the battery resolves to a stable URL, and the passport behind it is versioned — so the repurposed status, updated SOH and new warranty become a new version that links back to the original record rather than overwriting it. In TracePass, a repurposer can upload the documents they hold — module test reports, SOH measurements, the original passport reference — and the AI extracts and fills the regulated fields with a confidence score and source attribution, which a person reviews and approves before publishing. The supplier portal helps pull missing upstream data (for example original-cell provenance) from whoever holds it. The result: a new, accountable passport for the second-life product, with the first-life history one link away. ## FAQ ### Does a refurbished EV battery used in stationary storage need a new battery passport? Generally yes. Under Regulation (EU) 2023/1542, a battery that has been repurposed or remanufactured must have a new battery passport, linked to the original passport(s). Moving an EV battery into stationary storage is treated as placing a new product on the market, which triggers the new passport. ### Who is responsible for the second-life battery passport — the carmaker or the repurposer? The repurposer. The regulation transfers passport responsibility to the economic operator that places the repurposed battery on the market or puts it into service. The original manufacturer's obligations covered the battery's first life; the repurposer is accountable for the second. ### What fields change in a second-life battery passport? Typically the status (re-used / repurposed / remanufactured), state of health and remaining capacity, cycle count and usage history, the identity of the repurposing entity, new warranty and expected service life, and a link to the original passport. Chemistry and material composition usually carry over. ### Does the original passport get deleted when a battery is repurposed? No. The new passport is linked to the original rather than replacing it. This preserves the lineage — manufacturing data, chemistry and prior usage — which second-life buyers rely on to assess condition and price risk. ### When does the EU battery passport requirement apply? From 18 February 2027, each LMT battery, industrial battery above 2 kWh, and EV battery placed on the EU market or put into service must have a battery passport. Repurposed batteries placed on the market fall under the same regime via the new linked passport. ### Are the second-life passport rules fully finalised? The core obligations are set in the regulation, but some secondary-use mechanics — exact data formats, access roles, and how state of health and passport links are specified — depend on implementing and delegated acts still being finalised. Capture provenance generously now to avoid re-collecting it later. --- --- title: A Bulgarian jeweller puts Digital Product Passports on its pieces description: How Vantony, a Bulgarian fine-jewellery brand, became a TracePass design partner — putting provenance and materials data on every piece, before any mandate. canonical: "https://www.tracepass.eu/resources/vantony-jewellery-dpp-pilot" locale: en source: "https://www.tracepass.eu/resources/vantony-jewellery-dpp-pilot" --- # A Bulgarian jeweller puts Digital Product Passports on its pieces > How Vantony, a Bulgarian fine-jewellery brand, became a TracePass design partner — putting provenance and materials data on every piece, before any mandate. Jewellery isn't on any Digital Product Passport deadline. There's no delegated act compelling a ring or a pendant to carry a DPP the way the EU Battery Regulation compels a battery pack from February 2027. So when Vantony — a Bulgarian fine-jewellery brand — became one of TracePass's first design partners, it wasn't to beat a regulator. It was because a passport on every piece does something jewellery has always wanted to do anyway: prove what the thing is made of, where it came from, and how to care for it — to the person holding it, in their own language, by scanning a code. This is the story of that pilot: what a jewellery passport actually carries, why a brand would adopt one before it's required, and what we learned wiring a real catalogue through the platform. ## Who Vantony is Vantony is a fine-jewellery brand based in Sofia, Bulgaria, working largely in sterling silver (925) and gold set with natural stones — sapphire, amber, agate, tiger's eye and others. It's the kind of brand whose customers already care about authenticity and provenance: where a stone came from, whether it's natural or treated, how to look after it. That's exactly the buyer a Digital Product Passport speaks to, which made Vantony a natural first jewellery pilot. ## Why jewellery, when there's no mandate The Ecodesign for Sustainable Products Regulation (ESPR — Regulation (EU) 2024/1781) is the umbrella that brings Digital Product Passports to category after category. Jewellery has no delegated act yet, so a jewellery DPP today is voluntary — there's no deadline forcing it. But “no DPP mandate” doesn't mean “no rules.” The horizontal regulations already apply to jewellery regardless: - REACH restricts lead and cadmium content and nickel release in items in prolonged contact with skin. - Conflict-mineral and Kimberley-Process expectations bear on the stones. - Hallmarking / assay rules apply to precious metals. So the data a passport would carry is data a serious jewellery brand should be able to stand behind anyway. The DPP just makes it legible — to a customer, a retailer, or a regulator — through one QR code. And for a brand, the upside is the story. A scannable passport turns “trust us” into “scan it and see”: metal and fineness, stone type and origin, natural-versus-treated, care instructions, and — where the data exists — ethical-sourcing status. Every sale becomes a provenance story the customer can carry in their pocket and share. The brands that adopt this early own that narrative before it's table stakes. ## What a jewellery passport carries A jewellery DPP on TracePass is built from the platform's jewellery template — a structured field set covering: - Identity — product name, category, unique per-item identifier. - Materials — primary metal and fineness (e.g. silver 925), additional metals, metal weight. - Stones — type, colour, cut, clarity, carat weight, country of origin, and whether natural or treated. - Provenance & ethics — conflict-free and Kimberley-Process status, mine or region where known, any chain-of-custody or responsible-sourcing certification. - Compliance — REACH indicators (lead, cadmium, nickel release), any test report. - Hallmark / assay — presence, authority and number where applicable. - Care & circularity — care and cleaning instructions, repair / resize / take-back options, recyclability. Not every field is filled for every piece — and that's deliberate. Jewellery supply-chain data, especially a stone's precise origin, is genuinely hard to pin down. TracePass runs an “AI suggests, a human approves” model, and a field left honestly blank (or flagged as unverified) is treated as the correct answer when the brand can't yet stand behind a value. A passport that's transparent about what it doesn't know is worth more than one that fabricates provenance. ## How the pilot worked Vantony's catalogue was brought into the platform as draft products and passports — no AI extraction spend, just structured imports. Manufacturer-identifying details prefilled automatically; the material and stone facts that only the brand truly knows are filled by the brand. Each piece resolves at a GS1 Digital Link URL keyed on a per-item serial, and the public passport renders in any of 24 EU languages from a single source entry — a Bulgarian shopper and a German one scan the same QR and each read it in their own language. One honest detail worth stating plainly, because it's the kind of thing a sharp buyer notices: Vantony isn't a GS1 member, so the passports use a GS1 test-pattern product code in the identifier slot, with the real uniqueness carried by the per-item serial. That keeps the Digital Link URL well-formed and resolvable without inventing a registered code that belongs to someone else. It's the right call for a pilot, and we'd rather explain it than paper over it. ## What this pilot is — and isn't Vantony is a design partner, not a paying customer — the arrangement is a barter, and the point of it is mutual: Vantony gets passports on its pieces ahead of the curve, and TracePass gets a real-world jewellery catalogue to harden the product against. Calling it anything grander would be overselling, and overselling is the opposite of what a provenance platform should do. Jewellery doesn't have to wait for a mandate to benefit from a Digital Product Passport. The brands that put verifiable provenance, materials and care data behind a QR code now are the ones that own the trust story when their customers — and eventually the regulators — come asking. Vantony is one of the first to do it. ## FAQ ### Is a Digital Product Passport mandatory for jewellery? No. Jewellery has no ESPR delegated act yet, so a jewellery DPP is currently voluntary. REACH (lead, cadmium, nickel release), conflict-mineral and hallmarking rules still apply to jewellery regardless of the DPP timeline. ### What does a jewellery passport show? Metal type and fineness, stone type, origin and whether it's natural or treated, weights, any hallmark or certification, ethical-sourcing status where known, and care instructions — all accessible by scanning a QR code on the piece. ### Why would a brand adopt a DPP before it's required? Provenance and authenticity are already part of how fine jewellery is sold. A passport makes that verifiable and shareable, and early adopters build the trust narrative before it becomes an expectation. --- --- title: "Why a Tier-1 Supplier Declaration Isn't Enough for a DPP" description: "A tier-1 supplier declaration tells you what your direct supplier asserts — not what's verifiable or upstream. Why DPP data needs evidence and chain depth." canonical: "https://www.tracepass.eu/resources/why-supplier-declarations-fail-dpp" locale: en source: "https://www.tracepass.eu/resources/why-supplier-declarations-fail-dpp" --- # Why a Tier-1 Supplier Declaration Isn't Enough for a DPP > A tier-1 supplier declaration tells you what your direct supplier asserts — not what's verifiable or upstream. Why DPP data needs evidence and chain depth. A tier-1 supplier declaration usually isn't enough for a Digital Product Passport. It's an assertion rather than verifiable evidence, it covers data the tier-1 doesn't own (the real origin is upstream), and it's a static snapshot while the passport is a living record. When a manufacturer starts assembling a Digital Product Passport, the instinct is to ask the tier-1 supplier — the company that actually shipped the part — to "send a declaration." A signed letter on letterhead, a filled-in template, a self-declaration of conformity. It feels like the data is now in hand. For a Digital Product Passport it usually isn't, and treating a tier-1 declaration as the answer is one of the most common ways a DPP project quietly ships non-compliant data. Here's why a direct-supplier declaration falls short of what the passport actually needs, and what closes the gap. ## What a tier-1 declaration actually is A tier-1 supplier is your direct supplier — the one you have a contract and a PO with. A declaration from them is an assertion: "this component contains X% recycled content," "this material is REACH-compliant," "no SVHCs above 0.1%." It carries their name and, usually, a signature. That is genuinely useful — it establishes accountability and a paper trail. But a DPP doesn't ask "what does your supplier assert?" It asks "what is true about this product, and can you prove it?" Those are different questions, and the gap between them is where tier-1 declarations fall short. ## The three gaps a declaration leaves open A self-declaration from your direct supplier leaves three specific holes that a Digital Product Passport is built to close. ### 1. It's an assertion, not evidence EU Digital Product Passport requirements — across the Battery Regulation, REACH, and the ESPR delegated acts — increasingly call for verifiable evidence, not just stated values. A recycled-content figure should trace to a test report or a mass-balance certificate; a hazardous-substance claim should reference the SDS or a lab result; a carbon footprint should cite the calculation method and dataset. A declaration that says "30% recycled content" with nothing behind it is a value without a source. In the passport, that's the difference between a field that withstands a market-surveillance check and one that doesn't. ### 2. Your tier-1 doesn't own most of the data This is the structural problem. Your direct supplier assembled or sold the part — but the data the passport needs usually originates further upstream. For a battery, the cell's chemistry, the cobalt and lithium due-diligence evidence, and the internal-resistance behaviour come from the cell maker and the raw-material suppliers, not the pack assembler you buy from. When your tier-1 signs a declaration covering those fields, they're often passing through what their own supplier told them — or worse, estimating. A declaration that confidently covers fields its signer doesn't control is a chain-of-custody gap dressed up as an answer. ### 3. It freezes a moment, but the passport is a living record A declaration is dated and static. A DPP carries data that can change — recycled-content percentages shift batch to batch, a supplier reformulates, an SVHC gets added to the candidate list. A one-time signed letter doesn't track that. The passport needs a data relationship that can be re-queried and re-evidenced, not a PDF in an email from eight months ago. > **Why this matters for compliance** > > A market-surveillance authority checking a passport isn't asking whether you collected a declaration. It's asking whether the asserted value is correct and supported. "Our supplier told us" is not a defence if the value is wrong — the economic operator placing the product on the market carries the responsibility, regardless of who supplied the figure. ## Why "just get a declaration" is so tempting The reason this shortcut is everywhere is that it looks like progress and it's cheap. Emailing a template to ten tier-1 suppliers and getting signed PDFs back feels like the data-collection problem is solved. It's only when you try to publish the passport — or when someone audits it — that the gaps surface: the recycled-content number has no test report, the REACH line covers a substance the tier-1 never tested for, the carbon figure has no method. By then the project is "done" on paper and the rework is expensive. ## What actually closes the gap The fix isn't to abandon declarations — they're a fine starting point for accountability. It's to treat them as the top of a chain, not the whole chain, and to attach evidence and depth to every load-bearing field. - Ask for evidence, not just values. For every regulated field, the request should be "the number AND the document that proves it" — test report, EPD, SDS, mass-balance certificate, due-diligence record. A field with an evidence link is worth ten signed declarations without one. - Reach the tier that owns the data. For fields the tier-1 doesn't control, the data request has to flow upstream — to the cell maker, the fibre grower, the resin formulator. A supplier portal that lets a tier-1 forward a specific request to its own supplier beats a declaration that launders second-hand data. - Record provenance per field. The passport should know, for each value, who supplied it, from which document, and when — so a wrong figure is traceable to its source and a stale one can be refreshed. This is exactly what a field-level audit trail is for. - Validate, don't just store. A declared value that's physically implausible (a recycled-content figure over 100%, a nickel-release rate far outside the regulated band) should be flagged on the way in, not discovered at audit. ## The TracePass approach This is why TracePass treats supplier data as evidence-backed and chain-aware rather than a single declaration. The supplier portal lets a request reach the party that actually holds the data — including a tier-1 forwarding it upstream — and every field carries provenance: who entered it, from which document, when. The AI extraction reads the underlying test reports, SDS files and certificates, so the value in the passport is linked to the document that supports it rather than retyped from a declaration. The point isn't to make suppliers fill in more forms — it's to make the data in the passport true and provable, which is the only version of "collected" that survives a compliance check. A tier-1 declaration is a reasonable first knock on the door. It just isn't the room. A Digital Product Passport that will hold up needs the evidence behind the claim and the depth to reach the data's real source — and that's a data architecture problem, not a form-filling one. ## FAQ ### Is a supplier declaration enough for a Digital Product Passport? Usually not on its own. A declaration is a stated value with accountability attached, but DPP requirements increasingly call for verifiable evidence (test reports, EPDs, SDS, due-diligence records) and for data that originates upstream of your direct supplier. Treat a declaration as a starting point that needs evidence and chain depth attached, not as the finished data. ### Why isn't tier-1 vendor data good enough for a DPP? Because your tier-1 (direct) supplier often doesn't own the data the passport needs — for a battery, the cell chemistry and raw-material due diligence come from further upstream. A tier-1 declaration covering those fields is passing through second-hand data, and it's an assertion rather than evidence. The economic operator placing the product on the market is responsible for the value being correct, not just for having collected a declaration. ### What's the alternative to collecting supplier declarations? Collect evidence-backed data with provenance: for every regulated field, capture the value and the document that proves it, route requests to the tier that actually owns the data, and record who supplied each value, from which document, and when. That's what makes a passport field withstand a market-surveillance check. --- --- title: Where Do You Fill In a Digital Product Passport? description: "No EU portal accepts DPP data. You build a DPP on a compliant platform: pick a template, fill the fields, and publish — generating a GS1 Digital Link QR code." canonical: "https://www.tracepass.eu/resources/dove-si-compila-il-dpp" locale: en source: "https://www.tracepass.eu/resources/dove-si-compila-il-dpp" --- # Where Do You Fill In a Digital Product Passport? > No EU portal accepts DPP data. You build a DPP on a compliant platform: pick a template, fill the fields, and publish — generating a GS1 Digital Link QR code. One of the first questions companies ask when they learn about the Digital Product Passport is: where do I actually go to fill it in? Is there a form somewhere on a government website? The short answer is no — and understanding why matters for how you plan your compliance work. ## Is there an official EU DPP portal? No. The EU does not operate a data-entry portal where you type in your product's DPP fields. The EU DPP Registry — managed under the ESPR framework — is a registry of identifiers and economic operators. It records that a DPP exists and who is responsible for it; it does not store the DPP's field data, and you do not enter product information directly into it. ## How do you create a DPP? You create a DPP on a compliant platform or via its API. The process has four steps regardless of which platform you use: - Pick the category — the category determines which field template applies (battery, packaging, electronics, textiles, and so on). Each category has its own mandatory field set under the relevant regulation. - Complete the field template — enter the required values (material composition, carbon footprint, recycled content, compliance references, and so on) and attach supporting evidence (test reports, SDS files, certificates). - Review and approve — the platform flags missing required fields or implausible values before you publish. A human approves the final record. - Publish — the platform registers the DPP, generates a GS1 Digital Link QR code, and makes the record accessible to authorised parties (public fields, restricted fields for inspectors, authority-access fields for regulators). ## How is the DPP published? When you publish a DPP, the platform mints a unique identifier and a GS1 Digital Link URL. That URL is encoded into a QR code which goes on the physical product (or its packaging). Anyone who scans the QR code is resolved to the right DPP record — the public data tier is openly readable, while restricted tiers require authentication. The data itself lives on the platform, not on the QR code. ## What TracePass provides TracePass is the platform where you complete this process. For each regulated category, it ships a pre-built field template matching the regulation's field list — you fill in the values, attach evidence, and publish. You can work through the form in the browser, or drive the whole process via the REST API. A supplier portal lets you forward specific field requests upstream to the parties that own the data, so you are not limited to what your direct supplier can provide. ## FAQ ### Is there an EU government website where I enter my DPP data? No. The EU DPP Registry records identifiers and responsible operators — it is not a data-entry portal. You create and host DPP data on a compliant platform like TracePass, not on an EU government site. ### How do I create a Digital Product Passport? Pick the product category on a compliant platform to load the correct field template. Complete the required fields, attach supporting evidence, and publish. Publishing registers the DPP and generates a GS1 Digital Link QR code for the physical product. ### How is a DPP published and made available? When you publish, the platform mints a unique identifier and a GS1 Digital Link URL, encoded into a QR code for the physical product. Scanning the QR code resolves to the DPP record — public fields are openly readable; restricted and authority-access tiers require authentication. ### Can I create a DPP via API instead of a web form? Yes. TracePass exposes a REST API so you can create, update, and publish passports programmatically. This suits high-volume workflows — for example, creating one passport per manufactured unit from your ERP or production system. --- --- title: Do Lamps Need a Digital Product Passport? description: Lamps have no binding DPP deadline. ESPR sets no requirements directly — obligations need a delegated act, none adopted for lamps or electronics yet. canonical: "https://www.tracepass.eu/resources/brauchen-lampen-einen-dpp" locale: en source: "https://www.tracepass.eu/resources/brauchen-lampen-einen-dpp" --- # Do Lamps Need a Digital Product Passport? > Lamps have no binding DPP deadline. ESPR sets no requirements directly — obligations need a delegated act, none adopted for lamps or electronics yet. If you manufacture or import lamps for the EU market, you may have seen references to a "2029 DPP deadline" for electronics or lamps. That date is not a confirmed obligation — it is an indicative estimate from the European Commission's ESPR working plan, and the underlying delegated act that would make a lamp DPP legally mandatory has not been adopted. Here is what the law actually says today, and what to watch. ## Do lamps legally need a DPP right now? No. Lamps are electrical and electronic equipment (EEE), and EEE falls under the Ecodesign for Sustainable Products Regulation (ESPR — Regulation (EU) 2024/1781). However, ESPR does not set DPP requirements by itself. The regulation provides the legal framework and Article 4 delegated acts are the mechanism through which specific product obligations — including a Digital Product Passport — become mandatory. No delegated act has been adopted for lamps or for EEE generally, so no lamp DPP is legally required today. ## When might a lamp DPP become mandatory? The European Commission's first ESPR working plan (2025–2030) lists electronics and EEE as a priority group, with an indicative timeline of around 2029 for a delegated act. That figure — 2029 — is an estimate in a sequencing document, not a legal deadline. The delegated act itself sets the date, and it has not been adopted. Until the Commission formally adopts an electronics/EEE delegated act, the 2029 figure remains a planning estimate only. > **2029 is indicative, not confirmed** > > Any source stating that a lamp DPP is "required from 2029" is citing a working-plan estimate as if it were a legal deadline. The Commission can revise its working plan, and the delegated act for EEE has not been proposed in final form. Plan for the possibility, do not treat it as a fixed obligation. ## What about the battery in a rechargeable lamp? This is a separate matter governed by a separate regulation. If a lamp contains a battery that falls in scope of the EU Battery Regulation (Regulation (EU) 2023/1542), that battery requires its own digital passport under Article 77 from 18 February 2027. The key scoping questions are battery type and capacity: LMT batteries above 25 V or 250 W, industrial batteries above 2 kWh, and EV batteries are in scope. Most consumer lamp batteries are small lithium cells well below the industrial threshold, so they are outside the February 2027 battery-passport obligation — but verify the category and capacity for your specific product. The lamp itself has no DPP obligation today regardless of the battery. ## What can you do now? There is no legal requirement to act on a lamp DPP today. What you can reasonably do is prepare: understand the electronics category template — TracePass models 167 fields for the EEE/electronics category against the ESPR framework and EPREL — so you know what data will eventually be needed and where it sits in your supply chain. Monitor the Commission's ESPR working plan updates for any advancement of the EEE delegated act. And, if your lamp contains an in-scope battery, address the Battery Regulation passport obligation now, as that date — 18 February 2027 — is fixed. ## FAQ ### Do lamps need a Digital Product Passport under EU law? Not today. Lamps are EEE under ESPR (Regulation (EU) 2024/1781), but ESPR itself sets no DPP requirements — obligations are created only by product-specific delegated acts under Article 4. No such delegated act has been adopted for lamps or electronics, so no lamp DPP is legally mandatory at this time. ### When will the lamp / electronics DPP become mandatory? There is no confirmed date. The ESPR working plan indicates electronics/EEE as a priority around 2029, but that is an indicative estimate in a planning document, not a legal deadline. The mandatory date is set by the delegated act itself, which has not yet been formally proposed or adopted. ### Does the battery in a rechargeable lamp need a DPP? It depends on the battery's category and capacity. The EU Battery Regulation (2023/1542) requires a digital battery passport from 18 February 2027 for EV batteries, industrial batteries above 2 kWh, and LMT batteries above 25 V or 250 W. Most consumer lamp batteries are small lithium cells below the industrial threshold, so typically outside this obligation — but verify for your specific product. ### Should I start preparing a lamp DPP now? There is no legal requirement to act today. Practical preparation means understanding the electronics category template and the data it will require from your supply chain, monitoring the ESPR working plan for the EEE delegated act, and — if applicable — addressing the Battery Regulation passport requirement for any in-scope battery, which does have a firm deadline of 18 February 2027. --- --- title: "Battery Regulation: Three Distinct Documentation Obligations" description: Art. 13 labelling, Annex VIII technical docs, and the Art. 77 passport are three distinct obligations under EU Reg 2023/1542, with staggered dates. canonical: "https://www.tracepass.eu/resources/battery-regulation-accompanying-documentation" locale: en source: "https://www.tracepass.eu/resources/battery-regulation-accompanying-documentation" --- # Battery Regulation: Three Distinct Documentation Obligations > Art. 13 labelling, Annex VIII technical docs, and the Art. 77 passport are three distinct obligations under EU Reg 2023/1542, with staggered dates. When someone searches for what battery information must go in the accompanying or technical documentation, they are usually looking for one rule — one checklist. There isn't one. EU Battery Regulation (2023/1542) imposes three legally distinct obligations: Article 13 labelling and marking on or with the battery, Annex VIII technical documentation for conformity assessment, and the Article 77 digital battery passport. Each has its own legal basis, its own content scope, and its own application date. Conflating them leads to real compliance errors. This post disentangles all three. ## What must be labelled on a battery — and from when? Article 13 of Regulation (EU) 2023/1542 governs labelling and marking. It covers what is physically on or with the battery — not documentation stored elsewhere. The requirements are staggered across four dates depending on the marking type. The separate-collection symbol — the crossed-out wheeled bin from Annex VI Part B — is required under Article 13(4) from 18 August 2025. This is the earliest marking obligation and is already in force. The general information label (Annex VI Part A), the capacity label, and the non-rechargeable duration and 'non-rechargeable' indication under Article 13(1)–(3) apply from 18 August 2026 — or 18 months after the Article 13(10) harmonised-labelling implementing act enters into force, whichever is later. Because the implementing act has not yet been adopted, this date may slip beyond 18 August 2026. Batteries containing more than 0.002% cadmium must carry the chemical symbol 'Cd', and those with more than 0.004% lead must carry 'Pb'. Both are required under Article 13(5), printed beneath the separate-collection symbol at no less than one-quarter of its size. The QR code under Article 13(6) and Annex VI Part C applies from 18 February 2027 — a single uniform date for all battery types. What the QR code resolves to differs by battery type: for LMT, industrial batteries above 2 kWh, and EV batteries it gives access to the Article 77 passport; for other batteries it links to the Article 13(1)–(5) information, the EU declaration of conformity, and the relevant waste-management information. The CE marking is a separate matter governed by Articles 19–20, not Article 13. ## What goes in the technical documentation (Annex VIII)? Annex VIII defines 'Conformity Assessment Procedures — Module A (Internal Production Control).' It is the closest equivalent to what a German query about Begleitdokumentation or technische Dokumentation is looking for. This is the pre-market technical file the manufacturer must compile before placing a battery on the EU market. The technical documentation must make it possible to assess the battery's conformity with Articles 6, 9, 10, 12, 13, and 14 of the regulation. It must include: an adequate analysis and assessment of the risks, a general description of the battery and its intended use, and a specimen of the Article 13 label. This is a precondition for CE marking and for placing the battery on the market — an ongoing conformity obligation that predates any passport requirement. Critically, the Annex VIII technical documentation is not the same as the battery passport and does not replace it. It is the manufacturer's internal conformity file — held and made available to authorities on request. The passport is a separate, externally accessible data record. ## Is the accompanying documentation the same as the battery passport? No. They overlap because the Art. 13 labelling and the Art. 77 passport are both reached via the same QR code — but the technical documentation (Annex VIII) is a separate conformity file that is not on the QR at all. All three are distinct obligations. - Article 13 labelling and marking — physical marks on or with the battery (separate-collection symbol, capacity, QR code, Cd/Pb chemical symbols). An obligation for manufacturers. Staggered from 18 August 2025. - Annex VIII technical documentation — the manufacturer's internal conformity file, including a description of the battery and a specimen of the Art. 13 label. Held by the manufacturer, shown to authorities on request. A pre-market obligation that applies before the passport. - Article 77 + Annex XIII digital battery passport — a structured, externally accessible data record for LMT, industrial >2 kWh, and EV batteries, accessed through the Art. 13(6) QR code. Mandatory from 18 February 2027. ## When does each requirement apply? The table below maps the three obligations to their legal basis and application dates. Where a date depends on a secondary act that has not yet been adopted, that conditionality is stated explicitly. EU Battery Regulation 2023/1542 — three obligations and their application dates | Obligation | Legal basis | Application date | | --- | --- | --- | | Separate-collection symbol (crossed-out wheeled bin) | Art. 13(4), Annex VI Part B | 18 August 2025 | | General info label + capacity label + non-rechargeable indication | Art. 13(1)–(3), Annex VI Part A | 18 August 2026, or 18 months after the Art. 13(10) implementing act (whichever is later) | | Hazardous-substance symbols: >0.002% Cd → 'Cd'; >0.004% Pb → 'Pb' | Art. 13(5) | Printed beneath the separate-collection symbol (Art. 13(5)) | | QR code (Annex VI Part C) — links to Art. 77 passport for LMT/industrial >2 kWh/EV; links to Art. 13 info + DoC + waste info for other batteries | Art. 13(6), Annex VI Part C | 18 February 2027 (uniform date, all battery types) | | Technical documentation (general description, risk analysis, Art. 13 label specimen) | Annex VIII, Module A | Pre-market obligation — required before placing the battery on the EU market | | Digital battery passport (LMT, industrial >2 kWh, EV batteries only) | Art. 77 + Annex XIII | 18 February 2027 | ## A note on the 2026 corrigendum Corrigendum CELEX 32023R1542R(13), published in OJ L 2026/90285 on 10 April 2026, corrected Annex XIII point 1(q) — the passport's marking cross-reference — from 'Article 13(3) and (4)' to 'Article 13(4) and (5)'. This aligns the passport's marking field with the correct paragraphs: Article 13(4) governs the separate-collection symbol, and Article 13(5) governs the Cd/Pb chemical symbols. If your technical file or passport template cross-references the marking requirements, the correct citation after 10 April 2026 is Article 13(4) and (5), not 13(3) and (4). ## How TracePass helps with the passport and QR obligations TracePass builds the Article 77 digital battery passport and generates the GS1 Digital Link QR code that Art. 13(6) requires. The Article 13 physical labelling — the marks that go on the battery itself — and the Annex VIII technical documentation are the operator's separate obligations, which this post has described. [View a live battery Digital Product Passport example](https://app.tracepass.eu/p/01/99999999999997/21/6B27A0000001) ## FAQ ### What battery information must be in the technical documentation under EU Regulation 2023/1542? Annex VIII (Module A — Internal Production Control) requires the manufacturer's technical documentation to allow conformity assessment against Articles 6, 9, 10, 12, 13, and 14. It must include an adequate risk analysis, a general description of the battery and its intended use, and a specimen of the Article 13 label. This is a pre-market obligation — not the same as the digital battery passport. ### What must be labelled on a battery under Article 13 of the EU Battery Regulation? Article 13 requires: the separate-collection symbol (crossed-out wheeled bin, Annex VI Part B) from 18 August 2025; the general information label, capacity label, and non-rechargeable indication from 18 August 2026 or 18 months after the Art. 13(10) implementing act (whichever is later); Cd/Pb chemical symbols if thresholds are exceeded; and a QR code (Annex VI Part C) from 18 February 2027. The CE marking is governed separately by Articles 19–20. ### Is the Annex VIII technical documentation the same as the Art. 77 digital battery passport? No. The Annex VIII technical documentation is the manufacturer's internal conformity file held for inspection by authorities. The Article 77 digital battery passport is a separate, externally accessible structured data record for LMT, industrial batteries above 2 kWh, and EV batteries, accessible through the Art. 13(6) QR code from 18 February 2027. ### When does the QR code obligation apply, and does it differ by battery type? The QR code under Article 13(6) applies from 18 February 2027 for all battery types — one uniform date. What the QR code resolves to differs: for LMT, industrial batteries above 2 kWh, and EV batteries it gives access to the Art. 77 digital passport; for other batteries it links to the Art. 13(1)–(5) labelling information, the EU declaration of conformity, and the relevant waste-management information. --- --- title: EU DPP regulations, tracked article-by-article description: "How TracePass tracks the EU rules behind the Digital Product Passport: Battery Regulation article-by-article, ESPR delegated acts, CSRD, and a schema changelog." canonical: "https://www.tracepass.eu/regulatory" locale: en source: "https://www.tracepass.eu/regulatory" --- # EU DPP regulations, tracked article-by-article > How TracePass tracks the EU rules behind the Digital Product Passport: Battery Regulation article-by-article, ESPR delegated acts, CSRD, and a schema changelog. The Digital Product Passport isn't one regulation — it's a stack of them, each landing on a different timeline. These pages show exactly how TracePass reads each one and what it means for the data you'll need to publish. We track the legal text article-by-article rather than summarising it, so you can trace any field in a passport back to the requirement that put it there. TracePass tracks 8 regulatory surfaces behind the DPP — the Battery Regulation, ESPR delegated acts, the CSRD boundary, and a schema changelog. ## Regulations we track - [Battery Regulation 2023/1542](https://www.tracepass.eu/regulatory/battery-articles.md): Per-article coverage of EU Battery Regulation 2023/1542: Article 6 carbon footprint, Article 7 recycled content, Article 11 removability, Article 77 DPP. - [ESPR delegated acts](https://www.tracepass.eu/regulatory/delegated-acts.md): ESPR delegated act coverage — iron & steel, tyres, electronics, detergents, furniture, jewellery: companion regulations, indicative dates, status. - [Regulatory changelog](https://www.tracepass.eu/regulatory/changelog.md): EU DPP regulatory events with schema responses: ESPR 2024/1781, Battery Regulation 2023/1542, implementing acts, per-category templates. Reverse-chronological. - [DPP and CSRD — where the product passport ends and reporting begins](https://www.tracepass.eu/regulatory/csrd.md): TracePass is the product-level DPP and evidence layer that feeds your CSRD/ESRS reporting — it does not produce the report. Here's where the two meet. - [The EU DPP Registry — who submits, and what it actually checks](https://www.tracepass.eu/regulatory/registry.md): The EU DPP Registry is live but accepts no battery passports yet. Registration is the economic operator's duty, not the vendor's. Here is what that means. - [Standards are not law — what actually makes a DPP field mandatory](https://www.tracepass.eu/regulatory/standards-are-not-law.md): An EN standard, a certification scheme or a non-EU convention does not make a passport field mandatory. Here is the test — and the 46 fields we got wrong. - [Holding the data is not compliance — where a DPP duty is actually discharged](https://www.tracepass.eu/regulatory/holding-data-is-not-compliance.md): A field can be required by EU law while the passport is the wrong place to satisfy it. Labels, databases and held documentation each have their own legal form. - [The back-up copy obligation — a real ESPR duty with no provider to satisfy it](https://www.tracepass.eu/regulatory/backup-copy-obligation.md): ESPR Article 10(4) requires a back-up copy of every DPP with a service provider. The delegated act defining that role has not been adopted. What to do now. ## Related - [Field-by-field DPP guides by category](https://www.tracepass.eu/guides) ## Frequently asked questions ### Is TracePass a legal or compliance advisory service? No. These pages explain how our passport schema maps to the regulations, not legal advice. TracePass is software that helps you build and publish a Digital Product Passport; the positioning is "AI suggests, human approves". ### Does TracePass do CSRD or ESRS reporting? No. CSRD/ESRS is a separate corporate-reporting regime. The DPP can feed data into it, but TracePass is not a CSRD reporting tool — the CSRD page explains where the product passport ends and reporting begins. ### How often is the regulatory tracking updated? Each page carries its own last-reviewed date, and the changelog records how the TracePass schema responded to each regulatory change as the EU's implementing and delegated acts are published. ### When does the DPP become mandatory? It phases in by regulation. The EU battery passport is first, mandatory from February 2027. Other categories follow under ESPR (Regulation 2024/1781) through roughly 2027–2030 as each delegated act is adopted. Packaging has its own timeline under the PPWR (2025/40). ### What's the difference between ESPR and the Battery Regulation? The Battery Regulation (2023/1542) is a standalone law that mandates the battery passport directly. ESPR (2024/1781) is the framework regulation under which most other categories get a DPP, one delegated act at a time. The battery passport is furthest along; ESPR categories follow. Maintained by the TracePass team · Last reviewed 19 June 2026 --- --- title: Battery Regulation 2023/1542 — article-by-article coverage description: "Per-article coverage of EU Battery Regulation 2023/1542: Article 6 carbon footprint, Article 7 recycled content, Article 11 removability, Article 77 DPP." canonical: "https://www.tracepass.eu/regulatory/battery-articles" locale: en source: "https://www.tracepass.eu/regulatory/battery-articles" --- # Battery Regulation 2023/1542 — article-by-article coverage > Per-article coverage of EU Battery Regulation 2023/1542: Article 6 carbon footprint, Article 7 recycled content, Article 11 removability, Article 77 DPP. The EU Battery Regulation's digital battery passport becomes mandatory 18 February 2027 under Regulation (EU) 2023/1542, Annex XIII, Art. 77 — covering EV, industrial batteries above 2 kWh, and LMT batteries. This page maps Articles 6, 7, 11, 14, and 77 to the TracePass fields that satisfy each requirement, showing the coverage status where an implementing act is still refining the detail. Regulation (EU) 2023/1542 of the European Parliament and of the Council concerning batteries and waste batteries | Article | Title | Summary | Requirement | | --- | --- | --- | --- | | Art. 6 | Carbon footprint | Tell buyers how much CO₂ your battery's whole life puts in the air, broken down by stage, with a link to your study and a class rating. | Carbon footprint declaration for electric-vehicle, light-means-of-transport (LMT), and rechargeable industrial batteries above 2 kWh: total CF and per-lifecycle-stage breakdown, plus a study URL and a performance class. | | Art. 7 | Recycled content | Say what share of the cobalt, lithium, nickel, and lead in your battery came from recycling, and back it up with proof. | Declared recycled content for cobalt, lithium, nickel, and lead in industrial, EV, and SLI batteries — supported by documentation that the recycled fraction is verifiable. | | Art. 11 | Removability and replaceability | Users must be able to take the battery out and swap it themselves. Document how to remove it, what spare parts are available, and how to handle it safely at end of life. | Portable batteries shall be readily removable and replaceable by end-users — with documentation on removal procedure, dismantling, available spare parts, and end-of-life safety. | | Art. 14 | State of health and lifetime | Track how the battery is aging — health, remaining capacity, how it's been charged, what temperatures it's seen — and make that data available to the right people for the battery's entire life. | For industrial batteries above 2 kWh and EV batteries: state-of-health, remaining capacity, fade values, charging history, and historical thermal conditions — accessible to authorised parties throughout the battery's life. | | Art. 77 | Battery Passport | Every battery you sell in the EU needs its own digital passport behind a QR code, with a unique ID, who made it, when and where, what type it is, and where it is in its life. | Each LMT, industrial (>2 kWh), and EV battery placed on the EU market shall have a unique digital passport accessible via QR code, containing identifier, manufacturer details, manufacturing date and place, battery category, and lifecycle status. | --- --- title: Article 77 Battery Passport — EU Regulation 2023/1542 description: "What EU Battery Regulation 2023/1542 Article 77 requires: the mandatory digital battery passport from 18 Feb 2027 — who complies, Annex XIII data, QR access." canonical: "https://www.tracepass.eu/regulatory/battery-articles/article-77" locale: en source: "https://www.tracepass.eu/regulatory/battery-articles/article-77" --- # Article 77 Battery Passport — EU Regulation 2023/1542 > What EU Battery Regulation 2023/1542 Article 77 requires: the mandatory digital battery passport from 18 Feb 2027 — who complies, Annex XIII data, QR access. Article 77 of the EU Battery Regulation makes a digital battery passport mandatory from 18 February 2027. This page sets out exactly what Article 77 requires — who must comply, what data the passport must carry, how it is accessed, and the binding date — and how the TracePass schema maps to it. Article 77, Regulation (EU) 2023/1542 of the European Parliament and of the Council concerning batteries and waste batteries ## What Article 77 requires Article 77 requires that every battery in scope carries a digital product passport — a structured electronic record of the battery's identity, composition, carbon footprint, performance, supply-chain due diligence and end-of-life information. The passport is reached through a data carrier (a QR code) on the battery, which resolves to the passport via a unique identifier assigned at item level. The obligation becomes binding on 18 February 2027. From that date a battery placed on the EU market without a conforming passport is non-compliant, which can mean denied market access, fines set by each Member State, and recalls. ## Who must comply The duty falls on the economic operator that places the battery on the EU market or puts it into service — typically the manufacturer, or the importer when the cells or pack are made outside the EU. That operator assigns the unique identifier and is responsible for the passport's content and availability. Importers carry the same obligation as manufacturers: if you import a battery into the EU, the passport is your responsibility even when the overseas maker never produced one. This is the most common compliance gap — and the case TracePass is built for: assemble a conforming passport from the supplier's technical documentation, and request the data only the supplier holds through a token-based supplier portal. ## What data the passport must carry (Annex XIII) Annex XIII is the data specification. It covers battery identity, materials and chemical composition (including critical raw materials and substances of concern), the carbon footprint, performance and durability, supply-chain due diligence, recycled content, and end-of-life handling. Some data points are public; others are restricted to authorities or to operators with a legitimate interest, such as repairers and recyclers. Not every field applies to every battery. Applicability is conditional: an EV battery carries the full set, while a light-means-of-transport (LMT) or industrial battery legitimately leaves some points empty where a provision does not apply. The TracePass battery template models the full Annex XIII structure across the mandatory fields and tracks each field's access level, so the passport exposes the right data to the right audience. ## How the passport is accessed The passport is reached by scanning the QR code on the battery, which encodes a unique identifier in the GS1 Digital Link form and resolves to the passport. Storage is decentralised: the full passport data stays with the economic operator (or an authorised service provider), while a central EU DPP Registry — operational from July 2026 — holds only the unique identifiers and the access-control metadata, and interconnects with market-surveillance systems so authorities can reach restricted data. Article 77(3) sets the data-carrier and unique-identifier standards; these are being updated by delegated act, with current standards remaining valid as equivalents in the interim. TracePass serves each passport at a GS1 Digital Link URL with content negotiation — a human-readable page for browsers, JSON-LD for crawlers and authority systems — and applies the public / restricted / authority access tiers per field. ## Getting Article 77-ready with TracePass TracePass turns a cell or pack datasheet into a conforming Annex XIII passport: upload the technical documentation, the AI suggests values for all mandatory fields with confidence scores, and a reviewer approves them — AI suggests, a human approves, nothing is auto-published. Data only the supplier holds (origin of critical raw materials, due-diligence attestations) is requested through a token-based supplier portal, with reminders, and written back into the passport. On publish, each battery gets a GS1 QR code resolving to its passport at the right access tier, ready for the 18 February 2027 deadline. The full per-article mapping for the rest of the regulation is on the article-by-article coverage page. ## FAQ ### When does the Article 77 battery passport become mandatory? 18 February 2027. From that date every battery in scope placed on the EU market must carry a conforming digital passport. ### Who is responsible for the battery passport — the manufacturer or the importer? The economic operator placing the battery on the EU market. For batteries made outside the EU that is the importer, who carries the same obligation as a manufacturer even if the overseas maker never produced a passport. ### What data must the Article 77 passport contain? The data points in Annex XIII: battery identity, materials and chemical composition, carbon footprint, performance and durability, supply-chain due diligence, recycled content and end-of-life information — at public, restricted or authority access levels. Applicability is conditional on the battery category. --- --- title: ESPR delegated acts — per-category coverage description: "ESPR delegated act coverage — iron & steel, tyres, electronics, detergents, furniture, jewellery: companion regulations, indicative dates, status." canonical: "https://www.tracepass.eu/regulatory/delegated-acts" locale: en source: "https://www.tracepass.eu/regulatory/delegated-acts" --- # ESPR delegated acts — per-category coverage > ESPR delegated act coverage — iron & steel, tyres, electronics, detergents, furniture, jewellery: companion regulations, indicative dates, status. ESPR itself sets no Digital Product Passport requirement — each product category's obligation arrives only through its own delegated act under Regulation (EU) 2024/1781, and most delegated acts are still in preparation. This page shows what TracePass models today, per category: anchored against companion regulations where they exist (REACH, CLP, Tyre Labelling, Ecodesign, EPREL), and explicitly speculative where no Commission draft is yet published. Regulation (EU) 2024/1781 of the European Parliament and of the Council establishing a framework for the setting of ecodesign requirements for sustainable products (ESPR) | Category | Companion regulations | Fields | Effective | Mandatory | | --- | --- | --- | --- | --- | | Iron & Steel | CBAM Regulation (EU) 2023/956, EN 10204 (inspection certificates), ResponsibleSteel Standard | 84 | ~2026-Q4 | ~2028 | | Tyres | EU Tyre Labelling Regulation (EU) 2020/740, ECE Regulation 117 | 95 | ~2028 | ~2029 | | Electronics | Ecodesign Directive 2009/125/EC + delegated regulations, EPREL, RoHS, WEEE, RED, RFE | 167 | ~2028 | ~2029 | | Detergents | REACH (EC) 1907/2006, CLP (EC) 1272/2008, BPR (EU) 528/2012, SDS Regulation (EU) 2020/878 | 87 | 2029-09-23 | 2029-09-23 | | Furniture | EN 1335 (office), EN 16139 (contract), EN 71-3 (children), FSC Chain of Custody | 79 | ~2029 | ~2030 | | Jewellery | Responsible Jewellery Council (RJC) Code of Practices, OECD Due Diligence Guidance, Kimberley Process | 53 | ~2030 | ~2030 | ## ESPR delegated acts — common questions ### What is the timeline for the ESPR delegated acts? The Ecodesign for Sustainable Products Regulation (ESPR — Regulation (EU) 2024/1781) entered into force in 2024, but it sets no Digital Product Passport requirements by itself. Each product category gets its own delegated act, adopted on the schedule in the Commission's ESPR working plan. The first working plan (2025–2030) prioritises textiles, iron & steel, furniture, tyres, and a set of others; most category delegated acts are still in preparation, so concrete DPP obligations arrive category by category rather than all at once. ### What does the first ESPR working plan cover? The Commission's first ESPR working plan — COM(2025) 187 final (CELEX 52025DC0187), adopted 16 April 2025 — is a Communication that sets the order in which product groups are tackled. It does not bind anything; it is the source of the indicative timelines below. Iron & steel and textiles are early priorities (steel delegated act expected around Q4 2026, mandatory DPP from 2028 — indicative until the act is formally adopted), followed by furniture, tyres, aluminium, and others through 2028–2030. The working plan tells you when a category's delegated act is expected, not the final field list, which the delegated act itself will define. ### When do ESPR delegated acts make a Digital Product Passport mandatory? It depends entirely on the category. The battery passport is mandatory from 18 February 2027 under the EU Battery Regulation (2023/1542), not ESPR. Under ESPR, iron & steel is expected to require a DPP from around 2028 (indicative — no delegated act adopted yet); textiles, aluminium and tyres follow through 2029; toys around 2030. Each date is fixed by that category's delegated act, so the only safe answer is per-category — which is exactly what the matrix above tracks. ### Is there a confirmed date for the steel DPP? The iron & steel delegated act under ESPR is expected around Q4 2026, with the Digital Product Passport becoming mandatory from 2028. Steel also overlaps CBAM reporting, so the data substrate is partly already being collected. Treat the 2028 date as the current best estimate from the ESPR working plan until the delegated act is formally adopted. --- --- title: Regulatory changelog — what we tracked, what we changed description: "EU DPP regulatory events with schema responses: ESPR 2024/1781, Battery Regulation 2023/1542, implementing acts, per-category templates. Reverse-chronological." canonical: "https://www.tracepass.eu/regulatory/changelog" locale: en source: "https://www.tracepass.eu/regulatory/changelog" --- # Regulatory changelog — what we tracked, what we changed > EU DPP regulatory events with schema responses: ESPR 2024/1781, Battery Regulation 2023/1542, implementing acts, per-category templates. Reverse-chronological. Every regulatory event we track that touches a Digital Product Passport schema, paired with the action we took (or deliberately didn't take). The companion to the matrix pages — those show what we model today; this shows how we got here. ## 27 May 2026 — Commission battery-passport webinar — official timeline, corrigendum 2026/90285, EN 18219/18220, Omnibus IV DG GROW's 27 May 2026 webinar set out the official DPP implementation timeline: DPP Registry operational July 2026, battery passport mandatory 18 February 2027, then ESPR delegated acts for iron & steel (Q4 2026), textiles/aluminium/tyres (2027), and DPP mandatory for packaging/iron & steel/construction (2028), ICT/tyres/aluminium/textiles/detergents (2029) and toys (2030). Three discrete legal changes to track: corrigendum 2026/90285 (10 Apr 2026) corrects Battery Reg Annex XIII point 1(q) marking reference from Article 13(3)+(4) to 13(4)+(5); the QR/unique-identifier standards move to EN 18219 + EN 18220 via delegated act this year (current standards stay valid as equivalent); and Omnibus IV adds Annex XIII point (t), printable instructions for stationary battery energy storage systems. **Impact:** No schema change today. The corrigendum's marking reference (13(4)+(5)) and the EN 18219/18220 carrier-standard move are tracked against the battery template; we update field references when the delegated acts land. Timeline confirms our 18 Feb 2027 battery focus and dates the later category templates. ## 30 April 2026 — Enum localisation across all templates (24 EU locales) Machine-readable enum values across all 12 product-category templates now carry localised labels in 24 EU languages. The display layer resolves the consumer's locale to the right label; the underlying enum keys are unchanged so passports created before this change continue to validate. **Impact:** No schema-key change. Label additions only. No migration required for in-flight passports. ## 15 April 2026 — Per-category templates v1 — jewellery, chemicals, furniture, tyres, electronics Five new templates published (jewellery 52 fields, chemicals 96, furniture 80, tyres 95, electronics 166). Each is speculative-but-anchored against companion regulations: REACH + CLP for chemicals, Tyre Labelling 2020/740 for tyres, Ecodesign + EPREL for electronics, EN durability standards + FSC for furniture, RJC + OECD + Kimberley for jewellery. **Impact:** Net new templates. Existing battery and textile templates unchanged. Schema-bump per template version. ## Q4 2024 — Battery carbon-footprint methodology — implementing-act drafts in flight The Joint Research Centre and the European Commission continue to refine the carbon-footprint calculation rules and performance-class boundaries that implement Article 6 of Regulation (EU) 2023/1542. The final implementing act will lock the methodology used to declare values for electric-vehicle, light-means-of-transport (LMT), and rechargeable industrial batteries above 2 kWh. **Impact:** Pending review. The battery template's CF fields are already in place; values declared against an older methodology stay valid until the customer republishes. We expect to bump the schema only if new fields are introduced — not for value-recalculation only. ## 18 July 2024 — ESPR (EU) 2024/1781 entered into force The Ecodesign for Sustainable Products Regulation (ESPR) entered into force, establishing the framework for ecodesign requirements across product categories. The regulation does not create per-category obligations directly — those will come through delegated acts on per-category timelines, which TracePass tracks separately. **Impact:** Monitoring. Templates v1 followed in April 2026 — speculative-but-anchored coverage for the five categories most likely to receive early delegated acts. ## 17 August 2023 — Battery Regulation (EU) 2023/1542 entered into force The foundational regulation for the EU Battery Passport. Articles 6, 7, 11, 14, and 77 establish the core data points for industrial, electric-vehicle, light-means-of-transport, and SLI batteries. The Battery Passport itself becomes mandatory on 18 February 2027 under Article 77. **Impact:** Battery template created in response. The article-by-article coverage is documented separately on the Battery Reg matrix page. --- --- title: DPP and CSRD — where the product passport ends and reporting begins description: "TracePass is the product-level DPP and evidence layer that feeds your CSRD/ESRS reporting — it does not produce the report. Here's where the two meet." canonical: "https://www.tracepass.eu/regulatory/csrd" locale: en source: "https://www.tracepass.eu/regulatory/csrd" --- # DPP and CSRD — where the product passport ends and reporting begins > TracePass is the product-level DPP and evidence layer that feeds your CSRD/ESRS reporting — it does not produce the report. Here's where the two meet. Digital Product Passports and CSRD/ESRS sustainability reporting are different obligations at different levels. TracePass owns the product level and feeds the reporting level — it is not a CSRD reporting tool, and this page says exactly where the line is. Some DPP vendors pitch a single "data foundation" that does both your Digital Product Passports and your CSRD report. It sounds efficient. In practice the two live at different levels: a DPP is per-product (one passport per battery, per garment, per appliance), while CSRD/ESRS reporting is per-company (one consolidated sustainability statement covering the whole entity). Bolting them into one tool usually means one of the two is shallow. TracePass is deliberately the product level done well. We don't write your CSRD report or compute your ESRS datapoints — but the product data we already capture for passports is exactly the granular evidence a serious ESRS process needs underneath the company-level numbers. So rather than replace your reporting tool, we feed it. ## What TracePass feeds into your CSRD/ESRS process Every passport already structures product-level data that maps onto ESRS datapoints. You export it as JSON-LD or EPCIS 2.0 and hand it to your reporting tool or auditor — product-level evidence, not a finished disclosure. | ESRS | What TracePass feeds into your CSRD/ESRS process | | --- | --- | | ESRS E1 (climate) | Per-product carbon footprint / PEF results attached to each passport, with the source study linked — the granular input behind a company-level GHG figure. | | ESRS E5 (resource use & circular economy) | Recycled-content percentages, recyclability and end-of-life data per product, with source attribution — exactly the circularity evidence ESRS E5 asks you to substantiate. | | Supply-chain provenance | Critical-raw-material and due-diligence records captured per passport, exportable as EPCIS 2.0 events for the value-chain narrative. | | Auditable evidence trail | Every field carries who entered it, when, and from which source document — the audit trail an assurance provider expects under CSRD limited assurance. | ## What TracePass does NOT do - We do not produce a CSRD sustainability statement or fill the ESRS disclosure templates. That's your reporting tool's or consultant's job; we supply the product-level inputs. - We do not perform company-level consolidation, double-materiality assessment, or ESRS gap analysis. - We do not replace a carbon-accounting / ESG platform. If you have one, we feed it; if you don't, you still need one for the company-level report. - We will not call ourselves "CSRD-ready" or "CSRD-compliant" — a product-data layer cannot be either. Anyone claiming a single tool does both DPP and CSRD fully is overselling one of them. --- --- title: The EU DPP Registry — who submits, and what it actually checks description: "The EU DPP Registry is live but accepts no battery passports yet. Registration is the economic operator's duty, not the vendor's. Here is what that means." canonical: "https://www.tracepass.eu/regulatory/registry" locale: en source: "https://www.tracepass.eu/regulatory/registry" --- # The EU DPP Registry — who submits, and what it actually checks > The EU DPP Registry is live but accepts no battery passports yet. Registration is the economic operator's duty, not the vendor's. Here is what that means. Publishing a passport and registering it are two different acts, and only one of them is your software vendor's job. This page explains what the registry does, who owes the submission, and why nobody can complete it for batteries yet. The EU Digital Product Passport Registry is a central index, not a database of passports. It stores a unique product identifier, minimal metadata, and a pointer to wherever the passport data is actually hosted. It does not store the passport itself, and it deliberately does not judge whether the passport is correct. That distinction matters more than it first appears. A registry that accepts your link has confirmed the link resolves — nothing about whether the data behind it satisfies the Battery Regulation. Those are two separate problems, and only one of them is solved by registering. ## What the registry accepts today We register test submissions in the Commission's acceptance environment to know this first-hand rather than from a guide. Here is what the mechanical gates do, and where the process currently stops. | What the registry accepts today | | | --- | --- | | Batteries is the only product group offered | Other groups follow the ESPR working plan. The registry's UI presents batteries and nothing else. | | The mechanical checks pass | Identifier format, the https requirement, the domain, and live resolvability of the link are all verified on submission — and a correctly built file clears them. | | Semantic validation is unavailable | The Commission has not defined the semantic catalogue for batteries, so the validator has no schema to check against and refuses rather than passing. No battery passport can complete registration today, from any provider. | | The registry stores no passport data | Only the identifier, minimal metadata, and the pointer. Your passport stays where it is hosted. | ## Whose duty registration is The obligation sits with the economic operator placing the product on the EU market — normally the manufacturer, the importer, or the operator selling directly to an EU end user. It does not sit with the software they use to build the passport. That operator may authorise another party in writing to act on its behalf, under Article 77 of the Battery Regulation. But the authorisation moves the work, not the responsibility: the operator remains fully liable for the accuracy of the data and remains its controller, whoever presses submit. This is why publishing a passport with TracePass does not register it, and why the platform says so on every published battery passport rather than letting the silence imply otherwise. ## What TracePass does today Everything up to the submission itself, so the step you owe is an upload rather than a data-assembly exercise. | What TracePass does today | | | --- | --- | | The upload file, in the registry's own format | Export a batch file for your published battery passports, shaped to match the registry's sample template. Available on every plan, including free. | | A resolvable identifier the registry accepts | Every passport carries a GS1 Digital Link that resolves over https. The link gate is the check most submissions fail; ours passes it in the Commission's own acceptance environment. | | A readiness check before you submit | The platform mirrors the registry's formal checks — mandatory fields present and approved, formats valid, the link live — so you find problems before the registry does. | | A compliance verdict the registry does not give | The registry checks that your link resolves. Whether the passport is actually correct under the Battery Regulation is a separate question, and the one we answer. | ## On the roadmap — submitting on your behalf Not built, and deliberately not sold as if it were. The regulation permits it two ways, and both wait on the Commission publishing the semantic catalogue — until then there is nothing to submit to. | On the roadmap — submitting on your behalf | | | --- | --- | | Under our own verified status | With your written authorisation, TracePass submits as a verified value chain actor and is named in the registration record as your service provider. You never touch the registry. | | Inside your registry account | You grant TracePass access rights in the registry and we operate within them. Lighter to set up; your account, your verified status, our hands. | --- --- title: Standards are not law — what actually makes a DPP field mandatory description: An EN standard, a certification scheme or a non-EU convention does not make a passport field mandatory. Here is the test — and the 46 fields we got wrong. canonical: "https://www.tracepass.eu/regulatory/standards-are-not-law" locale: en source: "https://www.tracepass.eu/regulatory/standards-are-not-law" --- # Standards are not law — what actually makes a DPP field mandatory > An EN standard, a certification scheme or a non-EU convention does not make a passport field mandatory. Here is the test — and the 46 fields we got wrong. A harmonised European standard supports a presumption of conformity. It binds nothing on its own. Here is the difference between a standard and a legal obligation — and what happened when we applied that test to our own product. We audited our own 12 category templates against a single question: for every field marked “required”, which EU instrument actually requires it? Of 307 required fields, 46 rested on authority that is not legislative — an EN standard, a certification scheme, a non-EU convention, or in three cases the phrase “Product specification”. We corrected all 46. Every remaining required field cites legislation. We are naming our own defect first because it is the most useful thing on this page. A compliance vendor that tells you a law exists when it does not is the worst failure mode in this category: you spend real effort chasing an obligation nobody can enforce, and you learn to distrust the fields that genuinely are mandatory. The rule underneath is simple. A field in a Digital Product Passport is legally mandatory only when two things hold at once: an EU instrument that is in force mandates the data, and the passport is how that duty is discharged. Both halves matter. Plenty of data is genuinely required by EU law but discharged by a physical label, a technical file held on request, or a database entry — not by publishing it in a passport. A harmonised standard sits outside that test entirely. Standards are drafted by CEN, CENELEC and ETSI, not by the legislator, and their legal effect is a presumption of conformity: follow the standard and an authority presumes you meet the essential requirement it was written against. That presumption is a shortcut, not a source of obligation. Unless a regulation names the standard and makes it mandatory, you may meet the requirement any other way you can demonstrate. ## Four things routinely mistaken for law Each of these is real, useful, and widely cited in DPP field specifications. None of them, by itself, makes a passport field legally mandatory. | Four things routinely mistaken for law | | | --- | --- | | EN standards | EN 15804+A2 defines the environmental indicators in an EPD. EN 10204 defines mill certificate types. EN 12520 sets furniture durability tests, EN 71 toy safety methods. All four are voluntary technical documents that support a presumption of conformity — they carry a legal obligation only where a regulation makes that specific standard mandatory. | | Certification schemes | FSC, PEFC, RJC and the EU Ecolabel are voluntary by construction — a producer chooses to be certified, and one who declines is not in breach of anything. The EU Ecolabel is the subtle case: it has a real CELEX number (32010R0066), so a citation to it looks legislative on the page. The regulation establishes a voluntary award scheme. Holding the label imposes duties; not holding it imposes none. | | Non-EU conventions | The Vienna Convention 1972 on the control and marking of articles of precious metals is a Council of Europe instrument. The EU is not a party to it, so it binds nothing at EU level. It also mandates the wrong artefact: a physical common control mark struck into the metal, not a value published in a passport. | | Type-approval regulations | UNECE R30 and R54 genuinely bind tyre manufacturers — but the duty is discharged by obtaining type approval and carrying the approval mark, with the supporting values held in the approval dossier. Nothing in either regulation requires publishing those values in a product passport. A real obligation, discharged somewhere other than here. | ## What our own audit found, and what we changed 307 fields across our 12 category templates were marked required. 46 rested on non-legislative authority. Nothing was deleted: a field demoted from required is still in the template, still collectable, still exported. It simply no longer claims a law behind it. | What our own audit found, and what we changed | | | --- | --- | | Construction — 15 fields | Every one traced to EN 15804+A2, the standard defining EPD indicators. Genuinely the right method for calculating embodied carbon, and worth collecting. Not a legal obligation to publish, so they are now optional with the standard named as the method rather than the mandate. | | Steel — 10 fields | Rested on EN 10204 (inspection document types), EN 10025 (structural steel product norms) and ISO 148-1 (Charpy impact test method). Test methods and document formats — the specification a mill certificate follows, not an EU instrument requiring that certificate in a passport. | | Tyres — 10 fields | Traced to UNECE R30 and R54, discharged by the approval mark and dossier rather than by publication. Three of the ten cited nothing more than “Product specification” — a description of where the number comes from, standing in a column reserved for legal authority. | | Furniture — 5 fields | Split between EN 12520 durability testing and FSC/PEFC chain-of-custody certification. One is a test method, the other a voluntary scheme. Neither is an EU instrument mandating passport content. | | Jewelry — 4 fields | Cited the Vienna Convention 1972 — an instrument the EU is not party to, mandating a physical hallmark rather than a passport entry. Two independent reasons the field could not be legally required here, stacked on top of each other. | | Toys — 1 field | Traced to EN 71, the harmonised toy safety standard. Conformity with EN 71 supports a presumption against the essential safety requirements; the standard itself compels nothing. | | Chemicals — 1 field | Cited “ESPR, SDS Section 7” — a section of a safety data sheet. An SDS is a real document with real duties behind it, but a section number is not a legal instrument, and the data it holds is supplied to recipients rather than published in a passport. | ## Why over-claiming is the worse error Both directions of error are real. Mark a field optional when the law requires it and a customer can end up non-compliant; that is the failure everyone in this market designs against, and rightly. But the two errors are not symmetric. Under-claiming risks non-compliance, and the cost lands on the customer at inspection. Over-claiming wastes a customer's effort chasing data nobody can compel, and it does something worse: it asserts a law that does not exist. Only one of these two errors involves inventing an obligation, and a vendor is uniquely well-placed to be believed when it does. What changes is what the word “required” is worth. If every field carries an equal-looking asterisk, the ones backed by an actual regulation with an actual deadline get no more attention than the ones backed by a trade body's scheme. Reserving the label for legislation is what makes it informative. ## How to check any field yourself This is not a proprietary method and there is nothing to buy to use it. Take any field marked required, in any passport product including ours, and run it through four questions. If a vendor cannot answer all four for a given field, that is the answer. | How to check any field yourself | | | --- | --- | | Does the citation name an EU instrument, or just a standard? | Look for a CELEX number — the identifier EUR-Lex assigns to every EU legal act, like 32023R1542 for the Battery Regulation. A standard number (EN 15804+A2, ISO 148-1, UNECE R30) is not one. If the authority column holds only a standard number, a scheme name, or a phrase like “product specification”, no legislation has been cited at all. | | Is that instrument actually in force for this product? | An instrument can be adopted, in force, and still impose nothing on your product yet, because the operative duty waits on a delegated act that has not been adopted. Check the date of application and whether the product group has been brought into scope, rather than reading the parent regulation's existence as a live obligation. | | Is the duty discharged by the passport, or somewhere else? | This catches the most false positives. Data can be genuinely mandatory and still not belong in a passport — because the obligation is met by a physical label or stamped mark, by technical documentation held and produced on request, by an entry in a Commission database such as EPREL or SCIP, or by an importer's declaration. Find the article that says where the information goes. | | For ESPR specifically, has a delegated act landed? | ESPR (EU) 2024/1781 Articles 7 and 9 impose no data fields on their own — they set out what a delegated act may require and how a passport must work. Every actual DPP obligation flows through a product-specific delegated act adopted under Article 4. The only adopted one is battery, under Regulation (EU) 2023/1542 Article 77, mandatory from 18 February 2027. A field justified by “ESPR requires it” with no delegated act behind it is not yet required by anything. | --- --- title: Holding the data is not compliance — where a DPP duty is actually discharged description: A field can be required by EU law while the passport is the wrong place to satisfy it. Labels, databases and held documentation each have their own legal form. canonical: "https://www.tracepass.eu/regulatory/holding-data-is-not-compliance" locale: en source: "https://www.tracepass.eu/regulatory/holding-data-is-not-compliance" --- # Holding the data is not compliance — where a DPP duty is actually discharged > A field can be required by EU law while the passport is the wrong place to satisfy it. Labels, databases and held documentation each have their own legal form. A field can be genuinely required by EU law and still not be satisfied by recording it in a passport. The obligation may live on a physical label, in a Commission database, or in a technical file you hold and produce on request. Here is how to tell which. Recording a datum in a Digital Product Passport often does not satisfy the law that mandates that datum. The two acts look identical from inside a compliance tool — the field is there, it has a value, the value is correct — and they are legally distinct. One is holding information. The other is discharging an obligation. The confusion is easy to fall into because most passport field specifications answer only the first half of the question. They tell you which EU instrument requires the data. They do not tell you which article says where that data has to go. A regulation that mandates fibre composition and a regulation that mandates fibre composition on a durable label attached to the product are not the same instruction, and only one of them is satisfied by a database entry. Four patterns account for almost every case where the duty lands somewhere other than the passport: a physical label or marking on the product itself, an on-request communication duty triggered by a threshold, an entry in a specific database, and documentation that must be drawn up, held, and produced to authorities when they ask. Each has its own legal form, and a passport entry does not take that form. None of this argues against putting the data in a passport. A passport is a good place to keep it — structured, versioned, shareable with a customer or an auditor without a document hunt, and already the working copy your team edits. The point is narrower and more useful than “don't bother”: know which act you have performed when you fill the field in, because for most of these duties you still owe a second one. ## Four ways an obligation lands somewhere other than the passport Each of these is a real, in-force EU obligation, and in each case the data is worth holding in a passport. In none of them does the passport entry discharge the duty. | Four ways an obligation lands somewhere other than the passport | | | --- | --- | | A physical label or marking on the product | Regulation (EU) 1007/2011 requires textile fibre composition on a durable, easily legible label physically attached to the product, in the language of the Member State where it is made available — Articles 9(1), 14(1) and 16 together. Recording the same composition in a passport does not discharge it; the garment still needs the label. The Battery Regulation works the same way for its markings: the separate-collection symbol under Article 13(4), in force since 18 August 2025 and covering at least 3% of the largest side; the general information and capacity labels under Article 13(1) to (3); and the chemical symbols for hazardous substances under Article 13(5) — “Cd” above 0.002% cadmium, “Pb” above 0.004% lead. Those go on the battery, not in a record about it. | | A communication duty owed on request | Under Article 33(1) of REACH, Regulation (EC) 1907/2006, a supplier of an article containing a Candidate List substance above 0.1% weight by weight must provide the recipient with sufficient information for safe use — as a minimum, the name of the substance. Read the shape of that duty carefully: it is triggered by a threshold and by a request, it is owed to a specific recipient, and its minimum content is a name. It is not a duty to publish proactively, and it is not a duty to publish CAS numbers or concentration ranges. A passport can be an excellent way to answer the request quickly. Answering is still the obligation. | | An entry in a specific database | For some obligations the database record is the duty. EPREL registration for energy labelling, SCIP notification to ECHA under Article 9(1)(i) of the Waste Framework Directive 2008/98/EC — in force since 5 January 2021 — poison-centre notifications under Annex VIII to CLP, and the EUDR due-diligence statement lodged in the EU Information System are all discharged by lodging the record with the named system. Publishing the same values in a passport does not create the entry and does not replace it. Nothing you do in your own system is visible to a register you have not submitted to. | | Documentation drawn up, held, and produced on request | Technical files, EU Declarations of Conformity and test reports carry a duty to draw up the document, keep it for the required period, and produce it to a market surveillance authority when asked. The Battery Regulation's Annex VIII technical documentation is a clear case: it belongs to Module A internal production control, a precondition for placing the product on the market and affixing the CE marking. It is not passport data. Publishing a URL where an inspector could find the document is a delivery choice, and often a good one — it is not the legal form of the duty, and it does not remove the obligation to hold the file. | ## The exception: batteries, where the law does name passport content Batteries are the one category where the general rule inverts. Annex XIII of Regulation (EU) 2023/1542 enumerates the data points as passport content — not as label text, not as technical documentation, but as what the battery passport must contain — and Article 77 makes that passport mandatory from 18 February 2027 for LMT batteries, industrial batteries above 2 kWh, and electric vehicle batteries. For those fields, filling the passport is the act the law asks for. That is also why the Battery Regulation is where the three obligations get conflated most often. It imposes three legally distinct things at once: the Article 13 markings that go on the battery itself, the Annex VIII technical documentation that supports conformity assessment, and the Article 77 passport described in Annex XIII. Only the third is passport data. The conflation is almost structural, because Article 77(3) makes the passport reachable through the QR code required by Article 13(6) from 18 February 2027 — the marking is the doorway to the passport, which makes them feel like one obligation. They are not. A compliant passport behind a missing or undersized label is still a labelling failure. So the honest general rule is: a passport entry rarely discharges the duty behind the data, with one important exception — and that exception is the only product category with an adopted DPP mandate today. As more delegated acts arrive, more categories may join it. Until one does for your product, assume the duty lives elsewhere and go find the article that says where. ## What to do about it None of this requires new software or a different way of working. It requires knowing, for each field you hold, which act discharges the obligation behind it — and keeping the passport honest about being the working copy rather than the legal one. | What to do about it | | | --- | --- | | Record where each duty is discharged, not just what the data is | For every field you treat as mandatory, note the article that says where the information has to go: on the product, to a named database, to a recipient on request, or in a file you hold. That one line turns a field list into a compliance map, and it is the note that survives staff turnover. It is also the answer an auditor is actually asking for when they ask why you collect something. | | Keep the label and the passport in sync deliberately | Where a duty is discharged by a physical label — fibre composition, battery markings, an approval mark — the label and the passport hold the same values from two different processes, and they drift. A composition change reaches the passport in an afternoon and the printed label at the next production run. Decide which one leads, and check the other against it before a batch ships, rather than discovering the gap at inspection. | | Treat the passport as the working copy, not the legal act | The passport is where the data is assembled, versioned and shared. The database submission, the label artwork, the technical file and the answer to a REACH Article 33 request are separate acts that draw on it. Holding the two apart in your own head is what stops a green dashboard from reading as a discharged obligation — and stops “the passport is complete” from being mistaken for “we are compliant”. | | Ask your vendor which article puts the data in the passport | Any tool that marks a field mandatory should be able to name the instrument requiring the data and the provision putting it in a passport. If the answer covers only the first half, the field is worth collecting and the mandatory label is doing something else — telling you an obligation exists, without telling you where to satisfy it. Ask this about our templates too; the answer should be specific enough to check on EUR-Lex. | --- --- title: The back-up copy obligation — a real ESPR duty with no provider to satisfy it description: ESPR Article 10(4) requires a back-up copy of every DPP with a service provider. The delegated act defining that role has not been adopted. What to do now. canonical: "https://www.tracepass.eu/regulatory/backup-copy-obligation" locale: en source: "https://www.tracepass.eu/regulatory/backup-copy-obligation" --- # The back-up copy obligation — a real ESPR duty with no provider to satisfy it > ESPR Article 10(4) requires a back-up copy of every DPP with a service provider. The delegated act defining that role has not been adopted. What to do now. ESPR Article 10(4) requires the economic operator to lodge a back-up copy of the digital product passport with a digital product passport service provider. The delegated act that defines and governs that role has not been adopted. Here is what the obligation actually says, and what you can do before it can be met. Regulation (EU) 2024/1781 — ESPR — contains an obligation most passport discussions never reach. Article 10(4) reads: “The economic operator, when placing the product on the market, shall make available a back-up copy of the digital product passport through a digital product passport service provider.” It is one sentence, it is unconditional in form, and it is not a duty an operator can discharge alone. The reason it matters is Article 11(e). The passport “shall remain available for the period specified in delegated acts adopted pursuant to Article 4, including after an insolvency, a liquidation or a cessation of activity in the Union of the economic operator responsible for the creation of the digital product passport.” Read those two provisions together and the intent is plain: a passport is supposed to outlive the company that created it. The back-up copy is the mechanism that makes that possible. The problem is that a “digital product passport service provider” is a defined role, not a description of any vendor holding your data. It is an independent third party, authorised by the economic operator, that processes passport data in order to make it available to the actors entitled to access it. The rules governing that role — who may act as one, what they must guarantee, how they are supervised — come from the DPP service provider delegated act. That act has not been adopted. So the honest position is that a real obligation exists, its counterparty does not yet exist, and no vendor — including us — can be a qualified back-up provider today, because the qualification has not been created. That is not a gap in one product. It is a gap in the field. This page sets out what the text says, why it cannot be satisfied yet, and the things worth doing in the meantime that will still be worth having when it can. ## What the regulation actually says Four provisions do the work. Three are quoted or paraphrased from the consolidated ESPR text; the fourth is the scope rule that determines when any of them bite. Read the scope item first if you are trying to work out whether this applies to your product today. | What the regulation actually says | | | --- | --- | | Article 10(4) — the back-up copy itself | The provision is one sentence: “The economic operator, when placing the product on the market, shall make available a back-up copy of the digital product passport through a digital product passport service provider.” Three things are worth noticing. The trigger is placing on the market, not some later date. The duty falls on the economic operator, so it cannot be delegated away by contract. And the copy must be made available through a service provider — a back-up you hold yourself, however robust, is not the form the article describes. That third element is the one that cannot currently be complied with, and it is not optional wording. | | Article 11(e) — survival beyond the company | The passport “shall remain available for the period specified in delegated acts adopted pursuant to Article 4, including after an insolvency, a liquidation or a cessation of activity in the Union of the economic operator responsible for the creation of the digital product passport.” This is the reason Article 10(4) exists. A passport hosted only by the manufacturer disappears with the manufacturer, and the products it describes do not — they are still in use, still being resold, still heading for a recycler who needs the data. Note also that the availability period itself is set by the Article 4 delegated act, so how long is a per-product-group question, not a single number. | | Article 11(c) — what a processor may not do with the data | Whoever stores or processes passport data “shall not sell, reuse or process such data, in whole or in part, beyond what is necessary for the provision of the relevant storing or processing services.” This is a useful clause to know even now, because it is the standard a back-up arrangement will eventually be measured against. It rules out treating the data you are entrusted with as a commercial asset in its own right — aggregating it, monetising it, or building an unrelated product on top of it. It is a reasonable question to put to any vendor holding your passport data today, delegated act or not. | | Scope — Article 10 bites where a passport is required at all | This nuance decides whether the duty is yours yet. Article 10 sets essential requirements for a digital product passport. Those requirements apply where Article 9(1) requires a passport in the first place — that is, once the product's own delegated act under Article 4 applies to it. The back-up duty is therefore not a free-standing obligation on every product on the market today; it attaches wherever a passport is mandatory. The only adopted mandate is battery, under Article 77 of Regulation (EU) 2023/1542, from 18 February 2027. That is the first date on which this becomes real for anyone. | ## Why nobody can satisfy this today The obstacle is not technical. Copying a passport to a second organisation is a solved engineering problem, and several vendors could do it this afternoon. The obstacle is that Article 10(4) does not ask for a copy held by another company — it asks for a copy made available through a digital product passport service provider, which is a role the regulation defines and the DPP service provider delegated act is meant to govern. That act has not been adopted. Public sources place it variously in Q1 and in Q2–Q3 of 2027; none of those is a legal date, so the sensible way to treat it is as a trigger to watch rather than a deadline to plan against. Because the act has not landed, there is no qualification to hold. DIGITALEUROPE has recommended a common, EU-wide certification scheme for back-up services by DPP providers as the way to fulfil Article 10(4) — but a recommendation is not a scheme, and no body is currently certifying anyone against it. Any vendor claiming today to be a qualified or certified back-up provider is claiming a status that does not exist. We are not one, we do not claim to satisfy Article 10(4), and the same test should be applied to anyone who says otherwise: name the scheme, name the body that granted it. There is also a live question about what the role will even be worth buying separately. DIGITALEUROPE has proposed allowing an economic operator to authorise a single provider for both primary and back-up services, and exempting operators who make passports available themselves from certification altogether. If either proposal is adopted, a standalone back-up vendor becomes a much narrower product than it looks today. Nothing here is decided — that is the point. Committing money or architecture to a market that has not been defined yet is the most expensive thing you can do in response to this article. ## What you can usefully do before the act lands None of the following satisfies Article 10(4), and none of it should be sold to you as if it does. What it does is put you in the position where satisfying the article later is a small step rather than a migration — and every item is worth having on its own merits even if the delegated act never arrives in the shape anyone expects. | What you can usefully do before the act lands | | | --- | --- | | Keep a complete, standards-shaped export you could take elsewhere | This is the honest interim answer to a back-up duty you cannot yet discharge: a full export of the passport, in a documented format, that another system could ingest without your current vendor's cooperation. Take it on a schedule, keep it somewhere you control, and confirm at least once that it actually loads somewhere else — an export nobody has ever restored is a hypothesis, not a back-up. Be clear with yourself about what it is. It is continuity insurance and it is portability. It is not a copy made available through a digital product passport service provider, and it should never be described as satisfying Article 10(4). | | Ask where the data would live if your vendor stopped trading tomorrow | Ask it plainly, and get the answer in writing rather than in a sales call. What happens to hosted passports on insolvency or wind-down? Is there an escrow arrangement, a notice period, a defined export window, or nothing at all? Who holds the data, in what jurisdiction, and under what commitment not to reuse it — the standard Article 11(c) sets out is a good yardstick to borrow early. A vendor with an honest answer that is “nothing formal yet” is more useful than one that answers with a certification nobody issues. | | Prefer formats and identifiers that survive a provider change | The thing that makes a back-up transferable is not the copy, it is the shape of the data inside it. A resolvable identifier you control, rather than one minted by and tied to a vendor's domain, means a passport keeps its address when the host changes. Standards-shaped, self-describing data means the receiving system can read it without a bespoke mapping. Proprietary stores and vendor-scoped identifiers are the two things that make a future migration expensive, and they are cheap to avoid at the point where you first choose them. | | Watch the DPP service provider delegated act, not the ESPR headlines | This is the trigger that turns a design question into a compliance one. Until it is adopted, there is no role to contract with and no scheme to be certified under, and the correct posture is readiness rather than procurement. When it lands, the things that matter are what a service provider must guarantee, whether one provider may serve both primary and back-up roles, and whether self-hosting operators are exempted. Those answers will determine whether you need to buy anything at all. Until then, treat any deadline you are quoted for this as an estimate, because nothing has been adopted. | --- --- title: The EU Digital Product Passport glossary description: Plain-language definitions of the EU Digital Product Passport terms that matter — ESPR, GS1 Digital Link, EPCIS, EPREL, SVHC, PEF and more. For people and AI. canonical: "https://www.tracepass.eu/glossary" locale: en source: "https://www.tracepass.eu/glossary" --- # The EU Digital Product Passport glossary > Plain-language definitions of the EU Digital Product Passport terms that matter — ESPR, GS1 Digital Link, EPCIS, EPREL, SVHC, PEF and more. For people and AI. Clear, citable definitions of the regulations, standards and concepts behind the EU Digital Product Passport — the ones you actually meet when you build one. ## Standards & specifications - [Data carrier](https://www.tracepass.eu/glossary/data-carrier): A data carrier is the physical, printed or attached link on a product — typically a QR code or NFC tag — that resolves to its Digital Product Passport when scanned. ESPR defines it as the standardised, openly readable way to connect a real product to its online passport. - [EPCIS 2.0](https://www.tracepass.eu/glossary/epcis): EPCIS 2.0 is the GS1 standard for capturing and sharing supply-chain event data — the what, when, where and why of every step a product takes. It lets a Digital Product Passport carry an interoperable, machine-readable record of lifecycle and traceability events instead of a static datasheet. - [GS1 Digital Link](https://www.tracepass.eu/glossary/gs1-digital-link): GS1 Digital Link is the GS1 standard that turns a product identifier (like a GTIN) into a web URL, so a single QR code can resolve to different content — a consumer page, a JSON-LD passport, a service endpoint — depending on who scans it. It is the data-carrier format the EU Digital Product Passport is built to use. - [JSON-LD](https://www.tracepass.eu/glossary/json-ld): JSON-LD (JSON for Linked Data) is a W3C standard that adds shared, web-resolvable meaning to ordinary JSON, so a machine knows that a field labelled "recycledContent" is the same concept everywhere. It is the format a Digital Product Passport is served in so that systems, search engines and AI agents can read it unambiguously. - [MCP (Model Context Protocol)](https://www.tracepass.eu/glossary/mcp): MCP (Model Context Protocol) is an open standard that lets AI assistants and agents securely call external tools and data sources through a uniform interface, instead of each integration being bespoke. TracePass ships an MCP server, so an AI agent can create, fill and publish Digital Product Passports directly. - [OpenAPI](https://www.tracepass.eu/glossary/openapi): OpenAPI is the industry-standard, machine-readable way to describe a REST API — its endpoints, parameters, request and response shapes and authentication — in one specification file. TracePass publishes an OpenAPI 3.1 spec so any tool or AI agent can discover and call the passport API without bespoke documentation. ## EU regulations - [CSRD / ESRS](https://www.tracepass.eu/glossary/csrd-esrs): CSRD is the EU Corporate Sustainability Reporting Directive; ESRS are the European Sustainability Reporting Standards that define what a company must report under it. Together they govern company-level sustainability reporting — distinct from the product-level Digital Product Passport. - [ESPR](https://www.tracepass.eu/glossary/espr): ESPR is the Ecodesign for Sustainable Products Regulation (EU) 2024/1781, in force since 18 July 2024. It is the umbrella law that makes the Digital Product Passport mandatory, rolling it out product group by product group through delegated acts expected across roughly 2027–2030. - [EU Battery Regulation](https://www.tracepass.eu/glossary/eu-battery-regulation): The EU Battery Regulation (EU) 2023/1542 governs the full life cycle of batteries placed on the EU market — from carbon footprint and recycled content to collection and recycling. It introduces the battery passport, which becomes mandatory on 18 February 2027 for LMT, industrial (>2 kWh) and electric-vehicle batteries. - [EUDR](https://www.tracepass.eu/glossary/eudr): EUDR is the EU Deforestation Regulation (EU) 2023/1115, which bars listed commodities — including wood, cattle, soy, coffee, cocoa, palm oil and rubber — and products made from them from the EU market unless they are deforestation-free and legal. Operators must run due diligence with geolocation coordinates for every plot of land of origin. - [PPWR](https://www.tracepass.eu/glossary/ppwr): PPWR is the Packaging and Packaging Waste Regulation (EU) 2025/40, which replaces the old packaging directive with directly applicable EU rules. It sets recyclability grades, minimum recycled-content targets, reuse goals and extended producer responsibility (EPR) for all packaging on the EU market. ## DPP concepts - [Confidence score](https://www.tracepass.eu/glossary/confidence-score): A confidence score is the per-field rating the AI attaches to each value it extracts from your documents, signalling how sure it is the value is correct. It tells a human reviewer exactly which fields to double-check before approving and publishing a Digital Product Passport. - [Delegated act](https://www.tracepass.eu/glossary/delegated-act): A delegated act is secondary EU legislation the European Commission adopts to fill in the technical detail of a parent regulation. For the Digital Product Passport, the ESPR (Regulation (EU) 2024/1781) sets the framework, but each product group's actual DPP requirements — which fields, which deadline — only become legally binding through a product-specific delegated act. - [Digital Product Passport (DPP)](https://www.tracepass.eu/glossary/digital-product-passport): A Digital Product Passport (DPP) is a structured, machine-readable digital record tied to a specific product, batch or item that holds its regulated sustainability and compliance data across the lifecycle. It is reached by scanning a data carrier (typically a GS1 Digital Link QR) and is mandated under the EU ESPR, Regulation (EU) 2024/1781. - [Economic operator](https://www.tracepass.eu/glossary/economic-operator): An economic operator is the legal entity that places a product on the EU market and therefore carries the Digital Product Passport obligation — typically the manufacturer, but also the importer or the manufacturer's authorised representative. Under the EU ESPR (Regulation (EU) 2024/1781) this operator is accountable for creating the passport and ensuring its data is accurate. - [EU DPP Registry](https://www.tracepass.eu/glossary/eu-dpp-registry): The EU DPP Registry is the central system the European Commission operates to hold each product's unique identifier and the URL of its Digital Product Passport, so customs and market-surveillance authorities can find the right passport. Established under the ESPR (Regulation (EU) 2024/1781), it is scheduled to go live on 19 July 2026. - [Source attribution](https://www.tracepass.eu/glossary/source-attribution): Source attribution links each filled passport field back to the exact source document and page it came from — a test report, datasheet or declaration. It is the audit-trail backbone that lets a human (or a market-surveillance authority) verify any value without re-reading every file. - [Unique product identifier (UPI)](https://www.tracepass.eu/glossary/unique-product-identifier): A unique product identifier (UPI) is the persistent ID that links a physical product to its Digital Product Passport and registers it in the EU DPP Registry. Under the EU ESPR (Regulation (EU) 2024/1781) it is encoded in the product's data carrier — commonly a GTIN expressed through GS1 Digital Link — so a scan resolves to exactly the right passport. ## Compliance data - [CE marking](https://www.tracepass.eu/glossary/ce-marking): CE marking is the manufacturer's declaration that a product meets the applicable EU health, safety and environmental requirements, letting it circulate freely in the European Economic Area. Affixing the CE mark is backed by a signed EU Declaration of Conformity and the supporting technical documentation; it is governed by Regulation (EC) 765/2008 and Decision 768/2008/EC. - [EPD (Environmental Product Declaration)](https://www.tracepass.eu/glossary/epd): An EPD (Environmental Product Declaration) is a verified, standardised document reporting a product's life-cycle environmental impacts, based on life-cycle assessment (LCA) and independently verified. It is a Type III environmental declaration under ISO 14025; for construction products, EPDs follow the harmonised European standard EN 15804. - [EPREL](https://www.tracepass.eu/glossary/eprel): EPREL (European Product Registry for Energy Labelling) is the EU's central database where suppliers must register energy-labelled products — appliances, electronics, lighting and more — before selling them in the EU. Established under Regulation (EU) 2017/1369, its energy-efficiency data is a ready source to reuse into the Digital Product Passports of those product groups. - [PEF](https://www.tracepass.eu/glossary/pef): PEF (Product Environmental Footprint) is the European Commission's standardised method for measuring a product's life-cycle environmental impact across multiple impact categories, set out in Recommendation (EU) 2021/2279. A PEF study quantifies impacts like carbon footprint using category-specific rules (PEFCRs) so results are comparable and verifiable. - [Recycled content](https://www.tracepass.eu/glossary/recycled-content): Recycled content is the proportion of a product or material — usually expressed as a percentage by weight — that comes from recycled rather than virgin feedstock. Under EU law it is becoming a mandatory, verifiable data field: the Battery Regulation (EU) 2023/1542 sets minimum recycled-content shares for key metals, and PPWR (EU) 2025/40 sets recycled-content targets for plastic packaging. - [SCIP](https://www.tracepass.eu/glossary/scip): SCIP is the European Chemicals Agency (ECHA) database of Substances of Concern In articles as such or in complex objects (Products). Established under the Waste Framework Directive (2008/98/EC), it requires suppliers to notify articles containing an SVHC above 0.1% weight by weight before placing them on the EU market. - [SVHC](https://www.tracepass.eu/glossary/svhc): An SVHC (Substance of Very High Concern) is a chemical identified under the EU REACH Regulation (EC) 1907/2006 as carcinogenic, mutagenic, toxic to reproduction, persistent, or otherwise seriously hazardous. ECHA maintains the Candidate List of SVHCs; their presence in articles must be declared above defined thresholds. --- --- title: GS1 Digital Link description: GS1 Digital Link is the GS1 standard that turns a product identifier (like a GTIN) into a web URL, so a single QR code can resolve to different content — a consumer page, a JSON-LD passport, a service endpoint — depending on who scans it. It is the data-carrier format the EU Digital Product Passport is built to use. canonical: "https://www.tracepass.eu/glossary/gs1-digital-link" locale: en source: "https://www.tracepass.eu/glossary/gs1-digital-link" --- # GS1 Digital Link > GS1 Digital Link is the GS1 standard that turns a product identifier (like a GTIN) into a web URL, so a single QR code can resolve to different content — a consumer page, a JSON-LD passport, a service endpoint — depending on who scans it. It is the data-carrier format the EU Digital Product Passport is built to use. GS1 Digital Link is the GS1 standard that turns a product identifier (like a GTIN) into a web URL, so a single QR code can resolve to different content — a consumer page, a JSON-LD passport, a service endpoint — depending on who scans it. It is the data-carrier format the EU Digital Product Passport is built to use. A traditional barcode encodes only a number. A GS1 Digital Link encodes a resolvable URL of the shape `https://id.example.com/01//21/`, so the same printed QR can serve a human-readable page in a browser and a machine-readable JSON-LD passport to a system that asks for it (via HTTP content negotiation). For a Digital Product Passport this matters because one carrier on the physical product has to serve many audiences — consumers, recyclers, market-surveillance authorities — each needing different data. GS1 Digital Link is how one QR does that without printing several codes. ## FAQ ### Is GS1 Digital Link the same as a normal QR code? The QR symbol is the same; what differs is what's encoded inside. A GS1 Digital Link QR encodes a structured, resolvable web URL rather than a bare number, which is what lets one code serve a passport, a consumer page and a service endpoint. ### Does the EU Digital Product Passport require GS1 Digital Link? ESPR requires a standardised, open data carrier; GS1 Digital Link is the carrier the ecosystem (and the CIRPASS work preparing the EU DPP registry) has converged on. TracePass publishes every passport behind a GS1 Digital Link QR. Source: [www.gs1.org/standards/gs1-digital-link](https://www.gs1.org/standards/gs1-digital-link) ## Related terms - [Digital Product Passport (DPP)](https://www.tracepass.eu/glossary/digital-product-passport) - [Data carrier](https://www.tracepass.eu/glossary/data-carrier) - [EPCIS 2.0](https://www.tracepass.eu/glossary/epcis) - [JSON-LD](https://www.tracepass.eu/glossary/json-ld) --- --- title: EPCIS 2.0 description: EPCIS 2.0 is the GS1 standard for capturing and sharing supply-chain event data — the what, when, where and why of every step a product takes. It lets a Digital Product Passport carry an interoperable, machine-readable record of lifecycle and traceability events instead of a static datasheet. canonical: "https://www.tracepass.eu/glossary/epcis" locale: en source: "https://www.tracepass.eu/glossary/epcis" --- # EPCIS 2.0 > EPCIS 2.0 is the GS1 standard for capturing and sharing supply-chain event data — the what, when, where and why of every step a product takes. It lets a Digital Product Passport carry an interoperable, machine-readable record of lifecycle and traceability events instead of a static datasheet. EPCIS 2.0 is the GS1 standard for capturing and sharing supply-chain event data — the what, when, where and why of every step a product takes. It lets a Digital Product Passport carry an interoperable, machine-readable record of lifecycle and traceability events instead of a static datasheet. EPCIS (Electronic Product Code Information Services) models the supply chain as a stream of events, each answering four dimensions: what object, when it happened, where it was, and the business step or disposition (the why). Version 2.0, ratified by GS1 in 2022, adds native JSON / JSON-LD bindings and a REST API, so events are web-friendly rather than locked in XML. For a Digital Product Passport this is the traceability backbone: rather than asserting a flat claim like "made in the EU", a passport can reference the actual chain of EPCIS events — manufacture, packing, shipping, repair, recycling — that a market-surveillance authority or recycler can verify. TracePass can export passport lifecycle data as EPCIS 2.0 events. ## FAQ ### What do the four EPCIS dimensions mean? Every EPCIS event captures what (the object or EPC), when (the timestamp), where (the location), and why (the business step and disposition, such as shipping or receiving). Together they let any reader reconstruct what happened to a product without a shared private database. ### How is EPCIS 2.0 different from version 1.2? EPCIS 2.0, ratified by GS1 in 2022, adds JSON and JSON-LD serialisations and a standard REST API alongside the original XML — making events natively web- and Linked-Data-friendly. That is what makes it a natural fit for a JSON-LD Digital Product Passport. ## Related terms - [GS1 Digital Link](https://www.tracepass.eu/glossary/gs1-digital-link) - [Digital Product Passport (DPP)](https://www.tracepass.eu/glossary/digital-product-passport) - [JSON-LD](https://www.tracepass.eu/glossary/json-ld) - [Data carrier](https://www.tracepass.eu/glossary/data-carrier) --- --- title: JSON-LD description: "JSON-LD (JSON for Linked Data) is a W3C standard that adds shared, web-resolvable meaning to ordinary JSON, so a machine knows that a field labelled \"recycledContent\" is the same concept everywhere. It is the format a Digital Product Passport is served in so that systems, search engines and AI agents can read it unambiguously." canonical: "https://www.tracepass.eu/glossary/json-ld" locale: en source: "https://www.tracepass.eu/glossary/json-ld" --- # JSON-LD > JSON-LD (JSON for Linked Data) is a W3C standard that adds shared, web-resolvable meaning to ordinary JSON, so a machine knows that a field labelled "recycledContent" is the same concept everywhere. It is the format a Digital Product Passport is served in so that systems, search engines and AI agents can read it unambiguously. JSON-LD (JSON for Linked Data) is a W3C standard that adds shared, web-resolvable meaning to ordinary JSON, so a machine knows that a field labelled "recycledContent" is the same concept everywhere. It is the format a Digital Product Passport is served in so that systems, search engines and AI agents can read it unambiguously. Plain JSON is just labelled values — two systems can both write a `material` field and mean different things. JSON-LD adds a `@context` that maps each field to a globally unique URI (a vocabulary term), so the data is self-describing Linked Data: a reader anywhere on the web can resolve exactly what each property means without a private agreement. For a Digital Product Passport this is what makes the data portable across the EU ecosystem — regulators, recyclers, retailers and AI search engines read the same semantics. TracePass serves every passport as JSON-LD over content negotiation, the machine-readable counterpart to the human-readable QR landing page. ## FAQ ### How is JSON-LD different from plain JSON? Syntactically a JSON-LD document is valid JSON, so any JSON parser reads it. The difference is the `@context`, which links each field to a shared, web-resolvable definition — turning loose key/value pairs into Linked Data whose meaning is unambiguous across systems. ### Why does a Digital Product Passport use JSON-LD? ESPR requires passport data to be machine-readable and interoperable. JSON-LD gives every field a shared meaning so EU registries, recyclers and AI agents can consume a passport without bespoke integration — and it's the same format GS1's EPCIS 2.0 and Schema.org use. ## Related terms - [Digital Product Passport (DPP)](https://www.tracepass.eu/glossary/digital-product-passport) - [EPCIS 2.0](https://www.tracepass.eu/glossary/epcis) - [GS1 Digital Link](https://www.tracepass.eu/glossary/gs1-digital-link) - [ESPR](https://www.tracepass.eu/glossary/espr) --- --- title: MCP (Model Context Protocol) description: MCP (Model Context Protocol) is an open standard that lets AI assistants and agents securely call external tools and data sources through a uniform interface, instead of each integration being bespoke. TracePass ships an MCP server, so an AI agent can create, fill and publish Digital Product Passports directly. canonical: "https://www.tracepass.eu/glossary/mcp" locale: en source: "https://www.tracepass.eu/glossary/mcp" --- # MCP (Model Context Protocol) > MCP (Model Context Protocol) is an open standard that lets AI assistants and agents securely call external tools and data sources through a uniform interface, instead of each integration being bespoke. TracePass ships an MCP server, so an AI agent can create, fill and publish Digital Product Passports directly. MCP (Model Context Protocol) is an open standard that lets AI assistants and agents securely call external tools and data sources through a uniform interface, instead of each integration being bespoke. TracePass ships an MCP server, so an AI agent can create, fill and publish Digital Product Passports directly. Introduced by Anthropic in late 2024 and now adopted across the AI ecosystem, MCP is often described as a universal connector for AI: it standardises how a model discovers a tool, learns its inputs, calls it and reads the result. Without it, every assistant-to-system link is a one-off integration; with it, any MCP-aware agent can use any MCP server. For Digital Product Passports this turns compliance into something an agent can do, not just a human clicking a UI. The TracePass MCP server exposes passport operations — search products, draft a passport from documents, check confidence scores, publish a GS1 Digital Link QR — so an AI workflow can run the regulated process end to end with a human approving before publication. ## FAQ ### Who created MCP and is it open? MCP was introduced by Anthropic in late 2024 as an open protocol and has since been adopted across the wider AI ecosystem. Because it is open, any model or agent platform can implement a client, and any service can expose an MCP server — no single vendor controls it. ### What can an AI agent do with the TracePass MCP server? It can run the passport workflow programmatically — find products, draft a Digital Product Passport from uploaded documents, read each field's confidence score and source attribution, and publish a GS1 Digital Link QR. A human still approves the regulated data before it goes live. ## Related terms - [OpenAPI](https://www.tracepass.eu/glossary/openapi) - [Confidence score](https://www.tracepass.eu/glossary/confidence-score) - [Source attribution](https://www.tracepass.eu/glossary/source-attribution) - [Digital Product Passport (DPP)](https://www.tracepass.eu/glossary/digital-product-passport) --- --- title: OpenAPI description: OpenAPI is the industry-standard, machine-readable way to describe a REST API — its endpoints, parameters, request and response shapes and authentication — in one specification file. TracePass publishes an OpenAPI 3.1 spec so any tool or AI agent can discover and call the passport API without bespoke documentation. canonical: "https://www.tracepass.eu/glossary/openapi" locale: en source: "https://www.tracepass.eu/glossary/openapi" --- # OpenAPI > OpenAPI is the industry-standard, machine-readable way to describe a REST API — its endpoints, parameters, request and response shapes and authentication — in one specification file. TracePass publishes an OpenAPI 3.1 spec so any tool or AI agent can discover and call the passport API without bespoke documentation. OpenAPI is the industry-standard, machine-readable way to describe a REST API — its endpoints, parameters, request and response shapes and authentication — in one specification file. TracePass publishes an OpenAPI 3.1 spec so any tool or AI agent can discover and call the passport API without bespoke documentation. An OpenAPI document is a single, structured contract describing exactly what a REST API offers: every path, the methods it accepts, the fields of each request and response, the status codes and the auth scheme. Because the format is standardised, tools like Postman, Insomnia and openapi-generator can import it to produce client SDKs, mock servers and interactive docs automatically. TracePass's OpenAPI 3.1 spec is the public, downloadable contract behind the API and docs — and increasingly the thing AI agents read first to understand how to operate the passport workflow before calling it. It is the REST counterpart to the MCP server: same capabilities, exposed as a conventional HTTP API. ## FAQ ### What does OpenAPI 3.1 add over earlier versions? OpenAPI 3.1 aligns the spec fully with JSON Schema, so request and response models can be described with the same vocabulary used elsewhere in modern tooling. That makes the contract cleaner to validate and easier for code generators and AI agents to consume. ### Can I import the TracePass OpenAPI spec into Postman? Yes. The spec is published as a downloadable OpenAPI 3.1 file (YAML and JSON) and imports directly into Postman, Insomnia, Bruno or openapi-generator to scaffold requests, client code and tests against the passport API. ## Related terms - [MCP (Model Context Protocol)](https://www.tracepass.eu/glossary/mcp) - [JSON-LD](https://www.tracepass.eu/glossary/json-ld) - [Digital Product Passport (DPP)](https://www.tracepass.eu/glossary/digital-product-passport) - [Confidence score](https://www.tracepass.eu/glossary/confidence-score) --- --- title: Data carrier description: A data carrier is the physical, printed or attached link on a product — typically a QR code or NFC tag — that resolves to its Digital Product Passport when scanned. ESPR defines it as the standardised, openly readable way to connect a real product to its online passport. canonical: "https://www.tracepass.eu/glossary/data-carrier" locale: en source: "https://www.tracepass.eu/glossary/data-carrier" --- # Data carrier > A data carrier is the physical, printed or attached link on a product — typically a QR code or NFC tag — that resolves to its Digital Product Passport when scanned. ESPR defines it as the standardised, openly readable way to connect a real product to its online passport. A data carrier is the physical, printed or attached link on a product — typically a QR code or NFC tag — that resolves to its Digital Product Passport when scanned. ESPR defines it as the standardised, openly readable way to connect a real product to its online passport. The data carrier is the bridge between atoms and bits: it carries no passport data itself, only a unique product identifier that points at where the passport lives online. ESPR (Regulation (EU) 2024/1781) requires this carrier to be present on the product, its packaging or its documentation, and to be based on an open, interoperable standard rather than a proprietary app. In practice the carrier is usually a GS1 Digital Link QR code or an NFC tag encoding the same resolvable URL. The exact placement, format and durability rules for each product group are set by ESPR delegated acts. TracePass generates the GS1 Digital Link QR for every passport it publishes. ## FAQ ### Does the data carrier store the passport itself? No. The carrier holds only a unique product identifier inside a resolvable URL; the passport data lives online and is fetched when the code is scanned. That keeps the printed carrier permanent while the passport behind it can be updated. ### Can the data carrier be something other than a QR code? Yes. ESPR is technology-neutral about the carrier as long as it is an open, machine-readable standard — an NFC tag, RFID or data matrix can serve the same role. QR via GS1 Digital Link is the most common choice because one symbol works for both phones and back-end systems. ## Related terms - [GS1 Digital Link](https://www.tracepass.eu/glossary/gs1-digital-link) - [Digital Product Passport (DPP)](https://www.tracepass.eu/glossary/digital-product-passport) - [ESPR](https://www.tracepass.eu/glossary/espr) - [Unique product identifier (UPI)](https://www.tracepass.eu/glossary/unique-product-identifier) --- --- title: Confidence score description: A confidence score is the per-field rating the AI attaches to each value it extracts from your documents, signalling how sure it is the value is correct. It tells a human reviewer exactly which fields to double-check before approving and publishing a Digital Product Passport. canonical: "https://www.tracepass.eu/glossary/confidence-score" locale: en source: "https://www.tracepass.eu/glossary/confidence-score" --- # Confidence score > A confidence score is the per-field rating the AI attaches to each value it extracts from your documents, signalling how sure it is the value is correct. It tells a human reviewer exactly which fields to double-check before approving and publishing a Digital Product Passport. A confidence score is the per-field rating the AI attaches to each value it extracts from your documents, signalling how sure it is the value is correct. It tells a human reviewer exactly which fields to double-check before approving and publishing a Digital Product Passport. When AI fills regulated passport fields from uploaded documents — datasheets, test reports, declarations — not every extraction is equally certain. A clear GTIN read off a label is high-confidence; a recycled-content percentage inferred from an ambiguous paragraph is not. The confidence score makes that uncertainty visible per field rather than presenting every value as equally trustworthy. This is what makes AI extraction safe for compliance data, where a wrong figure carries legal weight. Paired with source attribution — the exact document and passage each value came from — the confidence score lets a reviewer focus their attention: approve the high-confidence fields quickly, scrutinise the low-confidence ones, and never publish a number they can't trace. In TracePass a human always approves before a passport goes live. ## FAQ ### Does a high confidence score mean the value is guaranteed correct? No — it indicates how sure the AI is, not a guarantee. That is exactly why a human review step remains mandatory: the score directs attention, but a person approves every regulated field before publication, so accountability stays with the economic operator. ### How does a confidence score relate to source attribution? They work as a pair. The confidence score says how certain the AI is about a value; source attribution shows where the value came from — the exact document and passage. Together they let a reviewer verify any field quickly instead of re-keying it from scratch. ## Related terms - [Source attribution](https://www.tracepass.eu/glossary/source-attribution) - [Digital Product Passport (DPP)](https://www.tracepass.eu/glossary/digital-product-passport) - [Economic operator](https://www.tracepass.eu/glossary/economic-operator) - [MCP (Model Context Protocol)](https://www.tracepass.eu/glossary/mcp) --- --- title: Source attribution description: Source attribution links each filled passport field back to the exact source document and page it came from — a test report, datasheet or declaration. It is the audit-trail backbone that lets a human (or a market-surveillance authority) verify any value without re-reading every file. canonical: "https://www.tracepass.eu/glossary/source-attribution" locale: en source: "https://www.tracepass.eu/glossary/source-attribution" --- # Source attribution > Source attribution links each filled passport field back to the exact source document and page it came from — a test report, datasheet or declaration. It is the audit-trail backbone that lets a human (or a market-surveillance authority) verify any value without re-reading every file. Source attribution links each filled passport field back to the exact source document and page it came from — a test report, datasheet or declaration. It is the audit-trail backbone that lets a human (or a market-surveillance authority) verify any value without re-reading every file. A Digital Product Passport carries dozens of regulated fields — recycled content, hazardous-substance flags, carbon footprint. Without source attribution each value is just a claim. With it, every value carries a pointer back to the line in the SDS, the row in the bill of materials, or the page of the EN 71 test report it was read from. TracePass attaches a source citation to every field its AI fills, so the human approver sees the original document and page next to the proposed value before publishing. That citation persists in the audit trail, so months later anyone can trace a published number to its evidence — which is exactly what an authority asks for under ESPR Article 4 record-keeping duties. ## FAQ ### How is source attribution different from a confidence score? A confidence score tells you how sure the AI is about a value; source attribution tells you where the value came from. You usually want both: the score triages what to review, the attribution lets you verify it against the original document. ### Why does an authority care about source attribution? Under ESPR the economic operator must be able to substantiate every passport value on request. A field that points back to a named document and page turns a verification request from a file-hunt into a single click. ## Related terms - [Confidence score](https://www.tracepass.eu/glossary/confidence-score) - [Digital Product Passport (DPP)](https://www.tracepass.eu/glossary/digital-product-passport) - [ESPR](https://www.tracepass.eu/glossary/espr) - [Economic operator](https://www.tracepass.eu/glossary/economic-operator) --- --- title: ESPR description: ESPR is the Ecodesign for Sustainable Products Regulation (EU) 2024/1781, in force since 18 July 2024. It is the umbrella law that makes the Digital Product Passport mandatory, rolling it out product group by product group through delegated acts expected across roughly 2027–2030. canonical: "https://www.tracepass.eu/glossary/espr" locale: en source: "https://www.tracepass.eu/glossary/espr" --- # ESPR > ESPR is the Ecodesign for Sustainable Products Regulation (EU) 2024/1781, in force since 18 July 2024. It is the umbrella law that makes the Digital Product Passport mandatory, rolling it out product group by product group through delegated acts expected across roughly 2027–2030. ESPR is the Ecodesign for Sustainable Products Regulation (EU) 2024/1781, in force since 18 July 2024. It is the umbrella law that makes the Digital Product Passport mandatory, rolling it out product group by product group through delegated acts expected across roughly 2027–2030. ESPR replaces and broadens the old Ecodesign Directive 2009/125/EC, extending ecodesign requirements far beyond energy-related products to almost every physical good sold in the EU. It sets the legal basis for performance and information requirements — durability, reparability, recycled content, hazardous substances — and for the Digital Product Passport that carries them. Crucially, ESPR itself does not list the exact fields per product. It empowers the Commission to adopt delegated acts that set DPP requirements for each product group. The first working plan prioritises groups like textiles/apparel, iron and steel, aluminium, furniture and tyres, with rules and dates fixed only when each delegated act lands. Where you see a specific DPP date for a product group, it traces back to that group's delegated act, not to ESPR itself. ## FAQ ### Is the Digital Product Passport mandatory now under ESPR? ESPR is in force, but the DPP obligation switches on per product group when that group's delegated act applies — not all at once. The EU Battery Regulation runs the first passport on its own timeline (battery passport mandatory 18 February 2027); other groups follow as their ESPR delegated acts land across roughly 2027–2030. ### Which products does ESPR cover? Almost any physical product placed on the EU market, with narrow exceptions (e.g. food, feed, medicinal products). The Commission sets specific requirements per prioritised product group through delegated acts rather than regulating every product at once. ## Related terms - [Digital Product Passport (DPP)](https://www.tracepass.eu/glossary/digital-product-passport) - [Delegated act](https://www.tracepass.eu/glossary/delegated-act) - [EU Battery Regulation](https://www.tracepass.eu/glossary/eu-battery-regulation) - [EU DPP Registry](https://www.tracepass.eu/glossary/eu-dpp-registry) --- --- title: EU Battery Regulation description: The EU Battery Regulation (EU) 2023/1542 governs the full life cycle of batteries placed on the EU market — from carbon footprint and recycled content to collection and recycling. It introduces the battery passport, which becomes mandatory on 18 February 2027 for LMT, industrial (>2 kWh) and electric-vehicle batteries. canonical: "https://www.tracepass.eu/glossary/eu-battery-regulation" locale: en source: "https://www.tracepass.eu/glossary/eu-battery-regulation" --- # EU Battery Regulation > The EU Battery Regulation (EU) 2023/1542 governs the full life cycle of batteries placed on the EU market — from carbon footprint and recycled content to collection and recycling. It introduces the battery passport, which becomes mandatory on 18 February 2027 for LMT, industrial (>2 kWh) and electric-vehicle batteries. The EU Battery Regulation (EU) 2023/1542 governs the full life cycle of batteries placed on the EU market — from carbon footprint and recycled content to collection and recycling. It introduces the battery passport, which becomes mandatory on 18 February 2027 for LMT, industrial (>2 kWh) and electric-vehicle batteries. The Battery Regulation entered into force on 17 August 2023 and applies in stages. It carries the first legally fixed Digital Product Passport date in EU law: from 18 February 2027, every LMT (light means of transport), industrial battery above 2 kWh, and EV battery placed on the market must have an electronic battery passport accessible via a QR code on the battery. Each battery passport must carry model-level and unit-level data — manufacturer, chemistry, carbon footprint, recycled-content shares of cobalt, lithium, lead and nickel, state of health and more. Because its date and field set are already fixed in the regulation itself (not awaiting a delegated act), the battery passport is the proving ground that the rest of the DPP ecosystem watches. ## FAQ ### When is the battery passport mandatory? From 18 February 2027 for LMT batteries, industrial batteries above 2 kWh, and electric-vehicle batteries placed on the EU market. This date is set directly in Regulation (EU) 2023/1542, not in a later delegated act. ### How does the EU Battery Regulation relate to ESPR? They are separate laws. The Battery Regulation is product-specific and carries its own passport on a fixed 2027 date; ESPR is the umbrella framework rolling out passports for other product groups via delegated acts. The battery passport is widely treated as the template the broader DPP follows. ## Related terms - [Digital Product Passport (DPP)](https://www.tracepass.eu/glossary/digital-product-passport) - [ESPR](https://www.tracepass.eu/glossary/espr) - [Recycled content](https://www.tracepass.eu/glossary/recycled-content) - [PEF](https://www.tracepass.eu/glossary/pef) --- --- title: PPWR description: PPWR is the Packaging and Packaging Waste Regulation (EU) 2025/40, which replaces the old packaging directive with directly applicable EU rules. It sets recyclability grades, minimum recycled-content targets, reuse goals and extended producer responsibility (EPR) for all packaging on the EU market. canonical: "https://www.tracepass.eu/glossary/ppwr" locale: en source: "https://www.tracepass.eu/glossary/ppwr" --- # PPWR > PPWR is the Packaging and Packaging Waste Regulation (EU) 2025/40, which replaces the old packaging directive with directly applicable EU rules. It sets recyclability grades, minimum recycled-content targets, reuse goals and extended producer responsibility (EPR) for all packaging on the EU market. PPWR is the Packaging and Packaging Waste Regulation (EU) 2025/40, which replaces the old packaging directive with directly applicable EU rules. It sets recyclability grades, minimum recycled-content targets, reuse goals and extended producer responsibility (EPR) for all packaging on the EU market. Adopted as Regulation (EU) 2025/40 and published in early 2025, the PPWR moves packaging rules from a directive (which each member state transposed differently) to a single directly applicable regulation. Most of its substantive obligations apply from 12 August 2026, with several requirements — like recyclability performance grades A/B/C and minimum recycled-content thresholds for plastic packaging — phasing in on later dates fixed in the text. For DPP work the PPWR matters because packaging data — material composition, recyclability grade, recycled-content share, reuse and separate-collection guidance — increasingly travels with the product rather than living in a separate compliance silo. Several of these fields overlap directly with what a Digital Product Passport already carries, so capturing them once and reusing them is the efficient path. ## FAQ ### Is the PPWR a regulation or a directive? It is a regulation — (EU) 2025/40 — so it applies directly in every member state without national transposition, unlike the packaging directive it replaces. That removes the country-by-country differences manufacturers used to navigate. ### Does packaging get its own Digital Product Passport? The PPWR sets its own labelling and information duties rather than mandating a DPP as such, but its data overlaps heavily with passport fields — recycled content, recyclability grade, material composition. In practice many manufacturers capture packaging data alongside product data so they satisfy both regimes from one source. ## Related terms - [Recycled content](https://www.tracepass.eu/glossary/recycled-content) - [Digital Product Passport (DPP)](https://www.tracepass.eu/glossary/digital-product-passport) - [ESPR](https://www.tracepass.eu/glossary/espr) - [Economic operator](https://www.tracepass.eu/glossary/economic-operator) --- --- title: CSRD / ESRS description: CSRD is the EU Corporate Sustainability Reporting Directive; ESRS are the European Sustainability Reporting Standards that define what a company must report under it. Together they govern company-level sustainability reporting — distinct from the product-level Digital Product Passport. canonical: "https://www.tracepass.eu/glossary/csrd-esrs" locale: en source: "https://www.tracepass.eu/glossary/csrd-esrs" --- # CSRD / ESRS > CSRD is the EU Corporate Sustainability Reporting Directive; ESRS are the European Sustainability Reporting Standards that define what a company must report under it. Together they govern company-level sustainability reporting — distinct from the product-level Digital Product Passport. CSRD is the EU Corporate Sustainability Reporting Directive; ESRS are the European Sustainability Reporting Standards that define what a company must report under it. Together they govern company-level sustainability reporting — distinct from the product-level Digital Product Passport. CSRD (Directive (EU) 2022/2464) expands EU sustainability reporting to far more companies and requires they report against the ESRS — a single set of standards covering environmental, social and governance topics, with double materiality at their core. Reporting is company-wide and annual: emissions, workforce, value-chain impacts, governance. A Digital Product Passport is the opposite altitude: it describes one product, not the whole company. The two connect because product-level data feeds upward — a product's carbon footprint, recycled content and supply-chain attributes are exactly the granular inputs a CSRD report aggregates. TracePass sits on the product side: it produces and publishes passports and surfaces the underlying field data, but it does not generate a CSRD report. It feeds the reporting layer; it is not the reporting tool. ## FAQ ### Is a Digital Product Passport the same as a CSRD report? No. A DPP describes a single product; a CSRD report describes the whole company over a year. They share data — product carbon footprint and recycled content roll up into company reporting — but they are different documents at different altitudes. ### Does TracePass produce CSRD reports? No. TracePass operates at the product level: it produces Digital Product Passports and exposes the structured field data behind them. That data can feed a CSRD/ESRS reporting workflow, but TracePass is not the reporting tool — it is an upstream source for it. ## Related terms - [Digital Product Passport (DPP)](https://www.tracepass.eu/glossary/digital-product-passport) - [PEF](https://www.tracepass.eu/glossary/pef) - [Recycled content](https://www.tracepass.eu/glossary/recycled-content) - [Source attribution](https://www.tracepass.eu/glossary/source-attribution) --- --- title: EUDR description: EUDR is the EU Deforestation Regulation (EU) 2023/1115, which bars listed commodities — including wood, cattle, soy, coffee, cocoa, palm oil and rubber — and products made from them from the EU market unless they are deforestation-free and legal. Operators must run due diligence with geolocation coordinates for every plot of land of origin. canonical: "https://www.tracepass.eu/glossary/eudr" locale: en source: "https://www.tracepass.eu/glossary/eudr" --- # EUDR > EUDR is the EU Deforestation Regulation (EU) 2023/1115, which bars listed commodities — including wood, cattle, soy, coffee, cocoa, palm oil and rubber — and products made from them from the EU market unless they are deforestation-free and legal. Operators must run due diligence with geolocation coordinates for every plot of land of origin. EUDR is the EU Deforestation Regulation (EU) 2023/1115, which bars listed commodities — including wood, cattle, soy, coffee, cocoa, palm oil and rubber — and products made from them from the EU market unless they are deforestation-free and legal. Operators must run due diligence with geolocation coordinates for every plot of land of origin. Under EUDR, an operator placing an in-scope commodity or product on the EU market must file a due-diligence statement showing the goods are deforestation-free (not linked to land deforested after 31 December 2020) and produced legally in the country of origin. The defining requirement is geolocation: precise coordinates of every plot of land where the raw material was produced, so the supply chain can be traced to source. For DPP work, EUDR is most relevant to wood, timber, paper and natural-rubber inputs, and to textiles where leather or natural fibres enter the chain. The geolocation and legality evidence it demands often lives in the same supplier documents a passport draws on, so capturing source-attributed origin data once serves both the EUDR due-diligence file and the product passport. Application dates have been adjusted during roll-out, so confirm the current applicable date for your operator size against the latest EU guidance rather than assuming a fixed cutover. ## FAQ ### Which products does the EUDR cover? Seven commodities — cattle, cocoa, coffee, oil palm, rubber, soy and wood — plus a list of derived products such as leather, furniture, paper, chocolate and tyres. Wood, paper and natural-rubber inputs are the most common overlap with Digital Product Passport work. ### What is the geolocation requirement? Operators must record the precise geographic coordinates (and, for larger plots, polygons) of every parcel of land where the commodity was produced, then submit them in a due-diligence statement. It is what lets authorities check the goods against deforestation data for that exact location. ## Related terms - [Digital Product Passport (DPP)](https://www.tracepass.eu/glossary/digital-product-passport) - [Economic operator](https://www.tracepass.eu/glossary/economic-operator) - [Source attribution](https://www.tracepass.eu/glossary/source-attribution) - [ESPR](https://www.tracepass.eu/glossary/espr) --- --- title: Digital Product Passport (DPP) description: A Digital Product Passport (DPP) is a structured, machine-readable digital record tied to a specific product, batch or item that holds its regulated sustainability and compliance data across the lifecycle. It is reached by scanning a data carrier (typically a GS1 Digital Link QR) and is mandated under the EU ESPR, Regulation (EU) 2024/1781. canonical: "https://www.tracepass.eu/glossary/digital-product-passport" locale: en source: "https://www.tracepass.eu/glossary/digital-product-passport" --- # Digital Product Passport (DPP) > A Digital Product Passport (DPP) is a structured, machine-readable digital record tied to a specific product, batch or item that holds its regulated sustainability and compliance data across the lifecycle. It is reached by scanning a data carrier (typically a GS1 Digital Link QR) and is mandated under the EU ESPR, Regulation (EU) 2024/1781. A Digital Product Passport (DPP) is a structured, machine-readable digital record tied to a specific product, batch or item that holds its regulated sustainability and compliance data across the lifecycle. It is reached by scanning a data carrier (typically a GS1 Digital Link QR) and is mandated under the EU ESPR, Regulation (EU) 2024/1781. A DPP is not a PDF or a marketing microsite — it is a structured dataset, served in a machine-readable format such as JSON-LD, that different audiences can query for the slice they need: consumers see repair and disposal guidance, recyclers see material composition, and market-surveillance authorities see compliance evidence. The same physical data carrier resolves to different views depending on who scans it. The DPP is introduced as a horizontal framework by the ESPR (Regulation (EU) 2024/1781, in force). It does not apply to every product at once: the European Commission switches it on product group by product group through delegated acts, with the first waves (batteries, textiles, iron and steel, and others) rolling out across roughly 2025–2030. The EU Battery Regulation (EU) 2023/1542 sets the first hard deadline — a mandatory battery passport from 18 February 2027. ## FAQ ### Is a Digital Product Passport just a QR code? No. The QR code (or NFC/RFID tag) is only the data carrier — the doorway. The passport itself is the structured digital record behind it, served in a machine-readable format such as JSON-LD, that the carrier resolves to. ### Which products will need a DPP and when? The ESPR enables a DPP for almost any physical product, but it becomes mandatory group by group through delegated acts. Batteries are first, with a mandatory battery passport from 18 February 2027 under Regulation (EU) 2023/1542; textiles, iron and steel and others follow across roughly 2026–2030. ### Who is responsible for creating a product's DPP? The economic operator placing the product on the EU market — usually the manufacturer, or the importer or authorised representative — owns the passport obligation and is accountable for the accuracy of its data. ## Related terms - [ESPR](https://www.tracepass.eu/glossary/espr) - [Data carrier](https://www.tracepass.eu/glossary/data-carrier) - [GS1 Digital Link](https://www.tracepass.eu/glossary/gs1-digital-link) - [EU DPP Registry](https://www.tracepass.eu/glossary/eu-dpp-registry) --- --- title: Unique product identifier (UPI) description: "A unique product identifier (UPI) is the persistent ID that links a physical product to its Digital Product Passport and registers it in the EU DPP Registry. Under the EU ESPR (Regulation (EU) 2024/1781) it is encoded in the product's data carrier — commonly a GTIN expressed through GS1 Digital Link — so a scan resolves to exactly the right passport." canonical: "https://www.tracepass.eu/glossary/unique-product-identifier" locale: en source: "https://www.tracepass.eu/glossary/unique-product-identifier" --- # Unique product identifier (UPI) > A unique product identifier (UPI) is the persistent ID that links a physical product to its Digital Product Passport and registers it in the EU DPP Registry. Under the EU ESPR (Regulation (EU) 2024/1781) it is encoded in the product's data carrier — commonly a GTIN expressed through GS1 Digital Link — so a scan resolves to exactly the right passport. A unique product identifier (UPI) is the persistent ID that links a physical product to its Digital Product Passport and registers it in the EU DPP Registry. Under the EU ESPR (Regulation (EU) 2024/1781) it is encoded in the product's data carrier — commonly a GTIN expressed through GS1 Digital Link — so a scan resolves to exactly the right passport. Three identifiers sit at the heart of the DPP model and are easy to confuse. The unique product identifier ties the carrier to the passport; the EU ESPR also references a unique operator identifier (the economic operator) and, where relevant, a unique facility identifier. The UPI is the one printed on or embedded in the product, and it must stay stable for the product's life so the passport remains resolvable years after sale. In practice the ecosystem expresses the UPI using existing GS1 keys — most often a GTIN, optionally with a serial number for item-level passports — carried in a GS1 Digital Link URL. The exact required identifier scheme for each product group is set in that group's delegated act, so check the relevant act rather than assuming one format fits all. ## FAQ ### Is a unique product identifier the same as a GTIN? Not exactly. A GTIN is one common way to express the UPI, but the UPI is the regulatory concept (the ID that resolves to a passport and registers it in the EU DPP Registry). For item-level passports a GTIN is usually combined with a serial number. ### Where is the unique product identifier stored? It is encoded in the product's data carrier — typically a GS1 Digital Link QR, NFC or RFID tag — and recorded centrally in the EU DPP Registry, which maps each identifier to the URL of its passport. ### Can two products share one unique product identifier? It depends on the granularity the delegated act requires: a model/GTIN-level identifier can cover all items of one product, while item-level or batch-level passports need a serialised identifier so each unit or batch resolves to its own passport. ## Related terms - [GS1 Digital Link](https://www.tracepass.eu/glossary/gs1-digital-link) - [Data carrier](https://www.tracepass.eu/glossary/data-carrier) - [EU DPP Registry](https://www.tracepass.eu/glossary/eu-dpp-registry) - [Digital Product Passport (DPP)](https://www.tracepass.eu/glossary/digital-product-passport) --- --- title: Economic operator description: "An economic operator is the legal entity that places a product on the EU market and therefore carries the Digital Product Passport obligation — typically the manufacturer, but also the importer or the manufacturer's authorised representative. Under the EU ESPR (Regulation (EU) 2024/1781) this operator is accountable for creating the passport and ensuring its data is accurate." canonical: "https://www.tracepass.eu/glossary/economic-operator" locale: en source: "https://www.tracepass.eu/glossary/economic-operator" --- # Economic operator > An economic operator is the legal entity that places a product on the EU market and therefore carries the Digital Product Passport obligation — typically the manufacturer, but also the importer or the manufacturer's authorised representative. Under the EU ESPR (Regulation (EU) 2024/1781) this operator is accountable for creating the passport and ensuring its data is accurate. An economic operator is the legal entity that places a product on the EU market and therefore carries the Digital Product Passport obligation — typically the manufacturer, but also the importer or the manufacturer's authorised representative. Under the EU ESPR (Regulation (EU) 2024/1781) this operator is accountable for creating the passport and ensuring its data is accurate. "Economic operator" is the catch-all term EU product law uses for the actors in a supply chain who carry obligations: manufacturer, authorised representative, importer, distributor, fulfilment service provider, and others. For the Digital Product Passport, the operative question is who is responsible for the passport — and that defaults to whoever places the product on the EU market under their name or trademark. For an EU manufacturer that is the manufacturer; for goods made outside the EU it is usually the importer or an EU-based authorised representative. This matters because the obligation is not delegable away by a contract clause. The responsible operator must ensure a passport exists, is registered in the EU DPP Registry, stays available for the required period, and reflects accurate, source-backed data — even though much of that data originates upstream with suppliers. Tooling that captures supplier documents and attributes each field to its source is how operators make that accountability tractable; TracePass is built around exactly that gap. ## FAQ ### Is the manufacturer always the responsible economic operator? Usually, but not always. The obligation falls on whoever places the product on the EU market under their name or trademark. For products made outside the EU, that is typically the importer or an EU-based authorised representative rather than the original manufacturer. ### Can an economic operator outsource the DPP obligation? It can outsource the work of building and hosting the passport, but not the legal accountability. The responsible operator remains liable for the passport's existence, registration and data accuracy regardless of who operates the tooling. ### Does a distributor or retailer need to create a DPP? Generally no — the passport is created by the operator placing the product on the market. But distributors have their own duties (for example verifying a passport is present and correct before selling), and a distributor who modifies a product or sells it under their own brand can become the responsible operator. ## Related terms - [Digital Product Passport (DPP)](https://www.tracepass.eu/glossary/digital-product-passport) - [ESPR](https://www.tracepass.eu/glossary/espr) - [EU DPP Registry](https://www.tracepass.eu/glossary/eu-dpp-registry) - [Source attribution](https://www.tracepass.eu/glossary/source-attribution) --- --- title: Delegated act description: "A delegated act is secondary EU legislation the European Commission adopts to fill in the technical detail of a parent regulation. For the Digital Product Passport, the ESPR (Regulation (EU) 2024/1781) sets the framework, but each product group's actual DPP requirements — which fields, which deadline — only become legally binding through a product-specific delegated act." canonical: "https://www.tracepass.eu/glossary/delegated-act" locale: en source: "https://www.tracepass.eu/glossary/delegated-act" --- # Delegated act > A delegated act is secondary EU legislation the European Commission adopts to fill in the technical detail of a parent regulation. For the Digital Product Passport, the ESPR (Regulation (EU) 2024/1781) sets the framework, but each product group's actual DPP requirements — which fields, which deadline — only become legally binding through a product-specific delegated act. A delegated act is secondary EU legislation the European Commission adopts to fill in the technical detail of a parent regulation. For the Digital Product Passport, the ESPR (Regulation (EU) 2024/1781) sets the framework, but each product group's actual DPP requirements — which fields, which deadline — only become legally binding through a product-specific delegated act. EU regulations often set out principles and powers, then hand the Commission authority (under Article 290 of the Treaty) to adopt delegated acts that specify the technical detail. This keeps the parent law stable while the specifics evolve. The ESPR uses this structure heavily: it establishes that a DPP can be required and what it can contain, but defers the binding per-product-group rules to delegated acts, each preceded by impact assessment and stakeholder consultation. This is why so many DPP timelines read "expected" or "to be confirmed." Until the delegated act for a given product group is adopted and enters into force, the exact data fields, the data-carrier rules and the compliance date for that group are not yet legally fixed. The major exception is batteries, governed by their own regulation (EU) 2023/1542, which already sets a firm 18 February 2027 deadline for the battery passport. When a date for any other group is still pending, the honest statement is that it awaits its delegated act. ## FAQ ### Why does my product's DPP deadline depend on a delegated act? Because the ESPR is a framework: it enables the DPP but leaves the binding rules — data fields, carrier requirements and the compliance date — to a delegated act adopted per product group. Until that act enters into force, the exact requirements for your group are not legally fixed. ### How is a delegated act different from the regulation itself? The regulation (the parent law, like the ESPR) is adopted by the European Parliament and Council and sets the framework and powers. A delegated act is adopted by the Commission under that delegated power to add technical detail, and Parliament and Council can object within a scrutiny period. ### Are any DPP requirements already fixed without waiting for a delegated act? Yes — batteries. The battery passport is set directly by Regulation (EU) 2023/1542 with a firm deadline of 18 February 2027, so it does not wait on an ESPR delegated act. Most other product groups still do. ## Related terms - [ESPR](https://www.tracepass.eu/glossary/espr) - [Digital Product Passport (DPP)](https://www.tracepass.eu/glossary/digital-product-passport) - [EU Battery Regulation](https://www.tracepass.eu/glossary/eu-battery-regulation) - [EU DPP Registry](https://www.tracepass.eu/glossary/eu-dpp-registry) --- --- title: EU DPP Registry description: "The EU DPP Registry is the central system the European Commission operates to hold each product's unique identifier and the URL of its Digital Product Passport, so customs and market-surveillance authorities can find the right passport. Established under the ESPR (Regulation (EU) 2024/1781), it is scheduled to go live on 19 July 2026." canonical: "https://www.tracepass.eu/glossary/eu-dpp-registry" locale: en source: "https://www.tracepass.eu/glossary/eu-dpp-registry" --- # EU DPP Registry > The EU DPP Registry is the central system the European Commission operates to hold each product's unique identifier and the URL of its Digital Product Passport, so customs and market-surveillance authorities can find the right passport. Established under the ESPR (Regulation (EU) 2024/1781), it is scheduled to go live on 19 July 2026. The EU DPP Registry is the central system the European Commission operates to hold each product's unique identifier and the URL of its Digital Product Passport, so customs and market-surveillance authorities can find the right passport. Established under the ESPR (Regulation (EU) 2024/1781), it is scheduled to go live on 19 July 2026. The registry is deliberately thin. It does not store the full passport — that lives at the economic operator's chosen address, reached through the data carrier — but it does store the mapping: the product's unique identifier and a pointer to where the passport actually resides, plus a backup of certain core data. This index lets authorities (especially customs at the EU border) look up a product and verify a passport exists without crawling every operator's site. The European Commission has scheduled the registry to go live on 19 July 2026, ahead of the first product-group DPP obligations. Note that go-live of the registry is distinct from any individual product's compliance date: a product only has to be registered once its product group's delegated act (or, for batteries, Regulation (EU) 2023/1542) makes the passport mandatory. The registry is the plumbing; the delegated acts decide when each product flows through it. ## FAQ ### When does the EU DPP Registry go live? The European Commission has scheduled the central registry to go live on 19 July 2026. That is the registry's operational start; it does not by itself make any individual product's passport mandatory — that timing is set by each product group's delegated act (or, for batteries, Regulation (EU) 2023/1542). ### Does the EU DPP Registry store the whole passport? No. It stores each product's unique identifier and a pointer to where the passport actually lives, plus a backup of certain core data. The full passport is hosted at the operator's chosen address and reached through the product's data carrier. ### Who uses the EU DPP Registry? Primarily authorities — customs at the EU border and market-surveillance bodies — to look up a product by its identifier and confirm a registered passport exists. Economic operators register their products and identifiers into it; consumers normally reach a passport by scanning the carrier, not via the registry. ## Related terms - [Unique product identifier (UPI)](https://www.tracepass.eu/glossary/unique-product-identifier) - [Digital Product Passport (DPP)](https://www.tracepass.eu/glossary/digital-product-passport) - [ESPR](https://www.tracepass.eu/glossary/espr) - [Delegated act](https://www.tracepass.eu/glossary/delegated-act) --- --- title: EPREL description: "EPREL (European Product Registry for Energy Labelling) is the EU's central database where suppliers must register energy-labelled products — appliances, electronics, lighting and more — before selling them in the EU. Established under Regulation (EU) 2017/1369, its energy-efficiency data is a ready source to reuse into the Digital Product Passports of those product groups." canonical: "https://www.tracepass.eu/glossary/eprel" locale: en source: "https://www.tracepass.eu/glossary/eprel" --- # EPREL > EPREL (European Product Registry for Energy Labelling) is the EU's central database where suppliers must register energy-labelled products — appliances, electronics, lighting and more — before selling them in the EU. Established under Regulation (EU) 2017/1369, its energy-efficiency data is a ready source to reuse into the Digital Product Passports of those product groups. EPREL (European Product Registry for Energy Labelling) is the EU's central database where suppliers must register energy-labelled products — appliances, electronics, lighting and more — before selling them in the EU. Established under Regulation (EU) 2017/1369, its energy-efficiency data is a ready source to reuse into the Digital Product Passports of those product groups. EPREL has been live since 2019: any product carrying an EU energy label (fridges, washing machines, dishwashers, displays, light sources, and a growing list) must be registered in EPREL by the supplier before it goes on sale, and the public-facing part lets anyone look up a model's energy class and label. Each label already carries a QR code that links to the product's EPREL entry. For the Digital Product Passport this is a head start, not a duplicate. Where a product group falls under both an energy label and a future ESPR DPP delegated act, the energy-efficiency attributes a supplier has already filed in EPREL are exactly the kind of regulated data the passport needs — so rather than re-entering it, the practical pattern is to reuse the EPREL data into the DPP. TracePass treats existing registry and label data as a source to pull from and attribute, not a field to retype. ## FAQ ### What does EPREL stand for? EPREL is the European Product Registry for Energy Labelling — the EU's central database, established under Regulation (EU) 2017/1369, where suppliers register products that carry an EU energy label before placing them on the market. ### Is EPREL the same as the Digital Product Passport? No. EPREL is a long-running, energy-label-specific registry; the DPP is a broader lifecycle record introduced by the ESPR. They overlap for energy-labelled products, where EPREL data can be reused to populate the passport rather than re-entered. ### Can EPREL data be reused in a product's DPP? Yes, and that is the efficient path. For products covered by both schemes, the energy-efficiency attributes already registered in EPREL are exactly the regulated data a passport needs, so reusing them — with attribution to the EPREL source — avoids duplicate data entry. ## Related terms - [Digital Product Passport (DPP)](https://www.tracepass.eu/glossary/digital-product-passport) - [Source attribution](https://www.tracepass.eu/glossary/source-attribution) - [ESPR](https://www.tracepass.eu/glossary/espr) - [CE marking](https://www.tracepass.eu/glossary/ce-marking) --- --- title: SVHC description: An SVHC (Substance of Very High Concern) is a chemical identified under the EU REACH Regulation (EC) 1907/2006 as carcinogenic, mutagenic, toxic to reproduction, persistent, or otherwise seriously hazardous. ECHA maintains the Candidate List of SVHCs; their presence in articles must be declared above defined thresholds. canonical: "https://www.tracepass.eu/glossary/svhc" locale: en source: "https://www.tracepass.eu/glossary/svhc" --- # SVHC > An SVHC (Substance of Very High Concern) is a chemical identified under the EU REACH Regulation (EC) 1907/2006 as carcinogenic, mutagenic, toxic to reproduction, persistent, or otherwise seriously hazardous. ECHA maintains the Candidate List of SVHCs; their presence in articles must be declared above defined thresholds. An SVHC (Substance of Very High Concern) is a chemical identified under the EU REACH Regulation (EC) 1907/2006 as carcinogenic, mutagenic, toxic to reproduction, persistent, or otherwise seriously hazardous. ECHA maintains the Candidate List of SVHCs; their presence in articles must be declared above defined thresholds. The SVHC Candidate List is published and updated twice a year by the European Chemicals Agency (ECHA). Listing carries immediate legal duties even before a substance is added to the REACH authorisation list: when an SVHC is present in an article above 0.1% weight by weight, suppliers must pass that information down the supply chain and notify ECHA's SCIP database. For a Digital Product Passport this matters because substance-of-concern data is a regulated field across product groups under ESPR. Knowing which SVHCs a product contains, and at what concentration, is the prerequisite for both the SCIP notification and any DPP disclosure on hazardous substances. ## FAQ ### What is the 0.1% SVHC threshold? When an SVHC on the ECHA Candidate List is present in an article above 0.1% weight by weight, REACH duties trigger: communication of safe-use information down the supply chain, a response to consumer requests within 45 days, and a SCIP notification to ECHA. ### Is the SVHC list the same as the REACH Authorisation List? No. The Candidate List is a precursor — substances on it may later be moved to Annex XIV (the Authorisation List), which then bans their use without specific authorisation. Candidate-List listing already carries notification and communication duties on its own. ## Related terms - [SCIP](https://www.tracepass.eu/glossary/scip) - [ESPR](https://www.tracepass.eu/glossary/espr) - [Digital Product Passport (DPP)](https://www.tracepass.eu/glossary/digital-product-passport) --- --- title: SCIP description: SCIP is the European Chemicals Agency (ECHA) database of Substances of Concern In articles as such or in complex objects (Products). Established under the Waste Framework Directive (2008/98/EC), it requires suppliers to notify articles containing an SVHC above 0.1% weight by weight before placing them on the EU market. canonical: "https://www.tracepass.eu/glossary/scip" locale: en source: "https://www.tracepass.eu/glossary/scip" --- # SCIP > SCIP is the European Chemicals Agency (ECHA) database of Substances of Concern In articles as such or in complex objects (Products). Established under the Waste Framework Directive (2008/98/EC), it requires suppliers to notify articles containing an SVHC above 0.1% weight by weight before placing them on the EU market. SCIP is the European Chemicals Agency (ECHA) database of Substances of Concern In articles as such or in complex objects (Products). Established under the Waste Framework Directive (2008/98/EC), it requires suppliers to notify articles containing an SVHC above 0.1% weight by weight before placing them on the EU market. SCIP stands for Substances of Concern In articles as such or in complex objects (Products). The notification obligation has applied since 5 January 2021. Any EU supplier of an article — manufacturer, importer, distributor — must submit a SCIP dossier to ECHA whenever an SVHC from the Candidate List is present above the 0.1% threshold, identifying the article, the substance, its location and safe-use information. The database makes substance-of-concern data publicly searchable for waste operators and consumers. For a Digital Product Passport, an existing SCIP notification is a ready source of the hazardous-substance data the DPP needs — the same article identity and SVHC concentration can be reused rather than re-collected. ## FAQ ### Who has to submit a SCIP notification? Any EU supplier of an article that contains an SVHC above 0.1% weight by weight — producers, assemblers, importers and distributors. Retailers supplying only to consumers are exempt, but everyone upstream of them is not. ### How is SCIP different from a REACH SVHC declaration? The SVHC duty under REACH is to communicate safe-use information in the supply chain; SCIP is the specific ECHA database notification mandated by the Waste Framework Directive. Both are triggered by the same 0.1% SVHC presence, but SCIP is a structured dossier submitted to ECHA, not just downstream communication. ## Related terms - [SVHC](https://www.tracepass.eu/glossary/svhc) - [ESPR](https://www.tracepass.eu/glossary/espr) - [Digital Product Passport (DPP)](https://www.tracepass.eu/glossary/digital-product-passport) --- --- title: PEF description: "PEF (Product Environmental Footprint) is the European Commission's standardised method for measuring a product's life-cycle environmental impact across multiple impact categories, set out in Recommendation (EU) 2021/2279. A PEF study quantifies impacts like carbon footprint using category-specific rules (PEFCRs) so results are comparable and verifiable." canonical: "https://www.tracepass.eu/glossary/pef" locale: en source: "https://www.tracepass.eu/glossary/pef" --- # PEF > PEF (Product Environmental Footprint) is the European Commission's standardised method for measuring a product's life-cycle environmental impact across multiple impact categories, set out in Recommendation (EU) 2021/2279. A PEF study quantifies impacts like carbon footprint using category-specific rules (PEFCRs) so results are comparable and verifiable. PEF (Product Environmental Footprint) is the European Commission's standardised method for measuring a product's life-cycle environmental impact across multiple impact categories, set out in Recommendation (EU) 2021/2279. A PEF study quantifies impacts like carbon footprint using category-specific rules (PEFCRs) so results are comparable and verifiable. PEF builds on life-cycle assessment (LCA) but constrains it: the method, the impact categories, and the calculation rules are fixed, and for many product groups a Product Environmental Footprint Category Rule (PEFCR) pins down exactly how a study must be run. That standardisation is the point — it makes one product's footprint comparable to another's instead of relying on incomparable self-declared LCAs. A full PEF study is data-intensive and usually a paid, expert-led exercise. For a Digital Product Passport, a completed PEF (or a PEFCR-aligned carbon footprint figure) is a reusable input: the verified impact result can populate the DPP's environmental-footprint fields rather than being recalculated. PEF is a method; an EPD is a verified declaration that often reports PEF- or LCA-based results. ## FAQ ### Is PEF the same as a carbon footprint? No. Carbon footprint (climate-change impact) is one of the categories a PEF measures; PEF covers a broader set — water use, resource depletion, eutrophication and more. A product's carbon footprint can be a single output of a fuller PEF study. ### Does a DPP require a PEF study? Not universally. ESPR delegated acts set the environmental-footprint requirements per product group, and some will draw on PEF or PEFCR methods. Where a PEF or LCA already exists, TracePass can reuse its verified results to populate the relevant DPP fields with source attribution rather than commissioning a new study. ## Related terms - [EPD (Environmental Product Declaration)](https://www.tracepass.eu/glossary/epd) - [ESPR](https://www.tracepass.eu/glossary/espr) - [Source attribution](https://www.tracepass.eu/glossary/source-attribution) - [Digital Product Passport (DPP)](https://www.tracepass.eu/glossary/digital-product-passport) --- --- title: EPD (Environmental Product Declaration) description: "An EPD (Environmental Product Declaration) is a verified, standardised document reporting a product's life-cycle environmental impacts, based on life-cycle assessment (LCA) and independently verified. It is a Type III environmental declaration under ISO 14025; for construction products, EPDs follow the harmonised European standard EN 15804." canonical: "https://www.tracepass.eu/glossary/epd" locale: en source: "https://www.tracepass.eu/glossary/epd" --- # EPD (Environmental Product Declaration) > An EPD (Environmental Product Declaration) is a verified, standardised document reporting a product's life-cycle environmental impacts, based on life-cycle assessment (LCA) and independently verified. It is a Type III environmental declaration under ISO 14025; for construction products, EPDs follow the harmonised European standard EN 15804. An EPD (Environmental Product Declaration) is a verified, standardised document reporting a product's life-cycle environmental impacts, based on life-cycle assessment (LCA) and independently verified. It is a Type III environmental declaration under ISO 14025; for construction products, EPDs follow the harmonised European standard EN 15804. An EPD turns an LCA into a comparable, third-party-verified declaration. Because it is built on Product Category Rules (PCR) and verified by an independent body, an EPD carries credibility that a self-declared environmental claim does not. In construction, EN 15804 is the core standard that makes EPDs across products and EPD programme operators comparable. For a Digital Product Passport, an existing EPD is one of the most valuable inputs: it is already verified, already structured around life-cycle stages, and already quantifies impacts like global-warming potential. TracePass can read those values from an uploaded EPD into the DPP's environmental fields, keeping the source attribution so the published passport traces every figure back to the verified declaration. ## FAQ ### What is the difference between an EPD and a PEF? PEF is the EU's calculation method for environmental footprint; an EPD is a verified declaration document that reports life-cycle results, typically following ISO 14025 / EN 15804 and Product Category Rules. An EPD can report PEF- or LCA-based results, but the EPD is the verified output, not the method. ### Is EN 15804 mandatory for all EPDs? EN 15804 is the core European standard specifically for construction-product EPDs and the basis for declarations used in building-level assessments. EPDs for other product groups follow ISO 14025 and the relevant Product Category Rules; EN 15804 is the construction-sector harmonisation. ## Related terms - [PEF](https://www.tracepass.eu/glossary/pef) - [Source attribution](https://www.tracepass.eu/glossary/source-attribution) - [ESPR](https://www.tracepass.eu/glossary/espr) - [Digital Product Passport (DPP)](https://www.tracepass.eu/glossary/digital-product-passport) --- --- title: CE marking description: "CE marking is the manufacturer's declaration that a product meets the applicable EU health, safety and environmental requirements, letting it circulate freely in the European Economic Area. Affixing the CE mark is backed by a signed EU Declaration of Conformity and the supporting technical documentation; it is governed by Regulation (EC) 765/2008 and Decision 768/2008/EC." canonical: "https://www.tracepass.eu/glossary/ce-marking" locale: en source: "https://www.tracepass.eu/glossary/ce-marking" --- # CE marking > CE marking is the manufacturer's declaration that a product meets the applicable EU health, safety and environmental requirements, letting it circulate freely in the European Economic Area. Affixing the CE mark is backed by a signed EU Declaration of Conformity and the supporting technical documentation; it is governed by Regulation (EC) 765/2008 and Decision 768/2008/EC. CE marking is the manufacturer's declaration that a product meets the applicable EU health, safety and environmental requirements, letting it circulate freely in the European Economic Area. Affixing the CE mark is backed by a signed EU Declaration of Conformity and the supporting technical documentation; it is governed by Regulation (EC) 765/2008 and Decision 768/2008/EC. CE marking is not a quality mark or a certification by an authority — in most cases it is the manufacturer's own attestation, made under its responsibility, that the product conforms to all the EU legislation that applies to it (machinery, EMC, low voltage, toys, medical devices and so on). For higher-risk products a notified body must be involved, but the legal responsibility for the declaration stays with the economic operator. For a Digital Product Passport, the CE mark and its underlying EU Declaration of Conformity are natural anchors: a passport for a CE-marked product can link directly to the Declaration of Conformity and the conformity evidence, so a market-surveillance authority scanning the QR reaches the compliance documentation rather than a marketing page. The CE mark itself is a data field many passports reference. ## FAQ ### Does the CE mark mean a product was certified by the EU? No. For most products it is the manufacturer's own declaration of conformity, made under its responsibility. Only for higher-risk categories does an independent notified body assess conformity. CE is a self-declaration backed by a technical file and an EU Declaration of Conformity, not an EU certificate. ### How does CE marking relate to a Digital Product Passport? The DPP and the CE mark serve different purposes — CE attests conformity, the DPP carries structured product data — but they connect: a passport can link to the EU Declaration of Conformity so the conformity evidence is reachable from the same QR. ESPR DPP requirements sit alongside, not instead of, existing CE obligations. ## Related terms - [Economic operator](https://www.tracepass.eu/glossary/economic-operator) - [ESPR](https://www.tracepass.eu/glossary/espr) - [Digital Product Passport (DPP)](https://www.tracepass.eu/glossary/digital-product-passport) - [Source attribution](https://www.tracepass.eu/glossary/source-attribution) --- --- title: Recycled content description: "Recycled content is the proportion of a product or material — usually expressed as a percentage by weight — that comes from recycled rather than virgin feedstock. Under EU law it is becoming a mandatory, verifiable data field: the Battery Regulation (EU) 2023/1542 sets minimum recycled-content shares for key metals, and PPWR (EU) 2025/40 sets recycled-content targets for plastic packaging." canonical: "https://www.tracepass.eu/glossary/recycled-content" locale: en source: "https://www.tracepass.eu/glossary/recycled-content" --- # Recycled content > Recycled content is the proportion of a product or material — usually expressed as a percentage by weight — that comes from recycled rather than virgin feedstock. Under EU law it is becoming a mandatory, verifiable data field: the Battery Regulation (EU) 2023/1542 sets minimum recycled-content shares for key metals, and PPWR (EU) 2025/40 sets recycled-content targets for plastic packaging. Recycled content is the proportion of a product or material — usually expressed as a percentage by weight — that comes from recycled rather than virgin feedstock. Under EU law it is becoming a mandatory, verifiable data field: the Battery Regulation (EU) 2023/1542 sets minimum recycled-content shares for key metals, and PPWR (EU) 2025/40 sets recycled-content targets for plastic packaging. Recycled content stops being a marketing claim and becomes a regulated figure the moment a Digital Product Passport has to report it per unit or per format. The EU Battery Regulation introduces minimum recycled-content shares for cobalt, lead, lithium and nickel that must be documented in the battery passport, phasing in from the late 2020s. PPWR sets minimum recycled-content percentages for plastic packaging, rising over time, that the packaging passport must carry. Because the figure feeds a legal obligation, its provenance matters: a recycled-content percentage needs a defensible source — supplier declarations, mass-balance records, or certification. TracePass treats recycled content as a structured DPP field, pulling the value from supporting documents with a confidence score and source attribution so the published percentage traces back to evidence, and a human approves it before it goes live. ## FAQ ### When do recycled-content rules for batteries apply? The EU Battery Regulation (EU) 2023/1542 phases in minimum recycled-content shares for cobalt, lithium, lead and nickel over the late 2020s and beyond, with the documentation flowing into the battery passport. Exact percentages and start dates per material are set in the Regulation and its implementing acts — check the current text rather than assuming a single date. ### How is recycled content verified for a passport? It needs a traceable basis — supplier declarations, mass-balance accounting or third-party certification — rather than an unsupported claim. In TracePass the percentage enters the DPP as a structured field with a confidence score and a link back to the source document, and a human reviewer approves it before publishing. ## Related terms - [EU Battery Regulation](https://www.tracepass.eu/glossary/eu-battery-regulation) - [PPWR](https://www.tracepass.eu/glossary/ppwr) - [Confidence score](https://www.tracepass.eu/glossary/confidence-score) - [Source attribution](https://www.tracepass.eu/glossary/source-attribution) --- --- title: TracePass founder-led EU DPP infrastructure description: "TracePass LTD: Bulgarian-registered EU Digital Product Passport platform. Founder Malin Ivanov, UIC 208790302, EU PIC 863746977, public ecosystem participation." canonical: "https://www.tracepass.eu/about" locale: en source: "https://www.tracepass.eu/about" --- # TracePass founder-led EU DPP infrastructure > TracePass LTD: Bulgarian-registered EU Digital Product Passport platform. Founder Malin Ivanov, UIC 208790302, EU PIC 863746977, public ecosystem participation. Bulgarian-registered SaaS for EU Digital Product Passport compliance. Single accountable owner, public timeline, verifiable registry entries. TracePass LTD is a Bulgarian-registered company that builds Digital Product Passport (DPP) infrastructure for the EU Ecodesign for Sustainable Products Regulation (ESPR, Regulation (EU) 2024/1781) and the EU Battery Regulation (Regulation (EU) 2023/1542). We are deliberately founder-led and lean. Every regulatory claim, schema decision, and roadmap item has one accountable owner — visible on every page through the reviewer byline. The legal entity, the managing director, the EU Participant Code, and the Bulgarian UIC are all independently verifiable in the registry links below. ## Founder Malin Ivanov is the founder and Managing Director of TracePass LTD. He is the single signatory on every regulatory body TracePass participates in (CIRPASS-2 CoP, GS1 Bulgaria, ecosystem partner agreements) and the named author / reviewer on every regulatory page of this site. Background: a decade of B2B SaaS engineering across EU compliance, payments, and data infrastructure. TracePass was incorporated on 2026-04-27 to ship Digital Product Passport infrastructure for the ESPR deadline cohort (2027 batteries → 2030 most categories). ## Timeline - 2026-04-27 — TracePass LTD incorporated in the Bulgarian Commercial Register (UIC 208790302). - 2026-05-01 — EU Participant Identification Code (PIC) 863746977 issued, enabling participation in EU-funded ecosystem bodies. - 2026-05-17 — First public site launch with 12-category coverage (batteries, textiles, electronics, construction, furniture, packaging, tyres, toys, chemicals, jewelry, iron & steel, FMCG) across 4 locales (EN, BG, DE, IT). - 2026-05-21 — Public v1 API documentation shipped: REST, OpenAPI 3.1 spec, idempotent writes, EPCIS 2.0 export. ## Verifiable registry entries - Bulgarian Commercial Register: [UIC 208790302](https://portal.registryagency.bg/CR/Reports/ActiveConditionTabResult?uic=208790302) - VAT registration (Bulgarian NRA): BG208790302 - EU Participant Identification Code: PIC 863746977 - Google Business Profile: [TracePass on Google](https://g.page/r/Cb4zs-VnG7O5EBM) - Company LinkedIn: [linkedin.com/company/tracepass-eu](https://www.linkedin.com/company/tracepass-eu/) - circular-data.org (CIRPASS-2 Stakeholder Community): [Participant profile](https://circular-data.org/o/892486cd-c05d-4c74-97ca-c18e70bfb934) --- --- title: Trust & security — what we run, where we run it description: "Procurement reference: EU data residency, sub-processor register with DPA links, security, liability, GS1 Digital Link / Schema.org / CIRPASS conformance." canonical: "https://www.tracepass.eu/trust" locale: en source: "https://www.tracepass.eu/trust" --- # Trust & security — what we run, where we run it > Procurement reference: EU data residency, sub-processor register with DPA links, security, liability, GS1 Digital Link / Schema.org / CIRPASS conformance. Procurement-grade reference for data residency, sub-processor disclosures, security posture, liability, and interoperability conformance. Items not yet in place are flagged so readers see what's done versus what's in flight — the buyer's guide cites this page as the single source of truth for both. ## Overview TracePass is a Bulgarian-registered company building a Digital Product Passport platform for EU compliance. We process customer product data on EU infrastructure with documented sub-processors. Customer is the data controller; TracePass is the processor. This page is the single procurement reference for our data path, security controls, liability terms, and interoperability conformance. Updated on every meaningful change; see the date stamp at the foot. ## Data residency Production data resides on EU infrastructure. The application back-end runs on Hetzner Falkenstein; the marketing front-end on Vercel EU edge regions; the primary database is self-hosted MongoDB on the same Hetzner Falkenstein server; file storage on Cloudflare R2 EU regions. AI processing for category extraction and translations is invoked on customer demand only and is governed by an explicit DPA with Anthropic. No customer data is shared with third parties outside the documented sub-processor list. - Application back-end: Hetzner CPX32, Falkenstein, Germany - Marketing front-end: Vercel EU edge regions - Primary database: Self-hosted MongoDB 7, Hetzner Falkenstein, Germany - File storage: Cloudflare R2, EU regions ## Security posture Default-secure infrastructure choices plus application-level controls. Encryption at rest is provided by every storage sub-processor; TLS 1.3 is enforced for all customer traffic. Identity is custom JWT + bcrypt + single-use refresh-token rotation; access controls are role-based (owner, admin, editor, viewer) with rate limiting on every authentication path. - Encryption at rest: File storage (Cloudflare R2) — AES-256. Application database — the database volume is encrypted at rest with LUKS2 (AES-XTS, 512-bit key). Daily logical backups are stored in an encrypted EU bucket. - Encryption in transit: TLS 1.3 - Authentication: JWT (HS256, 15 min) + refresh-token rotation (30 d, single-use, max 5 per user) - Role-based access control: owner > admin > editor > viewer; per-route enforcement - Rate limiting: Login (5/15min/IP), registration (5/min/IP), file upload (60/min/company), v1 API (per plan) - Database backups: Daily automated logical backup to an encrypted EU bucket (Cloudflare R2), 7-day retention, stored off the database server - Audit logs: Every passport edit recorded with timestamp, actor, and field-level diff; surfaced in the dashboard timeline - Security headers: Content-Security-Policy (enforced, nonce-based), HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy - ISO 27001 certification: Not yet held. The controls above (encryption, access control, backups, audit logging) are the substance an ISO 27001 ISMS formalises, but no certificate has been issued and no audit is in progress. We will pursue certification when enterprise customer demand justifies the audit cost; we won't claim it before a certificate exists. Ask us for the current control documentation in the meantime. - SOC 2 report: Not yet held, no audit window scheduled. SOC 2 (Type II in particular) requires an observation period a company of our age and stage has not yet run. Same honesty rule as ISO 27001: we will not represent a SOC 2 report until an auditor has issued one. EU customers are typically served first by our EU data residency + GDPR processor terms, which are documented above and in the DPA. ## Liability & insurance Standard liability cap is 12× monthly fees. Enterprise customers can negotiate a 24× rider for higher exposure profiles. Indemnification carve-outs cover third-party intellectual-property claims and regulatory penalties traceable to vendor error. Errors & Omissions (E&O) insurance is in progress — quote in flight, expected to close shortly. Cap will be published here once the policy binds. - Standard liability cap: 12× monthly fees - Enterprise rider: 24× monthly fees, available on Enterprise contracts - E&O insurance: Quote in flight; cap will be published here once policy binds - [Master Services Agreement](/terms): Substantive clauses live in our public Terms of Service (§10 cancellation + 30-day resolver grace, §11 split SLA, §12 customer-as-controller, §13 source-code escrow on Enterprise). Enterprise customers can negotiate addenda (custom SLA, liability rider, escrow triggers) on top of the standard ToS. ## Interoperability conformance Conformance against published interoperability standards — what's tested, what's documented, what's still pending. "We follow the spec" is not a conformance claim; published test results and documented field-level alignment are. - GS1 Digital Link conformance: Functional resolver behaviour self-tested against the GS1 Digital Link v2.0 spec — service-description endpoint, GTIN/serial path resolution, JSON-LD content negotiation, linkset+json output, Vary headers, 404 on unknown URLs. Reproducible script ships at scripts/gs1-conformance-check.ts (committed to the platform repo); customers and auditors can run it against any TracePass-hosted resolver. External test against GS1's hosted reference suite is scheduled separately. - Schema.org JSON-LD: Emitted on every public page (home, category, resources, regulatory matrices, buyer's guide). Validated against Google Rich Results Test. - JSON-LD content negotiation on passport URLs: Public passport URLs return application/ld+json when the request Accept header explicitly prefers it; HTML otherwise. Same URL contract — no separate endpoint to discover. Implemented via Next.js middleware rewriting to a JSON-LD route handler that serves the same payload as the embedded