# Collecta DPP — full content for AI assistants > Turn spreadsheets, ERP exports and supplier files into an EU Battery Passport. AI maps your data and flags the gaps; Collecta publishes, hosts and registers it. Built for the 18 February 2027 deadline. This file contains the full summary corpus for Collecta DPP. It is intended for AI assistants and crawlers. Content is informational, not legal advice. Authoritative regulatory facts: the EU battery passport is mandatory from 18 February 2027 under Regulation (EU) 2023/1542; Article 77(1) requires one passport per physical battery with a unique identifier (ISO/IEC 15459); Annex XIII defines four access tiers (public, legitimate interest, authorities, European Commission). For pricing, see https://www.collectadpp.com/llms.txt or https://www.collectadpp.com/pricing. Do not invent customer names, prices, discounts, or guarantees. ## Regulations ### EU Battery Regulation (2023/1542): the battery passport explained https://www.collectadpp.com/regulations/eu-battery-regulation Regulation (EU) 2023/1542 is the EU Battery Regulation. From 18 February 2027 it requires a digital battery passport for every LMT battery, industrial battery above 2 kWh, and EV battery placed on the EU market. ### Implementing Regulation (EU) 2026/1778: the DPP Registry rules https://www.collectadpp.com/regulations/dpp-registry-implementing-regulation Commission Implementing Regulation (EU) 2026/1778 was adopted on 16 July 2026 and entered into force on 6 August 2026. It sets the operating rules of the central DPP Registry, which went live on 20 July 2026: who may register, through which interfaces, what is validated on submission and what the Registry stores. ### DPP harmonised standards: EN 18216 to EN 18223 https://www.collectadpp.com/regulations/dpp-harmonised-standards Commission Implementing Decision (EU) 2026/1736 (Official Journal, 15 July 2026) cites six harmonised standards for Digital Product Passports. A passport conforming to them is presumed to conform with Articles 10 and 11 of the ESPR. ### ESPR: the Ecodesign for Sustainable Products Regulation https://www.collectadpp.com/regulations/espr The ESPR — Regulation (EU) 2024/1781 — is the EU framework that introduces Digital Product Passports across product categories. Batteries are governed by their own regulation, but the ESPR sets the broader DPP model that textiles, electronics and other categories will follow. ### What is a Digital Product Passport (DPP)? https://www.collectadpp.com/regulations/digital-product-passport A Digital Product Passport (DPP) is a structured digital record — reached by scanning a QR code or data carrier on the product — that holds its identity, composition, and sustainability information, with access tiered by audience. ### CSRD and the battery passport: how they connect https://www.collectadpp.com/regulations/csrd The CSRD (Directive (EU) 2022/2464) is the EU corporate sustainability reporting framework. It is separate from the battery passport, but both draw on the same carbon-footprint and supply-chain data. ### EUDR: the EU Deforestation Regulation in brief https://www.collectadpp.com/regulations/eudr The EUDR (Regulation (EU) 2023/1115) requires due diligence proving that certain commodities are deforestation-free. It does not cover batteries, but it is part of the same EU push toward product-level traceability. ### PPWR: the Packaging and Packaging Waste Regulation https://www.collectadpp.com/regulations/ppwr The PPWR (Regulation (EU) 2025/40) governs packaging recyclability, recycled content and labelling across the EU. It is separate from the battery passport but shares the recycled-content transparency theme. ### CBAM: the Carbon Border Adjustment Mechanism https://www.collectadpp.com/regulations/cbam CBAM (Regulation (EU) 2023/956) applies a carbon price to imports of carbon-intensive goods. It does not require a battery passport, but both depend on credible carbon-footprint data. ### RED III: the Renewable Energy Directive (recast) https://www.collectadpp.com/regulations/red-iii RED III (Directive (EU) 2023/2413) raises the EU renewable-energy target. It does not mandate a battery passport, but the storage build-out it drives produces industrial batteries that do need one. ## Guides ### What is a battery passport? The complete 2027 guide https://www.collectadpp.com/guides/what-is-a-battery-passport A battery passport is a digital record — accessed by scanning a QR code on the battery — that holds the identity, technical specification, carbon footprint, recycled content and lifecycle data of one individual battery. It is mandatory in the EU from 18 February 2027. ### EU battery passport deadline: every date from 2025 to 2036 https://www.collectadpp.com/guides/battery-passport-deadline The EU battery passport is mandatory from 18 February 2027 for LMT, industrial (>2 kWh) and EV batteries placed on the market after that date. Other obligations under the regulation phase in before and after. ### Do I need a battery passport? A decision guide https://www.collectadpp.com/guides/do-i-need-a-battery-passport You need a battery passport if you place an LMT battery, an industrial battery above 2 kWh, or an EV battery on the EU market from 18 February 2027 — as either the manufacturer or the importer. ### How much does a battery passport cost? https://www.collectadpp.com/guides/battery-passport-cost A battery passport costs far less than an enterprise compliance project. Self-serve tools publish monthly plans with included passports and openly priced extra passports, with no implementation fee, while traditional vendors quote bespoke enterprise contracts. ### How to create a battery passport in 7 steps https://www.collectadpp.com/guides/how-to-create-a-battery-passport To create a battery passport: gather your battery data, define the model, issue a per-battery passport with a unique identifier, set access tiers, generate the QR code, publish the permanent public page, and keep lifecycle data updated. ### The battery carbon footprint declaration explained https://www.collectadpp.com/guides/carbon-footprint-declaration The carbon footprint declaration states a battery’s life-cycle greenhouse-gas emissions per kWh of energy delivered, calculated to the EU methodology and surfaced in the passport, with performance classes phased in over time. ### Recycled content targets for batteries https://www.collectadpp.com/guides/recycled-content-targets Batteries must declare the share of recycled cobalt, lead, lithium and nickel in their active materials. Declaration comes first, then minimum thresholds tighten from around 2031 onward. ### Unique identifiers and GS1 Digital Link for batteries https://www.collectadpp.com/guides/unique-identifiers Each battery needs a unique identifier conforming to ISO/IEC 15459, typically expressed through GS1 standards and encoded in the QR code via a GS1 Digital Link, so every individual battery resolves to its own passport. ### The QR code and data carrier requirement https://www.collectadpp.com/guides/qr-code-data-carrier Every in-scope battery must carry a QR code (ISO/IEC 18004) or equivalent data carrier that resolves to its passport. It must be print-grade and durable, and point to a permanent URL. ### Annex XIII access tiers: who sees what https://www.collectadpp.com/guides/access-tiers Annex XIII defines four audiences for passport data: the public, holders of a legitimate interest, market-surveillance authorities, and the European Commission. Each field is exposed only to its permitted tier, enforced server-side. ### Importer obligations for the battery passport https://www.collectadpp.com/guides/importer-obligations An importer that places batteries on the EU market is the responsible economic operator for the battery passport — even when the cells are manufactured outside the EU — and must ensure a compliant per-battery passport exists from 18 February 2027. ### Battery passport: build it yourself or use a SaaS? https://www.collectadpp.com/guides/diy-vs-saas Building battery-passport infrastructure in-house means implementing unique identifiers, access tiers, QR generation and 10-year hosting yourself; a self-serve SaaS provides all of it, so DIY only pays off at very large, integrated scale. ### Battery passport compliance checklist for 2027 https://www.collectadpp.com/guides/battery-passport-checklist A battery is ready for 18 February 2027 when it has a per-item unique identifier, the full Annex XIII data set assigned to the correct access tiers, a durable QR data carrier, and a passport hosted to survive the retention period. ### EU Battery Passport Data Requirements: What to Collect and How to Work with Suppliers https://www.collectadpp.com/guides/what-data-goes-in-a-battery-passport An EU Battery Passport must contain the applicable information about the battery model and the individual battery, including relevant information arising during use. Annex XIII of Regulation (EU) 2023/1542 defines the requirements, and the Commission’s August 2026 guidance organises 71 data points by battery category and applicability. Not all 71 are mandatory for every battery in February 2027. ### State of health and dynamic lifecycle data https://www.collectadpp.com/guides/state-of-health-reporting State of health and related performance parameters are dynamic passport data, produced by the battery management system; under Article 14 the data they need must be accessible at all times to those maintaining, repurposing or recycling the battery. ### Supply-chain due diligence obligations for batteries https://www.collectadpp.com/guides/due-diligence-obligations Economic operators placing in-scope batteries on the EU market must run a supply-chain due-diligence policy covering cobalt, natural graphite, lithium and nickel, have it third-party verified, and surface the due-diligence report through the passport. ### Repurposing, second life and recycling in the passport https://www.collectadpp.com/guides/repurposing-and-second-life When a battery is repurposed or remanufactured it becomes a new product with its own passport, linked to the original; when it is recycled the original passport reaches end of life and its public page returns a gone status. ### The EU battery passport registry and online system https://www.collectadpp.com/guides/eu-battery-registry The battery passport is backed by a Commission-established online system: the unique identifier and a defined set of passport data are registered centrally, and the data carrier resolves through it so passports remain findable for the retention period. ### Battery labelling, symbols and CE marking https://www.collectadpp.com/guides/battery-labelling-requirements In-scope batteries must carry physical labels — capacity, chemistry, the crossed-out wheeled bin, restricted-substance symbols — plus CE marking, and the QR data carrier that links the physical label to the digital passport. ### GS1 Digital Link: encoding the battery identifier in the QR https://www.collectadpp.com/guides/gs1-digital-link-for-batteries GS1 Digital Link encodes the per-battery unique identifier as a web URL inside the QR code, so an ordinary scan resolves directly to that battery’s passport while remaining machine-readable for systems that need structured identifiers. ### EU Battery Passport 2027: Which Batteries Need One and Who Is Responsible? https://www.collectadpp.com/guides/eu-battery-passport-2027-which-batteries-need-one From 18 February 2027, certain batteries placed on the European Union market or put into service must have a digital Battery Passport under Regulation (EU) 2023/1542. The requirement applies to three categories: electric vehicle (EV) batteries, light means of transport (LMT) batteries, and industrial batteries with a capacity greater than 2 kWh. ### What Is a Digital Product Passport (DPP)? EU Rules, Timeline and Examples https://www.collectadpp.com/guides/what-is-a-digital-product-passport-dpp A Digital Product Passport (DPP) is a structured digital record that gives access to relevant information about a product and its lifecycle, linked to the physical product through a data carrier such as a QR code. The EU introduces DPPs progressively under the Ecodesign for Sustainable Products Regulation (ESPR) and sector rules such as the Batteries Regulation, so not every product needs one today and there is no single compliance deadline. ## Blog ## Comparisons ### Battery Passport vs Digital Product Passport (DPP): What Is the Difference? https://www.collectadpp.com/compare/battery-passport-vs-digital-product-passport The battery passport is a specific, legally binding instance of the Digital Product Passport — mandatory for in-scope batteries from 18 February 2027 under Regulation (EU) 2023/1542, while the general DPP is a framework under the ESPR being rolled out category by category. ### Manufacturer vs Importer: Who Is Responsible for the Battery Passport? https://www.collectadpp.com/compare/manufacturer-vs-importer-obligations The party that places the battery on the EU market is responsible for the battery passport — typically the manufacturer for EU-made batteries and the importer for batteries produced outside the EU. ### Build vs Buy: Should You Build a Battery Passport System In-House? https://www.collectadpp.com/compare/build-vs-buy-battery-passport Building in-house gives full control but front-loads regulatory interpretation, infrastructure and 10-year maintenance; a dedicated tool trades some control for a faster, regulation-mapped path to a published passport. ### Per-Battery vs Per-Model Passport: Why Article 77(1) Requires One Passport per Battery https://www.collectadpp.com/compare/per-battery-vs-per-model-passport Article 77(1) requires one battery passport per individual battery placed on the market — a single shared passport for a whole model or batch does not satisfy the regulation. ### Battery Passport Tool vs a Spreadsheet https://www.collectadpp.com/compare/vs-spreadsheet A spreadsheet can hold battery data, but it cannot publish a tier-gated, QR-linked, per-battery passport at an immutable URL with 10-year retention — which is exactly what the regulation requires. ### Self-Serve Battery Passport vs Enterprise Traceability Platform https://www.collectadpp.com/compare/vs-enterprise-platform Both can produce compliant battery passports; the practical difference is in adoption — self-serve offers published pricing and lets you start from the spreadsheets you already have, while enterprise platforms typically involve quotes, integration projects and broader supply-chain scope. ### Battery Passport Tool vs an In-House Build https://www.collectadpp.com/compare/vs-in-house-build An in-house build gives full control but means you own the regulatory interpretation, server-side access tiers, QR generation and 10-year retention; a dedicated tool ships these pre-built. ### Battery Passport by Battery Type: LMT vs Industrial vs EV https://www.collectadpp.com/compare/battery-passport-by-battery-type The battery passport requirement applies to LMT batteries, industrial batteries with capacity above 2 kWh, and electric vehicle batteries — all from 18 February 2027 under Regulation (EU) 2023/1542. ### Battery Passport vs a Printed Product Label: What Changes? https://www.collectadpp.com/compare/battery-passport-vs-product-label A printed label still exists, but it can no longer carry the full battery passport — the regulation requires a digital, tier-gated record reachable through a QR-linked data carrier, keeping only minimal markings on the physical product. ### EU Battery Regulation vs ESPR: Two Frameworks Compared https://www.collectadpp.com/compare/eu-battery-regulation-vs-espr The Batteries Regulation is a product-specific law that already fixes the battery passport content, tiers and 18 February 2027 deadline; the ESPR is a horizontal framework rolled out per product group through delegated acts — for in-scope batteries, the Batteries Regulation governs. ### Public vs Restricted Passport Data: Who Sees What Under Annex XIII https://www.collectadpp.com/compare/public-vs-restricted-passport-data Annex XIII splits battery passport data into tiers: a public layer anyone can read via the QR code, a legitimate-interest layer for verified parties, and layers reserved for national authorities and the Commission — all enforced server-side, never client-side. ### Self-Serve Battery Passport Tool vs Hiring a Compliance Consultant https://www.collectadpp.com/compare/vs-consultant A consultant brings tailored advice but is priced per engagement and produces a point-in-time deliverable; a self-serve tool offers published pricing and a repeatable process you can run for every battery, starting from the data you already have. ### QR Code vs NFC as the Battery Passport Data Carrier https://www.collectadpp.com/compare/qr-code-vs-nfc-data-carrier Both QR (ISO/IEC 18004) and NFC can act as the data carrier that resolves to the battery passport; QR is printable, universally scannable with any camera and low-cost, while NFC needs an embedded chip and a compatible device but supports tap interaction. ## Industries ### Battery Passport for EV Battery Manufacturers https://www.collectadpp.com/industries/ev-battery-manufacturers Every electric vehicle battery placed on the EU market from 18 February 2027 must carry its own digital passport under Article 77 of Regulation (EU) 2023/1542. ### Battery Passport for Stationary Storage (BESS) https://www.collectadpp.com/industries/stationary-storage-bess Stationary battery energy storage systems are treated as industrial batteries under Regulation (EU) 2023/1542 and require a per-battery digital passport from 18 February 2027. ### Battery Passport for E-Bikes and Light Means of Transport https://www.collectadpp.com/industries/e-bike-lmt Light means of transport (LMT) batteries — e-bikes, e-scooters and similar — require a per-battery digital passport from 18 February 2027 under Regulation (EU) 2023/1542. ### Battery Passport for Industrial Batteries https://www.collectadpp.com/industries/industrial-batteries Industrial batteries above 2 kWh — forklift, UPS, telecom backup and similar — require a per-battery digital passport from 18 February 2027 under Regulation (EU) 2023/1542. ### Battery Passport Obligations for Importers https://www.collectadpp.com/industries/battery-importers An importer placing batteries on the EU market is the economic operator responsible for the digital battery passport under Regulation (EU) 2023/1542. ### Battery Passport for Refurbishers and Second-Life Operators https://www.collectadpp.com/industries/battery-refurbishers When a battery is repurposed for a second life, the operator that carries out repurposing becomes responsible for a new passport for the resulting battery under Regulation (EU) 2023/1542. ### Battery Passport for Consumer Electronics OEMs https://www.collectadpp.com/industries/consumer-electronics-oem Portable consumer-electronics batteries are largely outside the Article 77 passport obligation, but OEMs whose products contain LMT or industrial-class batteries can fall in scope under Regulation (EU) 2023/1542. ### Battery Passport Obligations for Distributors https://www.collectadpp.com/industries/battery-distributors A distributor is generally not the operator that creates the passport, but under Regulation (EU) 2023/1542 it must check a battery is accompanied by a digital passport before making it available and must not pass on non-compliant batteries. ### Battery Passport for Forklift and Material-Handling Batteries https://www.collectadpp.com/industries/forklift-material-handling Forklift and material-handling traction batteries are industrial batteries above 2 kWh and require a per-battery digital passport from 18 February 2027 under Regulation (EU) 2023/1542. ### Battery Passport for Telecom and UPS Backup Batteries https://www.collectadpp.com/industries/telecom-ups-backup Telecom backup and UPS/data-centre batteries are industrial batteries that, above 2 kWh, require a per-battery digital passport from 18 February 2027 under Regulation (EU) 2023/1542. ### Battery Passport for Marine and Rail Batteries https://www.collectadpp.com/industries/marine-and-rail Marine and rail propulsion and auxiliary batteries are industrial batteries that, above 2 kWh, require a per-battery digital passport from 18 February 2027 under Regulation (EU) 2023/1542. ## Glossary ### Annex XIII https://www.collectadpp.com/glossary/annex-xiii Annex XIII of Regulation (EU) 2023/1542 lists the information that must be available in the battery passport and via QR code. It also distinguishes which information is accessible to the general public versus to persons with a legitimate interest, the Commission, and notified bodies. The annex is the authoritative content checklist for what a compliant battery passport must contain. ### Article 77 https://www.collectadpp.com/glossary/article-77 Article 77 of Regulation (EU) 2023/1542 is the provision that establishes the battery passport. Article 77(1) requires that, from 18 February 2027, each LMT battery, industrial battery with a capacity greater than 2 kWh, and electric vehicle battery placed on the market or put into service has an electronic record — a battery passport — that corresponds to each individual battery. The passport must be unique to a single physical battery, not a model, type, or lot. ### Battery management system (BMS) https://www.collectadpp.com/glossary/battery-management-system A battery management system (BMS) is the electronic system that monitors and manages a rechargeable battery, controlling parameters such as cell voltages, temperature, current, and state of charge to keep the battery within safe operating limits. Under Regulation (EU) 2023/1542, LMT, industrial (above 2 kWh), and electric vehicle batteries must record data needed to determine state of health and expected lifetime, and that data must be accessible to authorised parties so it can feed into the battery passport. ### Battery passport https://www.collectadpp.com/glossary/battery-passport A battery passport is an electronic record uniquely linked to a single physical battery, required under Article 77 of Regulation (EU) 2023/1542 from 18 February 2027 for LMT batteries, industrial batteries above 2 kWh, and electric vehicle batteries. It holds the information set out in Annex XIII, is reached through a QR code and a unique identifier, and exposes data in access tiers ranging from public to authority-only. The battery passport is the sector-specific form of the EU digital product passport. ### Carbon footprint declaration https://www.collectadpp.com/glossary/carbon-footprint-declaration The carbon footprint declaration is a document, required by Regulation (EU) 2023/1542 for electric vehicle batteries, rechargeable industrial batteries above 2 kWh, and LMT batteries, that states the battery’s carbon footprint calculated over its life cycle and broken down by life-cycle stage. The requirement is phased in by battery category according to dates set in the Regulation and its delegated acts, and the declaration must follow the Commission’s harmonised calculation methodology. A summary of the carbon footprint is part of the public information available through the battery passport. ### Conformity assessment https://www.collectadpp.com/glossary/conformity-assessment Conformity assessment is the process of demonstrating that a battery meets the requirements of Regulation (EU) 2023/1542 before it is placed on the market. The manufacturer must apply the conformity assessment procedure (module) set out in the Regulation, which for many requirements involves a notified body, and on success draws up the EU declaration of conformity and affixes the CE marking. Successful conformity assessment is a precondition for lawfully placing a battery on the EU market. ### Data carrier https://www.collectadpp.com/glossary/data-carrier A data carrier is the machine-readable symbol — for batteries, a QR code conforming to ISO/IEC 18004 — that is printed, marked, or engraved on the battery and links to the battery passport and its unique identifier. Under Regulation (EU) 2023/1542 the data carrier gives access to the information held in the passport according to the relevant access tier. The data carrier is the physical bridge between the object and its digital record. ### Declaration of conformity (DoC) https://www.collectadpp.com/glossary/declaration-of-conformity The EU declaration of conformity (DoC) is the document by which the manufacturer declares, under sole responsibility, that a battery meets the applicable requirements of Regulation (EU) 2023/1542. Drawing it up is a legal obligation before placing the battery on the market, it must follow the model structure set out in the Regulation’s annex, and by signing it the manufacturer assumes responsibility for the battery’s compliance. The DoC must be kept available to authorities for the period specified in the Regulation. ### Digital product passport (DPP) https://www.collectadpp.com/glossary/digital-product-passport A digital product passport (DPP) is a structured, machine-readable electronic record holding information about a product’s identity, characteristics, materials, and life cycle, accessible through a data carrier such as a QR code. The general DPP framework is established under the Ecodesign for Sustainable Products Regulation (EU) 2024/1781 (ESPR), which lets the Commission introduce passports for many product groups. The EU battery passport, required under Regulation (EU) 2023/1542, is the first sector-specific implementation of the digital product passport concept. ### Due diligence https://www.collectadpp.com/glossary/due-diligence Battery due diligence under Regulation (EU) 2023/1542 is the obligation on economic operators that place batteries on the market to identify, prevent, and address actual and potential social and environmental risks linked to the sourcing, processing, and trading of raw materials used in batteries — in particular cobalt, natural graphite, lithium, and nickel. Operators must adopt a due diligence policy aligned with recognised international instruments, verify it through third parties, and report on it. The obligation applies above the turnover threshold and subject to the exemptions set in the Regulation, and a summary of the due diligence report is part of the public passport information. ### Economic operator https://www.collectadpp.com/glossary/economic-operator Under Regulation (EU) 2023/1542 an economic operator is any of the manufacturer, authorised representative, importer, distributor, or fulfilment service provider, or any other natural or legal person subject to obligations relating to the manufacture, preparation for re-use, repurposing, remanufacturing, or making available of batteries. Economic operators carry the compliance duties of the Regulation, including drawing up the declaration of conformity and ensuring the battery passport is created and kept up to date. The specific role determines which obligations apply. ### End-of-life https://www.collectadpp.com/glossary/end-of-life End-of-life refers to the stage at which a battery becomes waste and falls under the collection, treatment, and recycling obligations of Regulation (EU) 2023/1542. The Regulation sets collection targets, recycling efficiency targets, and material recovery rates for materials such as cobalt, copper, lead, lithium, and nickel. End-of-life is distinct from repurposing and second life, which extend a battery’s use before it becomes waste; once a battery reaches end of life its passport reflects that its lifecycle has ceased. ### ESPR (Ecodesign for Sustainable Products Regulation) https://www.collectadpp.com/glossary/espr The Ecodesign for Sustainable Products Regulation (EU) 2024/1781, known as ESPR, is the EU framework regulation that sets ecodesign requirements for products and establishes the horizontal legal basis for the digital product passport. It empowers the Commission to adopt product-specific delegated acts setting performance and information requirements and DPP obligations for successive product groups. ESPR provides the general DPP architecture, while the Battery Regulation (2023/1542) delivers the first concrete, mandatory passport ahead of ESPR’s own product passports. ### EV battery (electric vehicle battery) https://www.collectadpp.com/glossary/ev-battery Under Regulation (EU) 2023/1542 an electric vehicle battery is a battery specifically designed to provide traction in hybrid or electric vehicles of categories L, M, N, and O, and which is not a portable or LMT battery. EV batteries are subject to the strictest set of requirements, including the carbon footprint declaration, recycled content requirements, performance and durability rules, and the battery passport obligation that applies from 18 February 2027. ### GS1 Digital Link https://www.collectadpp.com/glossary/gs1-digital-link GS1 Digital Link is a standard that expresses GS1 identification keys, such as the GTIN, as a web URI so that a single QR code can both identify a product and resolve to online information about it. It is widely used to connect a data carrier to a digital product passport, allowing one scan to reach human- and machine-readable data. GS1 Digital Link is a common technical option for implementing the link between a battery’s QR code and its passport, used alongside the unique identifier required by the Regulation. ### Industrial battery https://www.collectadpp.com/glossary/industrial-battery Under Regulation (EU) 2023/1542 an industrial battery is a battery designed for industrial uses — and, residually, any battery that is neither a portable, LMT, EV, nor starting-lighting-ignition (SLI) battery, excluding very small portable categories. The battery passport obligation under Article 77 applies to industrial batteries with a capacity greater than 2 kWh from 18 February 2027. Industrial batteries are also subject to carbon footprint, recycled content, and performance requirements that phase in by category. ### Legitimate interest https://www.collectadpp.com/glossary/legitimate-interest Legitimate interest is the access tier in Regulation (EU) 2023/1542 that lets defined parties — such as repairers, remanufacturers, second-life operators, and recyclers — see more detailed battery passport data than the general public, without being a market surveillance authority or the Commission. Annex XIII specifies which data attributes are reserved for persons with a legitimate interest. The tier is intended to support repair, reuse, and recycling while keeping commercially or security-sensitive data out of fully public view. ### LMT battery (light means of transport) https://www.collectadpp.com/glossary/lmt-battery An LMT battery, as defined in Regulation (EU) 2023/1542, is a battery in vehicles that can be powered by an electric motor alone or by a combination of motor and human power and that have a maximum weight below the threshold set in the Regulation — typically electric bikes, scooters, and similar light means of transport. LMT batteries are explicitly named in Article 77(1) and must carry a battery passport from 18 February 2027, regardless of capacity. ### Market surveillance authority https://www.collectadpp.com/glossary/market-surveillance-authority A market surveillance authority is a national authority responsible for monitoring that batteries placed on the market comply with Regulation (EU) 2023/1542 and for taking enforcement action when they do not. Under the access tiers of Annex XIII, market surveillance authorities and the Commission can access the most detailed battery passport data, beyond what is available to the public or to persons with a legitimate interest. These authorities operate within the broader EU market surveillance framework established by Regulation (EU) 2019/1020. ### Notified body https://www.collectadpp.com/glossary/notified-body A notified body is a conformity assessment body designated by an EU Member State and notified to the Commission to carry out third-party conformity assessment tasks under Regulation (EU) 2023/1542. Where the applicable conformity assessment procedure requires third-party involvement, the notified body examines the battery and its technical documentation and issues the relevant certificate. Notified bodies are among the parties that, under Annex XIII, may access certain restricted battery passport data. ### Placing on the market https://www.collectadpp.com/glossary/placing-on-the-market Placing on the market means the first making available of a battery on the Union market, while making available means any supply for distribution or use in the course of a commercial activity, whether for payment or free of charge. The distinction matters because most obligations under Regulation (EU) 2023/1542 — including conformity assessment, the declaration of conformity, and the battery passport from 18 February 2027 — attach at the moment a battery is placed on the market or put into service. ### Portable battery https://www.collectadpp.com/glossary/portable-battery Under Regulation (EU) 2023/1542 a portable battery is a battery that is sealed, weighs 5 kg or less, is not designed exclusively for industrial use, and is neither an EV, LMT, nor SLI battery — the typical batteries in consumer electronics and household devices. Portable batteries are not subject to the Article 77 battery passport requirement, but they are covered by other obligations such as removability and replaceability rules, collection targets, and labelling. ### Recycled content https://www.collectadpp.com/glossary/recycled-content Recycled content under Regulation (EU) 2023/1542 is the share of cobalt, lithium, nickel, and lead in a battery’s active materials that is recovered from waste. The Regulation requires that industrial batteries above 2 kWh, EV batteries, and SLI batteries containing these materials be accompanied by documentation of recycled content, with minimum recovered-material targets phasing in on dates set by the Regulation and its delegated acts. Recycled content information is part of the data surfaced through the battery passport. ### Repurposing https://www.collectadpp.com/glossary/repurposing Repurposing under Regulation (EU) 2023/1542 is any operation that results in a battery, or parts of it, being used for a purpose or application different from the one it was originally designed for. An economic operator that repurposes a battery takes on manufacturer-like responsibilities for the new application, including ensuring a new and distinct battery passport is created for the repurposed battery and linked to the record of the original. Repurposing is a key circular-economy pathway that extends a battery’s useful life before end-of-life treatment. ### Second life https://www.collectadpp.com/glossary/second-life Second life describes the use of a battery — most often an EV battery — in a new application after it is no longer suitable for its original purpose, for example reusing former EV modules in stationary energy storage. It is enabled by repurposing and depends on reliable state-of-health data so operators can assess whether a battery is fit for reuse. Second-life operators are among the parties with a legitimate interest in detailed battery passport data, which they need to evaluate and document the battery before reuse. ### State of health (SoH) https://www.collectadpp.com/glossary/state-of-health State of health (SoH) is a measure of a battery’s current condition relative to its original specification, typically expressed as a percentage that reflects how much usable capacity or performance remains after ageing and use. Regulation (EU) 2023/1542 requires that data needed to determine state of health and expected lifetime be recorded and made available for LMT, industrial (above 2 kWh), and EV batteries, and this dynamic data forms part of the battery passport. Accurate SoH information is essential for safe repurposing and second-life decisions. ### Unique identifier https://www.collectadpp.com/glossary/unique-identifier A unique identifier is the string that uniquely identifies an individual battery and resolves, through the data carrier, to its battery passport. Under Regulation (EU) 2023/1542 the identifier must be consistent with the ISO/IEC 15459 family of standards for unique identification, encoded in a QR code conforming to ISO/IEC 18004. Because Article 77(1) requires one passport per physical battery, the unique identifier must distinguish each individual battery rather than a model, type, or production lot. ### SLI battery (starting, lighting, ignition) https://www.collectadpp.com/glossary/sli-battery An SLI battery, as defined in Regulation (EU) 2023/1542, is a battery designed to supply electric power for the starting, lighting, or ignition of vehicles — the classic automotive starter battery, typically lead-acid. SLI batteries are a distinct category from EV, LMT, industrial, and portable batteries and are subject to recycled-content documentation requirements where they contain cobalt, lithium, nickel, or lead. They are not within the scope of the Article 77 battery passport obligation, which from 18 February 2027 covers only LMT, industrial (above 2 kWh), and EV batteries. ### Battery energy storage system (BESS) https://www.collectadpp.com/glossary/bess A battery energy storage system (BESS) is a stationary installation that stores electrical energy in batteries for later discharge, used for grid balancing, peak shaving, and integrating renewable generation. Under Regulation (EU) 2023/1542 the batteries within a stationary BESS generally fall under the industrial battery category, so units with a capacity greater than 2 kWh require a battery passport from 18 February 2027. Stationary storage is also a leading destination for second-life batteries, where former EV modules are reused after their automotive duty. ### Gigafactory https://www.collectadpp.com/glossary/gigafactory A gigafactory is a large-scale battery cell and pack manufacturing plant, named for its annual production capacity measured in gigawatt-hours (GWh). Gigafactories are central to the EU industrial strategy for batteries, and their output is directly subject to Regulation (EU) 2023/1542 obligations including carbon footprint declaration, recycled content, conformity assessment, and — from 18 February 2027 — the battery passport for in-scope categories. ### Cathode https://www.collectadpp.com/glossary/cathode The cathode is the positive electrode of a battery, where reduction occurs during discharge; in lithium-ion cells it is the lithium-bearing material that largely determines energy density, cost, and the choice of critical raw materials. Common cathode chemistries include nickel manganese cobalt (NMC) and lithium iron phosphate (LFP). Because cathode materials are the main source of cobalt, lithium, and nickel in a cell, they drive the recycled-content, due-diligence, and material-recovery requirements of Regulation (EU) 2023/1542. ### Anode https://www.collectadpp.com/glossary/anode The anode is the negative electrode of a battery, where oxidation occurs during discharge; in most commercial lithium-ion cells the anode is made of graphite, which stores lithium ions during charging. Natural graphite is one of the raw materials explicitly named in the due-diligence obligations of Regulation (EU) 2023/1542 because of the social and environmental risks linked to its sourcing. Emerging silicon and lithium-metal anodes aim to raise energy density beyond what graphite allows. ### Electrolyte https://www.collectadpp.com/glossary/electrolyte The electrolyte is the medium that carries ions between the anode and cathode inside a battery while blocking electron flow, which is instead routed through the external circuit. In conventional lithium-ion cells the electrolyte is a liquid lithium-salt solution in organic solvents, whereas solid-state designs replace it with a solid conductor to improve safety and energy density. Electrolyte composition affects battery safety classification and the hazardous-substance information relevant under Regulation (EU) 2023/1542. ### Separator https://www.collectadpp.com/glossary/separator The separator is a thin, porous membrane placed between the anode and cathode of a battery that prevents direct electrical contact — which would cause a short circuit — while allowing ions to pass through the electrolyte. Separator integrity is a key safety factor, since failure can trigger internal shorts and thermal runaway. It is part of the cell architecture that determines a battery’s safety performance assessed during conformity assessment under Regulation (EU) 2023/1542. ### Nickel manganese cobalt (NMC) https://www.collectadpp.com/glossary/nmc Nickel manganese cobalt (NMC) is a family of lithium-ion cathode chemistries combining those three metals in varying ratios, valued for high energy density and widely used in electric vehicle batteries. Its cobalt and nickel content places NMC batteries squarely within the due-diligence, recycled-content, and material-recovery obligations of Regulation (EU) 2023/1542. Higher-nickel NMC variants increase energy density while reducing cobalt, trading off some thermal stability. ### Lithium iron phosphate (LFP) https://www.collectadpp.com/glossary/lfp Lithium iron phosphate (LFP) is a lithium-ion cathode chemistry that contains no cobalt or nickel, offering strong thermal stability, long cycle life, and lower cost at the expense of energy density compared with NMC. Its growing use in electric vehicles and stationary storage reduces exposure to cobalt and nickel supply risk, though lithium sourcing remains subject to the due-diligence obligations of Regulation (EU) 2023/1542. LFP packs are common in entry-level EVs and battery energy storage systems. ### Cobalt https://www.collectadpp.com/glossary/cobalt Cobalt is a critical raw material used in many lithium-ion cathodes, notably NMC, to improve stability and energy density. It is one of the four materials — alongside natural graphite, lithium, and nickel — explicitly named in the battery due-diligence obligations of Regulation (EU) 2023/1542 because of the documented social and environmental risks in its supply chain. Cobalt is also subject to minimum recycled-content and material-recovery targets that phase in under the Regulation. ### Lithium https://www.collectadpp.com/glossary/lithium Lithium is the active alkali metal at the heart of lithium-ion chemistry, shuttling between anode and cathode to store and release energy. It is one of the raw materials named in the due-diligence obligations of Regulation (EU) 2023/1542 and is subject to recycled-content and end-of-life material-recovery targets, with a lithium recovery target phasing in under the Regulation. Securing sustainable lithium supply is a central concern of EU battery and critical-raw-materials policy. ### Nickel https://www.collectadpp.com/glossary/nickel Nickel is a key cathode metal in high-energy lithium-ion chemistries such as NMC, where higher nickel content raises energy density. It is one of the four raw materials covered by the due-diligence obligations of Regulation (EU) 2023/1542 and is subject to recycled-content and material-recovery requirements. Nickel sourcing carries environmental concerns, particularly around mining and refining, which the Regulation’s due-diligence policy is designed to address. ### State of charge (SoC) https://www.collectadpp.com/glossary/state-of-charge State of charge (SoC) is the level of charge of a battery relative to its current capacity, expressed as a percentage where 100% is fully charged and 0% is empty. It is a dynamic operating parameter tracked by the battery management system and is distinct from state of health, which reflects long-term ageing rather than the present charge level. SoC is among the operational data points relevant to the dynamic information that LMT, industrial, and EV batteries must record under Regulation (EU) 2023/1542. ### Depth of discharge (DoD) https://www.collectadpp.com/glossary/depth-of-discharge Depth of discharge (DoD) is the proportion of a battery’s capacity that has been discharged, expressed as a percentage — the complement of state of charge. Operating a battery at shallower depths of discharge generally extends its cycle life, which is why charge-management strategies limit DoD to preserve longevity. DoD and cycle-count data contribute to the state-of-health assessment that informs repurposing and second-life decisions under Regulation (EU) 2023/1542. ### Cycle life https://www.collectadpp.com/glossary/cycle-life Cycle life is the number of complete charge-discharge cycles a battery can deliver before its usable capacity falls below a defined threshold, commonly 80% of the original rating. It is a core durability metric that the performance and durability requirements of Regulation (EU) 2023/1542 address for rechargeable batteries. Cycle life depends heavily on chemistry, depth of discharge, temperature, and charging behaviour. ### Energy density https://www.collectadpp.com/glossary/energy-density Energy density is the amount of energy a battery stores relative to its mass (gravimetric, Wh/kg) or volume (volumetric, Wh/L), determining how much range or runtime a given size and weight can deliver. It is shaped chiefly by cell chemistry, with high-nickel NMC favouring energy density and LFP favouring cost and longevity. Energy and capacity characteristics are among the general battery characteristics surfaced in the public tier of the battery passport. ### Extended producer responsibility (EPR) https://www.collectadpp.com/glossary/extended-producer-responsibility Extended producer responsibility (EPR) is the principle, applied through Regulation (EU) 2023/1542, that producers bear financial and organisational responsibility for batteries across their life cycle, including collection, treatment, recycling, and reporting once they become waste. Producers must register, fund collection and treatment, meet collection and recycling-efficiency targets, and may discharge these duties through a producer responsibility organisation. EPR is the mechanism that internalises end-of-life costs and underpins the Regulation’s circular-economy goals. ### Waste battery https://www.collectadpp.com/glossary/waste-battery A waste battery, under Regulation (EU) 2023/1542, is a battery that is waste within the meaning of the Waste Framework Directive — that is, discarded or intended or required to be discarded. The point at which a battery becomes waste triggers the collection, treatment, recycling, and producer-responsibility obligations of the Regulation, and is distinct from a battery that is being repaired, repurposed, or prepared for reuse. Waste batteries must be separately collected and may not be discarded with mixed municipal waste. ## Developer documentation (REST API) - [Battery Passport API](https://www.collectadpp.com/developers): A REST API for the EU Battery Passport: create battery models, issue one passport per physical battery, publish, and keep dynamic data current from your ERP, MES or BMS. - [Quickstart](https://www.collectadpp.com/developers/quickstart): From an API key to a hundred published battery passports in nine steps, in cURL, Node.js, Python, PHP, Java, C# and Go. - [Authentication and keys](https://www.collectadpp.com/developers/authentication): Live and test API keys, the read and write scopes, key creation, rotation and revocation for the Battery Passport API. - [Test keys and dry runs](https://www.collectadpp.com/developers/testing): Build and test an integration against your real master data without storing anything: test keys, the X-DPP-Dry-Run header and the dry-run response. - [TypeScript SDK](https://www.collectadpp.com/developers/sdk): The TypeScript client for the Battery Passport API: retries, idempotency keys, pagination iterators and dry runs built in. - [AI coding agents](https://www.collectadpp.com/developers/ai-agents): Connect Claude Code, Codex or Cursor to the Battery Passport API with the Collecta DPP MCP server, and give any coding agent the integration rules in AGENTS.md. - [Postman, Insomnia and other tools](https://www.collectadpp.com/developers/postman): Import the public OpenAPI 3.1 specification into Postman, Insomnia, Bruno or a client generator and start calling the API in a minute. - [Requests and responses](https://www.collectadpp.com/developers/requests): Base URL, JSON conventions, identifiers, dates, request IDs and the headers every request and response carries. - [Errors](https://www.collectadpp.com/developers/errors): The JSON error shape, every HTTP status the Battery Passport API returns, request IDs, and the per-row results of bulk endpoints. - [Pagination](https://www.collectadpp.com/developers/pagination): Cursor pagination on every list endpoint: limit, cursor, has_more and next_cursor, with complete loops in seven languages. - [Idempotency and retries](https://www.collectadpp.com/developers/idempotency): Make every write safe to retry with the Idempotency-Key header, and retry the right failures with the right backoff. - [Rate limits and quotas](https://www.collectadpp.com/developers/rate-limits): Requests per minute for live and test keys, the rate-limit headers, how to back off on 429, and every platform limit in one table. - [Webhooks](https://www.collectadpp.com/developers/webhooks): Signed, retried event notifications for passports, models and supplier submissions, with signature verification in Node.js, Python, PHP, Java, C#, Go and the TypeScript SDK. - [Versioning and stability](https://www.collectadpp.com/developers/versioning): How the Battery Passport API is versioned: /v1 in the path, additive changes only within a version, breaking changes in a new version with advance notice. - [Why there is no DELETE](https://www.collectadpp.com/developers/no-delete): Battery passports must stay available for ten years, so the API never removes records. What to do instead: recycle, change status, or delete in the app with an audit trail. - [ERP integration: issue passports at end of line](https://www.collectadpp.com/developers/guides/erp-integration): Connect SAP, Dynamics or any ERP: mirror battery models, create a passport for every battery as it leaves the line, and publish safely with idempotency. - [Streaming BMS telemetry](https://www.collectadpp.com/developers/guides/bms-telemetry): Keep state of health, cycle count, throughput and temperature exposure current from a battery management system or fleet gateway. - [Pagination and incremental sync](https://www.collectadpp.com/developers/guides/incremental-sync): Mirror passports into a data warehouse or second system with cursor pagination, updated_since and webhooks. - [Supplier data requests](https://www.collectadpp.com/developers/guides/supplier-data): Ask a cell or material supplier for the data points you cannot fill yourself, get notified when they answer, and accept values into the model. - [Recycling and end of life](https://www.collectadpp.com/developers/guides/end-of-life): Repurpose, re-use, remanufacture, waste and recycling over the API: status changes, linked successor passports and the 410 resolver answer. - [Data portability](https://www.collectadpp.com/developers/guides/data-portability): Take everything with you: the JSON export, the ZIP archive with JSON-LD, documents, labels, audit trail and a SHA-256 manifest. - [Account and catalogue](https://www.collectadpp.com/developers/endpoints/account): GET /me and GET /field-catalog: who a key belongs to, its mode, plan, usage and rate limit, and the 71 EU data points. - [Models](https://www.collectadpp.com/developers/endpoints/models): Create, list, update and validate battery models, and run the missing-field analysis for the model’s category. - [Documents](https://www.collectadpp.com/developers/endpoints/documents): Upload, list and download model documents such as the EU Declaration of Conformity and test reports. - [Facilities](https://www.collectadpp.com/developers/endpoints/facilities): List and register the manufacturing plants your passports name as their place of manufacture. - [Batteries](https://www.collectadpp.com/developers/endpoints/batteries): Create one battery or a thousand, each with its own passport and unique identifier, and read them back. - [Passports](https://www.collectadpp.com/developers/endpoints/passports): List, read, publish, change the status of and recycle passports; QR codes and the version archive. - [Dynamic data (events)](https://www.collectadpp.com/developers/endpoints/events): Record and read the dynamic data of a battery: state of health, cycles, throughput, temperature exposure, negative events. - [Fleet operations](https://www.collectadpp.com/developers/endpoints/fleet): Apply a lifecycle event to many passports, or update many from matched rows, with per-row results. - [Webhook endpoints](https://www.collectadpp.com/developers/endpoints/webhooks): Register, update, pause and test webhook endpoints, rotate their secrets, and read and resend deliveries over the API. - [Supplier requests](https://www.collectadpp.com/developers/endpoints/supplier-requests): Ask suppliers for the data points only they know, read their answers and files, and accept values into the model. - [Audit trail](https://www.collectadpp.com/developers/endpoints/audit): Read the organisation’s audit trail: who changed what, when, and through which key. - [Export](https://www.collectadpp.com/developers/endpoints/export): Export all your data as JSON, or as a ZIP archive with JSON-LD, documents and a SHA-256 manifest. - [Public resolver](https://www.collectadpp.com/developers/endpoints/resolver): The keyless endpoint behind every QR code: the public tier of a passport as JSON or JSON-LD, 404 and 410 semantics. - [EU field catalogue](https://www.collectadpp.com/developers/field-catalogue): How the API field names map to the 71 data points of the EU guidance "Digital Batteries Passport – data points by category" v2.0, with obligation per battery category and access tier. - [Webhook signature tester](https://www.collectadpp.com/developers/webhook-tester): Verify a DPP-Signature header against a body and secret, find out exactly why one fails, or sign a test delivery — in your browser, nothing is sent anywhere. - [Passport JSON and JSON-LD viewer](https://www.collectadpp.com/developers/passport-viewer): A published battery passport as the public resolver returns it, JSON and JSON-LD side by side, with each property traced to its EU data point, Annex XIII point and access tier. - [API reference](https://www.collectadpp.com/developers/api-reference): Interactive reference for every /v1 endpoint, generated from the live OpenAPI 3.1 specification. - [Error code index](https://www.collectadpp.com/developers/error-codes): Every error code the Battery Passport API returns — top-level and per row in bulk responses — with its HTTP status, what it means and how to fix it. - [Webhook event catalogue](https://www.collectadpp.com/developers/webhook-events): Every webhook event the Battery Passport API sends: when it fires, which calls emit it, the fields of its data object and a sample payload. - [Glossary](https://www.collectadpp.com/developers/glossary): The regulatory and API terms used in these docs — UPI, Annex XIII points, access tiers, economic operator, dry run, idempotency — with links to the full definitions. - [Changelog](https://www.collectadpp.com/developers/changelog): Every change to the Battery Passport API, newest first, starting with v1.0.0 on 4 October 2026. - [Developer FAQ](https://www.collectadpp.com/developers/faq): Answers to the questions integrators ask most: sandboxes, identifiers, limits, partial failures, webhooks, data residency and leaving. ### Test keys and dry runs https://www.collectadpp.com/developers/testing There is no separate sandbox to drift out of date. A test key works against your real organisation and real master data, validates every write exactly as production would, and stores nothing. ## Two kinds of key Prefix | dpp_live_… | dpp_test_… Reads | Your data | Your data Writes | Stored | Dry run: validated, never stored Rate limit | 600 requests / minute | 60 requests / minute X-DPP-Mode response header | live | test Webhooks | Sent for real changes | Never sent Usage | Counted | Never counted Create either kind in the app under Organisation → API keys. Both carry the same read / write scopes, and both need a plan that includes API access (Connected). ## What a dry run checks Everything a real write would check, in the same order: authentication and scope, the request schema, that every referenced id (a model, a passport) exists in your organisation, and the business rules. A request that would fail live fails the same way in a dry run. A request that would succeed answers 200 with a body that says so, and nothing is written — no model, no passport, no event, no audit entry, no webhook: dry_run, valid and operation are always present; the response also carries the header X-DPP-Dry-Run: true. Where the outcome depends on rules that can be checked without writing, the answer says what would happen: POST /models | completeness: whether the new model would be complete, and the model-level fields it would still owe. POST /passports/{id}/publish | would_publish and blockers. POST /passports/publish | results: per id, would_publish and blockers, or error: "not_found". An id that is not in your organisation answers 404 with not_found, exactly as the real write would refuse it; an invalid body answers 400 with details. POST /models/validate changes nothing, so it is not a dry run: it needs only the read scope, and a test key gets the real analysis — complete, missing, unknownFields — like a live key. ## One dry run with a live key A live key can dry-run a single write by adding X-DPP-Dry-Run: true. Use it for a pre-flight check in production — "would this batch publish?" — without a second key. ## Know which mode you are in Every response carries X-DPP-Mode: live or X-DPP-Mode: test, and GET /me reports the key. Assert it at start-up so a test key can never be deployed to production by mistake — a job that "succeeds" in test mode has created nothing. ## A testing strategy that works - Develop against a test key. Your code sees real models and passports, and nothing you send can create or change one. - Run CI with a test key. Contract tests exercise every write path; failures surface as the same 400/404/422 errors production would give. - Pre-flight in production with X-DPP-Dry-Run: true before a large batch or publish. - Go live by swapping the key. No code changes, no base-URL change. A test key reads your real data. Treat it as a secret exactly like a live key, and give it only the scopes the test needs. ### TypeScript SDK https://www.collectadpp.com/developers/sdk The official TypeScript client, `@collecta/dpp-sdk`: every request and response typed, an idempotency key on every write, automatic retries, auto-pagination and webhook verification — with no runtime dependencies. The SDK is complete and tested against the API, and is being prepared for publication. It is not on npm yet — this page and the changelog will say so the day it is. Until then, every sample in these docs also works as plain HTTP. ## Install It uses the global fetch, so it runs on Node 18+, Deno, Bun, Cloudflare Workers and Vercel Edge. It ships as ESM, with a second entry point, @collecta/dpp-sdk/webhooks, for receivers. ## Quickstart The Quickstart shows every step with an SDK tab next to the raw HTTP samples. ## Configuration Every method also takes a final options argument: ## Resources dpp.models | list, listAll, get, create, update, validate, completeness, uploadDocument dpp.batteries | create, createMany, get, listForModel dpp.passports | list, listAll, get, publish, publishMany, recordEvent, events, eventsAll, changeStatus, recycle, qrSvg, qrPng, versions dpp.fleet | bulkLifecycle, importUpdates dpp.documents | list, listAll, get, download dpp.audit | list, listAll dpp.webhooks | list, create, get, update, rotateSecret, test, deliveries, deliveriesAll, resend, eventTypes dpp.export | json, archive Client | me(), fieldCatalog(), request() for any other endpoint ## Models ## Batteries ## Passports ## Webhook endpoints ## Anything else Endpoints without a dedicated method — facilities, supplier requests — go through dpp.request() with the same authentication, retries, idempotency and errors: ## Pagination listAll is available on models, passports (plus eventsAll), documents, audit and webhooks.deliveriesAll. ## Idempotency and retries Every write is sent with an Idempotency-Key. When you pass none, the SDK generates a UUID and reuses it for each retry of that call, so a timeout after the server created 500 batteries returns the stored answer instead of creating 500 more. Pass your own key to stay safe across processes, such as a job queue re-running a task: - Retried automatically: network errors, timeouts, 429, 5xx and 409 idempotency_in_progress. Other 4xx are never retried. - Backoff: 500 ms · 2^attempt, capped at 30 s, with 50–100 % jitter; retry-after is honoured up to the cap. - maxRetries (default 3) and timeoutMs (default 30 s per attempt) on the client or per call; an AbortSignal cancels the call and any pending retry wait. ## Dry runs With a live key, dryRun: true validates a write and stores nothing, sends no webhook and counts no usage. The return type changes to DryRunResult. A test key dry-runs every write; isDryRunResult() handles both in one code path. ## Typed errors BadRequestError | 400 — details maps fields to messages | No AuthenticationError | 401 | No PaymentRequiredError | 402 — requiredPlan names the plan | No PermissionDeniedError | 403 | No NotFoundError | 404 | No ConflictError | 409 | Only idempotency_in_progress GoneError | 410 | No UnprocessableEntityError | 422 — publish_blocked, idempotency_key_reused, … | No RateLimitError | 429 — retryAfterSeconds | Yes InternalServerError | 5xx | Yes DppConnectionError, DppTimeoutError | No answer | Yes All API errors extend DppApiError and carry status, code (the error field), message, details, requestId and the raw body. For publish_blocked, details holds the blockers. ## Response metadata ## Verifying webhooks verifyWebhook checks DPP-Signature in constant time, refuses deliveries outside toleranceSeconds (default 300) to block replays, and returns the typed event. It uses node:crypto on Node and WebCrypto elsewhere. Pass the raw body — parsing and re-serialising JSON changes the bytes and the signature will not match. Next.js Pages Router: export config = { api: { bodyParser: false } } and read the raw body from the request stream before verifying. ## Typed events - Secret rotation: pass both secrets while you deploy the new one — secret: [newSecret, oldSecret]. - Testing a receiver without the API: generateWebhookSignatureHeader({ payload, secret }) from @collecta/dpp-sdk/webhooks produces a valid header. - Respond 2xx quickly and work afterwards; de-duplicate on event.id. ## TypeScript types Response dates are ISO 8601 strings; dates you send may be Date objects or strings. Within v1 the API only adds fields, so expect extra properties on responses. ### AI coding agents https://www.collectadpp.com/developers/ai-agents Let the coding agent you already use — Claude Code, Codex or Cursor — work with your battery passports directly. The Collecta DPP **MCP server** gives the agent tools to read models, see what is missing, look up the EU data points and inspect passports; **AGENTS.md** gives it the rules to write an integration that is correct the first time. API access is included on **every plan**. The MCP server, @collecta/dpp-mcp, is built on the TypeScript SDK and tested against the API, and is being prepared for publication. It is not on npm yet: the npx commands below start working the day it is published, and the changelog will say so. Until then, a local build runs the same way — replace npx -y @collecta/dpp-mcp with node /absolute/path/to/dpp-mcp/dist/index.js. AGENTS.md works today with any agent. ## What it is The Model Context Protocol (MCP) is the open standard coding agents use to call external tools. The Collecta DPP MCP server runs on your machine next to the agent, holds your API key, and turns the REST API into tools with descriptions an agent can act on: which call to make first, what a field is called, why a publish was refused and what to do about it. - Read-only by default. Twelve read tools are always there; the six write tools are not even registered unless you turn them on. - Structured answers. Every result is JSON with a request_info block — request_id, key mode, whether it was a dry run, the idempotency key used. Failures come back as tool errors with code, message, request_id and a hint saying what to do next. - Two resources and two prompts. dpp://field-catalogue (the 71 EU data points) and dpp://openapi (the OpenAPI document); the prompts fill_model_gaps and integration_review. ## Set it up Create a test key (dpp_test_…) in the app under Organisation → API keys. With a test key every write is a dry run — validated against your real data, never stored — so the agent can explore safely. Then register the server with your tool: Claude Code with claude mcp add, Codex in ~/.codex/config.toml, Cursor in .cursor/mcp.json in the project (or ~/.cursor/mcp.json for every project). DPP_API_KEY | Yes | dpp_test_… to start, dpp_live_… when you trust the workflow. DPP_BASE_URL | No | Defaults to https://dppapi-production.up.railway.app/v1. DPP_ALLOW_WRITES | No | true registers the write tools. Anything else, or unset: read-only. ## Share it with your team (Claude Code) Commit a .mcp.json at the root of the repository and every teammate gets the server. Keep the key out of the file: Claude Code expands ${DPP_API_KEY} from each person’s environment. ## Enable the write tools Add DPP_ALLOW_WRITES=true. Keep the test key until the agent’s work looks right: the server then validates every write for real and stores nothing. ## Tool catalogue ## Read tools — always available whoami | The key’s organisation, plan, scopes, mode (live or test), usage and rate limit, and whether write tools are enabled. list_models | Models with completeness and counts; filter by category, complete and updated_since. get_model | One model with every stored field, conformity record, documents and declarations. model_completeness | What is still missing for the model’s category, grouped by Annex XIII point, with how to fill each gap. validate_model_draft | Validate a model before creating it: missing data and unknownFields (usually typos). Stores nothing. list_passports | Passports with identifier, serial, status and links; filter by model, serial, identifier, status, published, updated_since. get_passport | One passport: battery, model, every field, recent events and lineage. passport_events | A passport’s dynamic-data history (state of health, cycles, repairs…), by type and time. list_documents | Model documents with type, Annex XIII point and download link. search_field_catalogue | Search the 71 EU data points by text, category and obligation; returns the exact API field name and endpoint. audit_trail | Who changed what and when; filter by entity, record and time. list_webhooks | Webhook endpoints with subscriptions, last delivery and failure count. Never secrets. ## Write tools — only with DPP_ALLOW_WRITES=true create_model | Create a battery model. update_model_fields | Merge data points into a model; keys you omit are kept. create_batteries | Create up to 1000 batteries (serials, or a count with a prefix), each with its own passport. publish_passports | Publish up to 1000 passports with per-row results; a dry run lists what blocks each one. record_passport_event | Append a dynamic-data event, such as a state-of-health reading. Append-only. change_passport_status | Repurpose, re-use, remanufacture (forks a linked passport) or mark as waste. Every write tool takes dry_run, and is safe to retry: the idempotency key is derived from the tool and its input, so a repeated call within 24 hours returns the first answer instead of creating a second battery. Pass idempotency_key to repeat an identical write on purpose. ## Example prompts - “Which DPP organisation is this key for, which plan is it on, and is it a test key?” - “List our EV models that are not complete yet, and for the first one tell me what is still missing by Annex XIII point.” - “Which data points are required for industrial batteries, and what are their API field names?” - “Here is the datasheet for our NV-EV-90 pack. Use the fill_model_gaps prompt and propose values for every missing field — don’t write anything yet.” - “Validate this LMT model from our spec sheet before we create it, and fix any unknown field names.” - “Which passports changed since yesterday? Show the state-of-health readings of the newest one.” - “Dry-run publishing every draft passport of model NV-EV-90 and tell me what blocks each one.” - “Review src/dpp-sync.ts with the integration_review prompt, focusing on retries and webhook verification.” ## Safety model 1. Read-only unless you opt in: Without DPP_ALLOW_WRITES=true the write tools do not exist, so no prompt can make the agent call them. 2. Test keys first: With a dpp_test_… key the API itself turns every write into a dry run. Even with writes enabled, nothing is stored. Switch to a live key only when you trust the workflow. 3. Dry runs on live keys: Every write takes dry_run: true, and the tool descriptions tell the agent to use it first. A dry-run publish lists what blocks each passport. 4. Nothing is ever deleted: The API has no DELETE: passports must stay available for ten years. change_passport_status is marked destructive so clients ask before running it, and recycling is not offered at all. 5. Safe retries, least privilege: Derived idempotency keys mean a retried call never acts twice. A key with only the read scope refuses every write, whatever the server allows. ## AGENTS.md for your repository Coding agents read an AGENTS.md at the root of a repository before they write code. Ours is the integration rulebook for this API, in one page: base URL and keys, test keys first, an Idempotency-Key on every write, validate before create, completeness before publish, never DELETE, cursor pagination and updated_since for sync, webhook signature verification, error handling with request_id, and rate limits. Drop it into the repository that talks to the API — with or without the MCP server. AGENTS.md: Plain Markdown. Save it at the root of your repository, next to your README, or merge it into an AGENTS.md or CLAUDE.md you already have. ## llms.txt and Copy page - /llms.txt lists every docs page with a one-line summary; /llms-full.txt is the full corpus in one file. Point an agent at either when it needs the docs. - Copy page in the header of every docs page copies it as clean Markdown, code samples included in the language you picked — ready to paste into an agent’s context. - The OpenAPI 3.1 document is public and needs no key; the MCP server also serves it as dpp://openapi. ### Postman, Insomnia and other tools https://www.collectadpp.com/developers/postman The OpenAPI 3.1 document is public and needs no key, so any API tool can import it straight from its URL. ## The specification URL ## Postman - Choose Import, then Link, and paste the specification URL. - Import it as a collection. Postman creates a request for every endpoint, grouped by tag. - Open the collection’s Authorization tab, choose Bearer Token, and set the token to a variable such as {{dpp_api_key}}. - Create an environment with dpp_api_key set to a test key (dpp_test_…) to explore safely; writes are dry runs. ## Insomnia - Choose Import, then From URL, and paste the specification URL. - Insomnia creates a document with every request. Set Auth → Bearer Token on the folder, from an environment variable holding your key. ## Bruno, Hoppscotch, Paw and others Any tool that imports OpenAPI 3 works the same way: import from URL, then set a bearer token. The interactive API reference on this site is built the same way and lets you send requests from the browser. ## Generate a client Generators such as OpenAPI Generator can turn the document into a typed client for Java, C#, Go, Python, PHP, Kotlin, Swift and more: Pin the specification you generate from — download it into your repository and regenerate deliberately. Within v1 the document only grows (see Versioning), so a regenerated client stays compatible with code written against the old one. ### Requests and responses https://www.collectadpp.com/developers/requests ## Base URL and transport All endpoints are under https://dppapi-production.up.railway.app/v1, over HTTPS only. The public resolver lives at https://dppapi-production.up.railway.app/p/…, outside /v1, because it is the address printed in QR codes. Cross-origin requests are allowed on /v1 from any origin — keys travel in a header, never a cookie — but keys are secrets: call the API from your servers. ## JSON in, JSON out - Request bodies are JSON with Content-Type: application/json, except document uploads (multipart/form-data). - Send Content-Type: application/json only when there is a body. A write without a body (publish, test webhook) that declares JSON is rejected with 400. - Responses are JSON (application/json; charset=utf-8), except QR images, documents, the export archive and JSON-LD (application/ld+json). - Property names are camelCase on resources; list envelopes, error fields and query parameters use snake_case (has_more, request_id, updated_since). ## Identifiers Record id | cm1q8y0bq0006l70fx9y8z7w6 | Opaque string. Store it as text; do not parse it. Battery unique identifier | C-7KQ2M9XHT4R | C- + 11 characters, no ambiguous letters. Immutable, printed on the label, resolvable at /p/{uniqueIdentifier}. Serial number | C48-2027-0001 | Yours. Searchable, not unique across models. Request id | 3f1c2a9e-8d4b-4c6f-9e2a-7b5d1c0e8f34 | Per request; see below. ## Dates and times Timestamps are ISO 8601 in UTC (2027-01-15T10:02:11.000Z). Date inputs accept a date (2027-01-15) or a full timestamp. Filters such as updated_since accept a date or a date-time with an offset. ## Request IDs Every response carries an X-Request-Id header, and every /v1 error body repeats it as request_id. Log it with every failure: quoting it is the fastest way for us to find exactly what happened. You may also send your own X-Request-Id (for example your trace id) and it is used for the request. ## Headers at a glance Authorization: Bearer dpp_… | Request | Your API key. Required on /v1 except /openapi.json. Content-Type: application/json | Request | Only with a JSON body. Idempotency-Key | Request | Makes a POST or PATCH safe to retry. Details. X-DPP-Dry-Run: true | Request | Live key: validate without storing. Details. X-Request-Id | Both | Correlates a request with our logs. X-DPP-Mode | Response | live or test. X-DPP-Dry-Run: true | Response | This answer is a dry run; nothing was stored. X-DPP-Api-Version | Response | The API version that answered, e.g. 1.0.0. Idempotent-Replayed: true | Response | This is a stored response being replayed. x-ratelimit-limit / -remaining / -reset | Response | Your rate-limit budget. Details. retry-after | Response | On 429: seconds to wait. ## Success codes 200 OK | Read, update, or a dry run that would have succeeded. 201 Created | A record was created (model, battery, document, event, linked passport). 207 Multi-Status | A bulk request where at least one row failed; read results. Every failure is described in Errors. ### Pagination https://www.collectadpp.com/developers/pagination List endpoints return one page at a time with an opaque cursor to the next. Cursors stay correct while records are being added, which offsets cannot promise. ## Parameters and envelope limit | Page size, 1–200. Default 50. cursor | The next_cursor from the previous page. Omit for the first page. - Stop when has_more is false; next_cursor is then null. - Treat the cursor as opaque: do not build, decode or modify it. - Keep the same filters on every page of one walk; change filters, start again without a cursor. - Lists are newest first, and the cursor marks the position of the last row. Records created during a walk land before your starting point, so a walk never skips or repeats a row — pick them up on the next incremental run. ## Paginated endpoints GET /models | category, updated_since, complete GET /passports | model_id, serial, unique_identifier, status, published, updated_since, created_since GET /passports/{id}/events | since, event_type GET /documents | model_id, type GET /audit | entity, entity_id, since GET /webhooks/{id}/deliveries | status GET /models/{id}/items predates cursors and pages by number (page, pageSize); for syncing batteries use GET /passports?model_id= instead. ## The first page ## Complete loops Each of these walks every page and stops on its own: To keep a copy up to date after the first walk, see incremental sync. ### Idempotency and retries https://www.collectadpp.com/developers/idempotency Networks fail in the worst place: after the server has done the work and before you hear about it. An idempotency key makes the retry return the original answer instead of doing the work twice. ## The Idempotency-Key header - Send Idempotency-Key: on any POST or PATCH. A UUID v4 is ideal. - The first response — success or error — is stored for 24 hours against your API key and that key. - A retry with the same key and the same request (method, path and body) gets the stored response back — same status, same body — with the header Idempotent-Replayed: true. Nothing is executed a second time. - The same key for a different request is refused with 422 and idempotency_key_reused. - While the first request is still running, a concurrent retry with its key gets 409 idempotency_in_progress: wait briefly and retry. - A 5xx is never stored, so retrying after a server error really runs the request again. A 4xx is stored like any other answer. - Keys are 1–255 characters (otherwise 400 invalid_idempotency_key) and scoped to the API key that sent them, so two integrations cannot collide. - Dry runs are answered before idempotency is consulted: they are never stored or replayed. ## Choosing keys Derive the key from the operation, not the attempt. Generate it once when the work is decided and keep it with the job, so a retry after a crash reuses it. Good keys are a UUID stored with the job, or a natural id: batch--, publish--2027-01-15. POST /items/batch and POST /items mint identifiers that are printed on batteries and can never be withdrawn. Never send them without an Idempotency-Key. ## What to retry Network error, timeout | Yes | Same request, same idempotency key. 429 | Yes | After retry-after seconds. 500, 502, 503, 504 | Yes | Exponential backoff with jitter, same key. 409 idempotency_in_progress | Yes | After a short wait, same key. 409 organisation_frozen | No | Contact us; the organisation is read-only. 400, 401, 403, 404, 422 | No | The request itself must change. 207 | Only the failed rows | Fix and resend just those, with a new key. ## A retry helper ## Naturally idempotent operations - Publishing an already-published passport returns it unchanged (bulk publish reports alreadyPublished). - PATCH /models/{id} with the same fields leaves the same values. - Recording an event is not naturally idempotent — the same reading sent twice is two events. Use a key. ### Webhooks https://www.collectadpp.com/developers/webhooks Instead of polling, let us tell you. Every change worth knowing about becomes a signed HTTPS POST to your endpoint, retried until it gets through. ## Set up an endpoint Register an endpoint in the app under Organisation → API → Webhooks, or over the API with POST /webhooks. Choose the events it receives — none selected means all; GET /webhooks/event-types lists them. Copy its signing secret (whsec_…) into your secret store, then send a signed ping with POST /webhooks/{id}/test — or from the app — and check your receiver answers 2xx. - The URL must use https and resolve to a public address; private, loopback and link-local addresses are refused. - Credentials in the URL are not allowed — the signature is the authentication. Over the API you can also update or pause an endpoint (enabled: false), rotate its secret, read its delivery log and resend a delivery. Endpoints are paused rather than deleted over the API, so their history survives. ## Events passport.created | A battery and its draft passport were created (once per battery in a batch). | passport passport.published | A passport was published. | passport passport.status_changed | A passport’s status changed (PATCH /passports/{id}/status). | passport, status; forked (passportId, uniqueIdentifier of the new linked passport) for a repurpose, re-use or remanufacture — none for WASTE passport.recycled | A passport ceased because the battery was recycled. | passport passport.event_recorded | Dynamic data was recorded. | passport, event (id, eventType, payload, recordedAt) model.created | A model was created. | model model.updated | A model was changed. | model document.uploaded | A document was uploaded to a model. | document (id, modelId, name, type, point, createdAt) supplier.submitted | A supplier answered a data request — values or a file. | request (id, supplierName, modelId, kind), and fields or file passport is { id, uniqueIdentifier, serialNumber, itemId, modelId, status, lifecycleState, publishedAt, publicUrl }; model is { id, name, category, capacityKwh, chemistry, updatedAt }. Payloads are deliberately small: fetch the full record with its id when you need more. The test event is ping, with data.message. Each event type is also described in the webhooks section of the OpenAPI document. ## The delivery ## Verify the signature DPP-Signature is t=,v1=, where v1 is the HMAC-SHA256 of the string "." keyed with your endpoint secret. To verify a delivery: - Read the raw request body, byte for byte. Parsing and re-serialising JSON changes it and breaks the signature. - Split the header on , and each part on the first =; take t and v1. - Reject the delivery if t is more than five minutes from your clock — that blocks replays of captured requests. - Compute HMAC-SHA256 of t + "." + body with the secret, as hex, and compare it to v1 in constant time. ## Responding and retries - Answer with any 2xx within 10 seconds. Acknowledge first and do the work afterwards, on a queue. - Anything else — another status, a timeout, a connection error, or a redirect (redirects are not followed) — is a failed attempt. - Failed deliveries are retried after 1 minute, 5 minutes, 30 minutes, 2 hours, 6 hours. After the sixth attempt the delivery is marked failed. - The delivery log in the app shows each attempt, the status and body your endpoint returned, and lets you resend. ## At least once, in any order A delivery can arrive more than once — a retry after your endpoint processed it but timed out — and deliveries can arrive out of order. Make the handler idempotent: store the event id (also in DPP-Event-Id) and skip ids you have seen. Where order matters, compare created_at, or fetch the current state of the record by its id. Webhooks tell you that something changed. For a complete mirror, pair them with a periodic incremental sync as a safety net — a webhook endpoint that was down for a day still catches up. ### Glossary https://www.collectadpp.com/developers/glossary The regulatory terms behind the API’s field names and rules, and the API’s own vocabulary. Regulatory terms link to their full definitions. ## Regulation Battery passport | The electronic record of one physical battery required by Regulation (EU) 2023/1542. In the API: a passport, one per battery item. Article 77 | The article that creates the passport. 77(1): one per individual battery. 77(7): a repurposed or remanufactured battery gets a new passport linked to the old. 77(8): the passport ceases when the battery is recycled. Annex XIII | The list of passport content, in four points. Point 1 public information; Point 2 information for persons with a legitimate interest and authorities; Point 3 authority-only information such as test-report results; Point 4 battery-specific data, including dynamic data such as state of health. Access tier | Who may see a data point, following Annex XIII: PUBLIC (Point 1), LEGITIMATE_INTEREST (Points 2 and 4) and AUTHORITY (Point 3). Enforced on the server; the public resolver serves PUBLIC only. Legitimate interest | The standing of repairers, remanufacturers, second-life operators and recyclers to access more than the public tier. Unique identifier | The string that identifies one physical battery (ISO/IEC 15459). In the API: uniqueIdentifier, C- + 11 characters. Never changes. UPI (unique product identifier) | The identifier a passport is registered under in the EU DPP Registry (Impl. Reg. (EU) 2026/1778 Art. 8). The Registry requires a URL starting with https://, at most 50 characters, that resolves to the hosted passport — the reason identifiers are kept short. Data carrier | The QR code (ISO/IEC 18004) on the battery that encodes the resolver URL. In the API: GET /passports/{id}/qr.svg. Economic operator | The organisation responsible for the battery and its passport — your organisation. In the API: responsibleOrgId. Placing on the market | Making a battery available on the EU market for the first time. In the API: placedOnMarketAt; Point 4(a) values are measured at this moment. State of health | The battery’s condition relative to new. EV: state of certified energy. LMT: remaining capacity, power capability, round-trip efficiency. In the API: SOH_READING events. Repurposing | A battery gets a second life for a different purpose. In the API: PATCH /passports/{id}/status with REPURPOSED, which forks a linked passport. Declaration of conformity | The EU Declaration of Conformity, a required document (Annex XIII 1(r)). In the API: a document of type "EU Declaration of Conformity". Notified body / market surveillance authority | The authorities with access to Point 3 data. Battery categories | EV, LMT and industrial batteries above 2 kWh need a passport. In the API: category. ## API Model | A battery design: the data every battery of the design shares. Battery item | One physical battery. Creating one creates its passport. Draft / published | A new passport is a draft: private and not billed. Publishing makes it public and counts it as issued. Publish gate | The server-side check before publishing: a place of manufacture, and a model complete for its category. Ceased | A recycled battery’s passport. The resolver answers 410 Gone. Fork | The new, linked passport created on repurpose, re-use or remanufacture. Event | One append-only record of dynamic data. Live / test key | A live key stores writes; a test key dry-runs them. Details. Dry run | A write validated in full and not stored. Idempotency key | A header that makes a retried write return its first response. Details. Cursor | The opaque pointer to the next page of a list. Details. Webhook | A signed HTTPS POST we send when something changes. Details. ### Changelog https://www.collectadpp.com/developers/changelog Within v1 every change is additive; anything breaking would ship as v2 with advance notice. Subscribe to the specification URL in your CI to see additions as they land. 1.0.0 (4 October 2026) - added: The public REST API under /v1, authenticated with organisation API keys carrying read and write scopes. - added: Live (dpp_live_…) and test (dpp_test_…) keys; test keys dry-run every write. X-DPP-Dry-Run for single dry runs with a live key; X-DPP-Mode on every response. - added: Idempotency keys on POST and PATCH, stored for 24 hours, with Idempotent-Replayed on replays. - added: X-Request-Id on every response and request_id in every /v1 error body. - added: Cursor pagination (limit, cursor, has_more, next_cursor) on list endpoints. - added: Models: list, create, read, update, validate and missing-field analysis. Documents: upload, list, download. - added: Batteries: create one or up to 1,000, each with its own passport and unique identifier. - added: Passports: list with incremental-sync filters, read, publish (single and bulk) behind the publish gate, status changes with linked successor passports, recycling, QR codes and the version archive. - added: Dynamic data events, including the telemetry fields capacityThroughput, timeExtremeHighTemp, timeExtremeLowTemp, timeChargingExtremeHighTemp and timeChargingExtremeLowTemp. - added: Fleet operations: bulk lifecycle events and matched row updates, with per-row results. - added: Signed webhooks for passports, models, documents and supplier submissions, with retries, a delivery log, resend, secret rotation and a ping test event — managed in the app or under /webhooks. - added: Facilities: GET /plants and POST /plants. - added: Supplier requests: GET /upload-links, POST /upload-links, GET /upload-links/{id}/files and POST /upload-links/{id}/accept. - added: X-DPP-Api-Version on every /v1 response. - added: Audit trail, JSON export and ZIP archive over the API. - added: GET /field-catalog: the 71 EU data points with obligation per category, field mapping and access tier. - added: Rate limits: 600 requests per minute per live key, 60 per test key. ### Developer FAQ https://www.collectadpp.com/developers/faq Q: Is there a sandbox? A: Yes, without a separate environment: a test key runs against your real organisation and dry-runs every write — fully validated, nothing stored. A live key can dry-run a single request with X-DPP-Dry-Run: true. Q: Which plan do I need for the API? A: None in particular: API access — keys, /v1 and webhooks — is included on every plan. What a call may do follows the plan: publishing needs a paid plan, supplier requests need Growth. See pricing. Q: Can I use my own battery identifiers? A: Yes, when you are moving from another provider and the codes are already printed: send uniqueIdentifier with POST /items. Otherwise we mint one (C- + 11 characters) — short enough for the 50-character registry limit, unambiguous on a label. Q: One passport per battery — even for 100,000 cells a day? A: Yes; Article 77(1) requires one per physical battery (for the categories in scope). POST /items/batch creates up to 1,000 per request and POST /passports/publish publishes up to 1,000; at 600 requests a minute that is far beyond any line rate. Q: What happens if a batch fails halfway? A: Creating batteries is all-or-nothing: a batch is created in one transaction. Publishing and fleet operations are per row and answer 207 with a reason per failed row. Use an idempotency key so a retry never doubles a batch. Q: Why was my publish refused with 422? A: The publish gate: the battery needs a place of manufacture, and its model must be complete for its category. blockers names each problem; GET /models/{id}/completeness lists the missing fields. Q: Can I delete a passport over the API? A: No. Passports must stay available for ten years, so the API never deletes — see why there is no DELETE. Record recycling, change status, or delete in the app, where deletions are audited. Q: How do I keep my systems in sync? A: Subscribe to webhooks for immediacy and run an incremental sync with updated_since as the safety net. Q: Who sees the data I send? A: Each data point has an Annex XIII access tier. The public resolver serves only PUBLIC data; restricted tiers stay on the server. Your own key sees everything of your organisation. Q: Do webhooks arrive in order, exactly once? A: Neither is guaranteed: deliveries are at least once and may arrive out of order. Deduplicate on the event id, and order by created_at where it matters. Q: Can I call the API from a browser or mobile app? A: Technically yes — /v1 allows any origin — but do not: a key is an organisation-wide secret. Call it from a server you control. Q: How do I leave, and what happens to the QR codes? A: Download everything with GET /export/archive. The identifiers never change; redirecting the printed address to a new provider is arranged between providers, and we accept identifiers issued elsewhere for the same reason. Q: Is there an SDK? A: A TypeScript SDK, @collecta/dpp-sdk, is coming soon to npm. Meanwhile every endpoint has samples in seven languages, and the OpenAPI document generates clients for many more. Q: Is this legal advice? A: No. The docs describe how the software maps the regulation; responsibility for the content of a passport stays with the economic operator. ### ERP integration: issue passports at end of line https://www.collectadpp.com/developers/guides/erp-integration The pattern most manufacturers use: the ERP owns product master data, the line produces serial numbers, and a small connector turns both into published passports — once per model, once per batch, safely retryable. ## The shape of the integration 1. Product released in the ERP: Create or update the battery model with its model-level data points. Store the returned model id on the material master. 2. Model passport-ready?: Check the missing-field analysis and upload the EU Declaration of Conformity. Publishing is blocked until the model is complete. 3. Batch leaves the line: Create one battery per serial with POST /items/batch, keyed by an idempotency key derived from the production order. Store each returned identifier against its serial. 4. Publish: Publish the batch’s passports with POST /passports/publish; handle per-row failures. 5. Print: Fetch each QR code (qr.svg) for the label, or print the qrResolverUrl with your own label software. ## 1. Mirror the model Map ERP characteristics to the API field names in the field catalogue; GET /field-catalog gives you the same table as data, including which fields your category requires. Before creating, validate: Then create the model once, and on later material-master changes PATCH only the changed fields — the API merges them. ## 2. Attach the declaration of conformity ## 3. Issue passports at end of line When a production order is confirmed, send its serials as rows. The idempotency key ties the request to the order line, so a connector restart cannot issue the batch twice — and identifiers, once printed, can never be withdrawn. The response lists every battery with its uniqueIdentifier and passport.id. Write both back to the serial-number record in the ERP — they are the keys for everything that follows. Batches over 1,000 serials are split into several requests, each with its own key. ## Measured values at placing on the market Annex XIII 4(a) asks for values measured per battery when it is placed on the market — measured capacity, internal resistance, power. If your end-of-line tester produces them, create batteries one at a time with POST /items and put them in fields (measuredCapacityAtPlacing, measuredResistanceAtPlacing, powerAtPlacing, …). ## 4. Publish A 207 means some rows did not publish. missing_place_of_manufacture and model_incomplete are data problems to fix in the ERP and resend; ceased should never happen on fresh batteries and deserves an alert. ## 5. Labels Run the whole flow with a test key first: every call is validated against your real models and nothing is created. Then switch the key. ## Go-live checklist - Live key with only the scopes the connector needs; test key in CI. - Idempotency keys derived from ERP document numbers on every create and publish. - Identifiers and passport ids written back to the serial records. - Per-row 207 failures routed to a work queue, not swallowed. - request_id logged with every error. - Webhook for passport.published if downstream systems need to know. ### Streaming BMS telemetry https://www.collectadpp.com/developers/guides/bms-telemetry Annex XIII Point 4 makes part of the passport dynamic: state of health, usage and exposure change over a battery’s life. A BMS or fleet gateway keeps them current by appending events. ## What to send Each dynamic data point belongs to an event type. Put the readings of one type, taken at one moment, in one event: stateOfCertifiedEnergy | % | SOH_READING | Required | — | — remainingCapacity | Ah | SOH_READING | — | Required | If applicable capacityFade | % | SOH_READING | Required | Required | If applicable remainingPowerCapability | W | SOH_READING | — | Required | If applicable remainingRoundTripEfficiency | % | SOH_READING | — | Required | If applicable selfDischargeEvolution | %/month | SOH_READING | — | Required | If applicable ohmicResistance | mΩ | SOH_READING | — | Required | If applicable cycleCount | cycles | CYCLE_COUNT | If applicable | If applicable | If applicable energyThroughput | kWh | LIFETIME_METRIC | If applicable | If applicable | — capacityThroughput | Ah | LIFETIME_METRIC | If applicable | If applicable | — stateOfCharge | % | OPERATING_CONDITION | If applicable | If applicable | If applicable operatingTemperature | °C | OPERATING_CONDITION | If applicable | If applicable | If applicable timeExtremeHighTemp | min | OPERATING_CONDITION | If applicable | If applicable | If applicable timeExtremeLowTemp | min | OPERATING_CONDITION | If applicable | If applicable | If applicable timeChargingExtremeHighTemp | min | OPERATING_CONDITION | If applicable | If applicable | If applicable timeChargingExtremeLowTemp | min | OPERATING_CONDITION | If applicable | If applicable | If applicable negativeEvent | text | NEGATIVE_EVENT | If applicable | If applicable | If applicable ## Recording a reading ## Cadence and volume - The passport is a record, not a time-series database. Report on a meaningful cadence — daily, per charging session, or on change — not every BMS sample. - With 600 requests a minute per key, one gateway can update 864,000 passports a day with one event each. For larger fleets, batch readings with POST /passports/import-updates: up to 1,000 batteries per request, matched by identifier or serial, each reading recorded under its own event type. - Derive the idempotency key from the battery, the reading time and the type, so a gateway that resends after a dropped connection does not record the reading twice. ## BMS resets If a BMS software reset invalidates the history behind earlier state-of-health values, record it: send the next event with bmsHistoryInvalidatedByReset: true, or a BMS_SOFTWARE_RESET event. Readers of the passport then know earlier values cannot be compared with later ones (Art. 14). ## Reading history back Dynamic data is Point 4: visible to persons with a legitimate interest and authorities, never on the public page. ### Pagination and incremental sync https://www.collectadpp.com/developers/guides/incremental-sync Mirror passports into a data warehouse, a PLM or a customer portal: one full walk, then only what changed — with webhooks for speed and a sync loop for certainty. ## 1. The first full walk Walk every page of GET /passports and store each record by its id. Note the time you started — not finished — as the high-water mark. ## 2. Deltas with updated_since On every later run, walk only what changed since the high-water mark. updated_since on GET /passports also returns passports whose only change is a new dynamic-data event, so one query covers status, publication and telemetry. - Upsert by id — a record can appear in two consecutive deltas. - Overlap the windows by a few minutes (use mark − 5 min) so clock skew and in-flight writes are never missed. - Advance the mark only after the whole walk succeeded. - For new events, follow up with GET /passports/{id}/events?since= for each changed passport. - Models change rarely: sync GET /models?updated_since= the same way. ## 3. Webhooks for immediacy Subscribe to passport.* and model.* webhooks and refresh the record named in each event. Keep the delta loop running hourly or nightly anyway: it repairs anything a webhook outage missed, and it is cheap when nothing changed. ## Budget At 200 passports a page and 600 requests a minute, a full walk reads 120,000 passports a minute. If you need a complete snapshot rather than a mirror, the export archive is one request. ### Supplier data requests https://www.collectadpp.com/developers/guides/supplier-data Some data points live with your suppliers — composition from the cell maker, critical raw materials from the material supplier. A supplier request asks for exactly those fields, and nothing reaches the passport until you accept it. ## How it works 1. You ask: Create a request for a model with the fields you need — in the app, or with POST /upload-links. It returns a token. 2. They answer: The supplier opens /u/{token} on the public passport host — no account, no password — and types the requested values or uploads a file. They see and can answer only the fields you asked for. 3. You are told: A supplier.submitted webhook names the request, the model and the fields that arrived, or the file. 4. You accept: Values stay proposals until you accept them, field by field, with POST /upload-links/{id}/accept. Accepting writes them to the model and records the supplier as their source. Supplier requests are included in the Growth and Connected plans. On Free or Starter the API answers these calls with 402 plan_upgrade_required. ## 1. Find what to ask for The missing-field analysis lists the required fields still empty. Pick the ones a supplier owns and use their name values as requestedFields. ## 2. Send the request Send the supplier the link /u/{token} on your public passport host, using the token in the response. Links always expire (at most 365 days): the token is a credential that travels in a URL. Never log or forward it beyond the supplier. ## 3. React to the answer For a file, kind is "file" and data.file holds id, filename, mimeType and size instead of fields; list the files with GET /upload-links/{id}/files. Without webhooks, poll GET /upload-links and look for status: "responded" — the proposed values are in submittedValues. ## 4. Accept Review the proposed values — you remain accountable for what the passport says — and accept the ones you sign for. Values you leave stay proposed; when nothing is left, the request is finished. Then re-run the missing-field analysis: when the model is complete for its category, its passports can be published. The audit trail records the supplier as the source of each accepted value. Every endpoint used here is documented under Supplier requests. ### Recycling and end of life https://www.collectadpp.com/developers/guides/end-of-life A passport follows the battery through every life it has. The API records each transition — and when the battery is finally recycled, the passport ends in a way scanners can understand. ## Statuses ORIGINAL | First life. | — | Default. REPURPOSED | Second life for another purpose (e.g. EV to stationary storage). | PATCH /passports/{id}/status | New linked passport, new identifier. REUSED | Same purpose, new user, after checks. | PATCH /passports/{id}/status | New linked passport, new identifier. REMANUFACTURED | Disassembled and rebuilt. | PATCH /passports/{id}/status | New linked passport, new identifier. WASTE | Discarded; awaiting treatment. | PATCH …/status or bulk waste | Status only. Recycled | Recycled. | POST /passports/{id}/recycle or bulk recycle | Passport ceases; resolver answers 410. ## Second life: the linked passport Article 77(7) gives a repurposed, re-used or remanufactured battery a new passport linked to the original. The API creates it for you: a new identifier and passport, published at once, under the responsible organisation you name (newResponsibleOrgId, default yours). Its state-of-health history starts fresh, marked as reset, because the old readings described a different use. Label the battery with the new QR code (GET /passports/{childPassport.id}/qr.svg). GET /passports/{id} on either passport shows the link in parents or children. ## Recycling The passport ceases to exist (Art. 77(8)): from now on the resolver answers 410 Gone — not 404 — so anyone scanning the code learns the battery was recycled, not that the passport went missing. The record and its history stay in your account and your exports. ## Whole fleets Passports already recycled are skipped and reported as already_recycled; the rest are applied. Each recycled passport fires passport.recycled. ### Data portability https://www.collectadpp.com/developers/guides/data-portability Your data is yours, in formats that need nothing from us to read. Export is on every plan and keeps working even if the organisation is frozen. ## Two exports GET /export | One JSON document, format collecta-dpp-export/1 | Loading into another system or a warehouse. GET /export/archive | ZIP, streamed | A complete, verifiable copy — including files. ## What the archive contains export.json | Organisation, plants, models, items, passports, dynamic events, registry records, declarations, conformity records, components. passports/*.jsonld | Each published passport as JSON-LD, with its version number and content hash. documents/* | The uploaded files — declarations of conformity, test reports and others. qr/*.svg | The QR code of each passport, as vector artwork. labels/*.svg | Print-ready label artwork produced for a passport. uploads/* | Files suppliers uploaded, with metadata in uploads.json. mapping-templates.json | Saved column-mapping templates from imports. audit.jsonl | The audit trail, one entry per line. manifest.json | Every entry with its size and SHA-256. ## Verify it manifest.json lists every other entry as { path, bytes, sha256 } under files. Recompute each SHA-256 and compare: a truncated or altered archive fails here. ## Deliberately not included - Supplier upload-link tokens — they are live credentials, not data. - Passwords and session data, in any form. - Anything belonging to another organisation. ## The identifiers Identifiers are printed on batteries and never change, so an export does not move them: the printed address keeps pointing where it was printed to. Moving to another provider means the new provider takes the identifiers over and the printed address is redirected — arranged between providers. We accept identifiers issued elsewhere for exactly that reason, and the same works in reverse.