Your Product Now Needs an API: What the Digital Product Passport Actually Makes You Build

What Actually Becomes Mandatory, and When?

The Digital Product Passport has been discussed as a sustainability policy for so long that most engineering organisations have never looked at the technical obligation underneath it. That obligation is now concrete, dated, and in production. On 20 July 2026 the European Commission launched the DPP Registry together with a testing environment, offering both a web interface and an API for economic operators to register unique product identifiers and their associated metadata. The registry is the index. It is not where your data lives.

The first hard date is 18 February 2027. From that day, every electric-vehicle battery, every light means of transport battery, and every industrial battery above 2 kWh placed on the EU market must carry a battery passport reachable through a QR-linked unique identifier, under Regulation (EU) 2023/1542. That regulation has been staging obligations for a while: due diligence duties began in August 2025, general labelling requirements for capacity, chemistry and the separate-collection symbol land in August 2026, and carbon footprint performance thresholds follow in 2028.

Batteries are only the opening act. The wider mechanism sits in the Ecodesign for Sustainable Products Regulation, whose 2025 to 2030 working plan names iron and steel, aluminium, textiles, tyres, furniture, mattresses and ICT products as priority groups. Current tracking of the delegated act pipeline by product group puts iron and steel at a 2026 act with compliance around 2028, textiles, tyres and aluminium at 2027 acts with compliance around 2029, and furniture at 2028. Each act must allow at least eighteen months before its date of application, so the dates are predictable rather than surprising.

The strategic read is simple. If you make a physical product for the European market, a passport obligation is coming for your category, and the first movers in batteries are effectively running the integration test for everyone else. The engineering you do for one product group is the engineering you will reuse for the next, which changes the cost calculation considerably. Building a compliance point solution three times is expensive. Building a product data platform once is not.

Why Is This an Engineering Project and Not a Compliance Purchase?

Because of how the architecture was designed. CEN-CENELEC describes the DPP as a hybrid structure in which the European Commission operates a registry holding the identifiers of products, manufacturers and factories, while operational management and storage of the actual product data is delegated to economic operators and third-party service providers. Read that as an engineer rather than as a compliance officer and the implication is unavoidable: the regulator is running the phone book, and you are running the service it points at.

That service has all the properties of a production system, because it is one. It has to be reachable by anyone with a phone standing in front of your product, in any member state, for as long as that product exists. It has to answer authenticated queries from recyclers, repairers, customs authorities and market surveillance bodies, each seeing a different subset of the data. It has to survive your CDN provider changing, your ERP being replaced, and in the battery case a product that may be in service for fifteen years and then have a second life in a stationary storage installation somewhere else entirely.

Practitioner analysis of what battery storage operators must construct before the deadline sorts the work into four concurrent streams: a passport API and persistent identifier layer that is versioned, rate-limited and authenticated; a lifecycle event registry capturing timestamped, attributed events that feed state-of-health and degradation calculations; a federated ETL pipeline pulling due diligence and carbon footprint data from cell suppliers, mining certifications and transport logs; and integration points that get per-battery telemetry out of battery management systems rather than site-level aggregates. None of those are things you buy in a box.

This is where the procurement instinct misfires. There is a healthy market of DPP platforms, and for a company selling one product line with a shallow supply chain, a hosted product may genuinely be enough. For anyone with configurable products, multi-tier suppliers, existing PLM and MES investments, or telemetry that already flows somewhere, the platform is the easy 30% and the integration is the other 70%. The integration is bespoke by definition, because it terminates in systems only you have.

What Do the New Standards Actually Specify?

Until this year, the honest answer to "what exactly do we build" was that nobody knew. That changed on 27 May 2026, when CEN/CLC/JTC 24 published six horizontal standards under mandate M/604, subsequently cited as harmonised in the Official Journal on 15 July 2026. A detailed field guide to the eight-standard family is the clearest engineering-facing summary available, and it is worth reading before anyone writes a line of code.

EN 18219 governs unique identifiers and permits a defined set of schemes, including GS1 Digital Link URIs, self-issued identification links under IEC 61406, W3C Decentralised Identifiers, RFID and 2D identifiers, and DOIs, with separate schemes for economic operator identifiers including the GLEIF Legal Entity Identifier. The choice matters more than it looks, because it determines whether your identifier resolves through infrastructure you control, infrastructure someone else controls, or a URI scheme you will be maintaining for a decade. The GS1 route is the most familiar to anyone already running GTINs, which is most manufacturers, and it is also the route where your existing barcode estate is a head start rather than a legacy problem.

EN 18220 covers data carriers and specifies 2D symbols and RFID in its high-frequency, NFC and UHF variants, with the requirement that at least one carrier be free to read and readable by a standard smartphone without downloading an application. It also imposes durability expectations, and the published summary of the EN 18xxx family notes carrier survival against textile washing, mechanical abrasion and sun exposure as an explicit design consideration.

The remaining four published standards are the ones that read like an API design document. EN 18216 requires RESTful APIs over HTTPS with TLS, structured message formats, and exchange that is authenticated, confidential and tamper-resistant. EN 18222 specifies the lifecycle operations themselves: create, read, update and search, with element-level access, batch retrieval, version queries and registry submission. EN 18223 defines the shared data model, the container, the metadata and the semantic linking to machine-readable definitions so that a recycler's system can interpret your fields without a bilateral integration project. EN 18221 handles storage, archiving and persistence, making the operator responsible for continued availability across the product lifetime, requiring a backup provider arrangement, and requiring archived versions for regulatory audit trails.

Two standards remain outstanding and both matter for security architecture: prEN 18239 on access rights, security and confidentiality management, expected to align role-based access with eIDAS assurance levels, and prEN 18246 on data authentication and integrity, pointing toward W3C Verifiable Credentials, electronic attestations and ISO/IEC 20248 style signatures with full change audit logging. The pragmatic move is to design against the drafts now rather than wait, because the interfaces they touch are the ones that are most expensive to retrofit.

Why Is the Data, Not the API, the Hard Part?

Ask engineers what worries them about the passport and they will talk about identifier schemes and API contracts. Ask the industry and you get a different answer. In a European Commission survey of 91 battery industry companies, reported in an analysis of what the sector is actually worried about with seven months to go, 63% named data availability and quality as their biggest implementation hurdle, while only 15% pointed to unique identifiers and 2D codes. The plumbing is understood. The water is not there.

The reason is structural. A passport field like recycled content percentage or the carbon footprint of a cathode is not a number sitting in your ERP. It is a claim about something that happened three tiers up your supply chain, in a facility you do not own, held by a supplier who may consider it commercially sensitive, verified by an auditor whose capacity is itself a bottleneck. The March 2026 Brussels roundtable convened by the Global Battery Alliance, CEPS and RECHARGE recorded exactly these concerns: manufacturers reluctant to expose cell chemistry and supplier relationships, missing harmonised reference data for environmental footprints, traceability across multi-tier chains being resource-intensive for smaller firms, and insufficient auditor capacity as an implementation bottleneck.

The same roundtable pointed at the mitigations that actually work, and they are engineering patterns rather than policy asks: pseudonymisation so a supplier can contribute a verified figure without revealing the underlying commercial detail, third-party aggregation so no single party holds the whole picture, and alignment with parallel data-exchange ecosystems such as Catena-X rather than building yet another bilateral integration. It also recorded a piece of advice that engineering leaders should take seriously, which is to accept incremental traceability improvements rather than demanding complete coverage on day one.

That reframes the first sprint. The instinct is to design the passport schema and then go find the data. The productive order is the reverse: take the mandatory field list, walk it against your actual systems and supplier contracts, and mark each field green if you already hold it, amber if a supplier holds it and a contract clause could get it, and red if nobody currently produces it at all. The red list is your real project plan, and it is almost always longer than the schema work. It is also the part that has a procurement lead time, which is why it cannot start in January.

One more thing the gap audit reveals early: how much of this is a data engineering problem rather than a web development problem. Field-level provenance, unit normalisation across suppliers who report in different bases, reconciliation between a supplier declaration and a measured value, and validation rules that fail loudly at ingestion rather than quietly at publication. Teams that staff this as a front-end project with a compliance annex discover the imbalance around month four.

What Does a Ten-Year Availability Promise Do to Your Architecture?

EN 18221 makes the economic operator responsible for keeping passport data available across the lifetime of the product, and requires a backup provider arrangement so that the data survives the failure of whoever is hosting it. For a battery in a grid storage installation, that lifetime is comfortably over a decade, and it may include an ownership transfer, a repurposing into second life, and eventual dismantling by a recycler who has never heard of you.

Think about what that implies for ordinary architectural decisions. The URL embedded in a laser-etched mark on a steel casing cannot be changed after the product ships, which means the resolver host is now a permanent commitment and cannot be a vendor subdomain you might migrate off. The data model will change, because the delegated acts will change, so every passport needs to be versioned and every historical version needs to remain retrievable for audit. The access tiers are not a feature flag, they are a legal boundary between public information, information available to those with a legitimate interest, and information available only to authorities, each with its own authentication path.

The operational commitments are unusual too. Your uptime obligation is not driven by revenue-generating traffic, it is driven by a regulator and a recycler with a scanner. Traffic will be low, spiky, and dominated by automated crawlers and market surveillance checks, which is a poor fit for infrastructure sized by average load and a good fit for something boring, cheap and static-first. Cost per passport matters when the number of passports equals the number of units you have ever shipped, and a design that costs a fraction of a cent per item is a different business case from one that costs ten cents.

There is also a succession question that nobody enjoys raising in a kickoff meeting: what happens to the passport estate if the business unit is sold, or the company is acquired, or the product line is discontinued. The backup provider requirement exists precisely because the regulator has thought about this and you probably have not. Answering it early tends to push teams toward open formats, exportable archives and a hosting arrangement that can be transferred, which is good architecture anyway.

Does the Physical Mark Belong to Engineering Too?

It does, and this is where otherwise well-run programmes trip. Every digital record, every access tier and every audit trail in the passport system hangs off a physical mark on a physical object. Under Article 13 of the batteries regulation, that mark must be permanent, indelible, machine-readable and applied when the battery is placed on the EU market rather than when it is later commissioned, and the same analysis of industry readiness with seven months remaining notes that importers who assemble cells into packs assume manufacturer responsibility for marking compliance, and that second-life batteries require new marks documenting the status change.

The engineering consequence is that the marking line is part of your system boundary. Identifier generation has to happen at or before the point of marking, which means the software that allocates identifiers has to be available to the production line, has to be idempotent when the line restarts, and has to reconcile with the registry submission so that no unit ships with an identifier that was never registered or, worse, an identifier issued twice. Verification of mark quality has to be a gate on the line rather than a sampling exercise, because a code that fails to scan after two years in a vehicle underbody is a compliance failure with no remediation path short of a recall.

For teams used to shipping web software, the mental adjustment is that this part of the system has no rollback. A bad deployment is fixed in twenty minutes. A bad identifier scheme is fixed by physically revisiting every unit already in the field. That asymmetry argues for spending disproportionate design effort on the small number of decisions that get frozen into hardware, and for running a genuine end-to-end rehearsal, mark a unit, walk away, scan it with an unmodified phone, and see whether a stranger with no credentials gets the public tier, long before the deadline compresses everyone's schedule.

Who Actually Builds This Inside a Manufacturer?

Here is the awkward organisational fact. The companies in scope are excellent at making things. Their IT organisations are typically strong in ERP, MES, PLM and shop-floor systems, staffed by people who are very good at configuring and integrating large vendor platforms. What the passport requires is a different discipline: public API design, identity and access management, event-sourced data stores, ETL across partners who are not on your network, and a small consumer-facing web surface in every language you sell into. That is product engineering, and most manufacturers do not carry a product engineering bench because they have never needed one.

The default response is to route it to the incumbent ERP systems integrator, which produces a predictable result. You get a competent integration into the systems the integrator knows and a thin, expensive, slow-moving layer everywhere else, billed at enterprise transformation rates for work that is ordinary senior software engineering. The alternative default, hiring permanently, collides with the fact that the acute build phase is roughly six to twelve months, followed by a much smaller steady-state maintenance load. Neither shape fits.

This is precisely the shape a dedicated development team is built for: a small senior group that owns a bounded system end to end, integrates against your existing estate at published contracts, and stays through the stabilisation period rather than disbanding at go-live. Stepto has run senior-led nearshore teams from Serbia since 2014, assigning engineers by name to a client context rather than rotating people through a shared bench, which matters when the work is a decade-long data commitment and the institutional knowledge of why field 47 is calculated the way it is has to live somewhere.

The timezone point is more than a convenience here. A passport programme generates a continuous stream of small blocking decisions: whether a supplier's declaration format is acceptable, which of two units a field should be normalised to, whether an exception is a data error or a genuine product variant. A team sharing the full European working day resolves those the same morning. A team eight or nine hours away resolves them tomorrow, and against a fixed regulatory date a queue of one-day decisions is how a schedule slips without anyone doing anything wrong.

There is a jurisdictional argument as well. Passport data includes commercially sensitive supplier information and, in the battery case, operational telemetry from equipment in the field. Keeping the build team, the data and the hosting inside the European legal perimeter removes an entire category of transfer-mechanism arguments with your own legal department, and it is markedly easier to defend to a customer's procurement team than an equivalent arrangement outside it.

How Should You Sequence the Next Six Months?

Start with registration, because it is cheap and it surfaces reality. The Commission's testing environment is open now, alongside published technical documentation, implementation guidance and a helpdesk. Put one engineer on it for a week, register a real product identifier in test, and pull the proof-of-registration document. You will learn more about your actual gaps in that week than in a quarter of steering committee slides.

Then do the field-level gap audit described earlier, and give it a deadline of four weeks rather than letting it become a standing workstream. Green, amber, red against every mandatory field, with a named owner for each amber and red item. Any field whose owner is a tier-two supplier goes straight to procurement in the same week, because contract amendments move at the speed of contract amendments and no amount of engineering will accelerate them.

In parallel, freeze the decisions that get baked into hardware: the identifier scheme, the resolver hostname, the carrier type and its placement, and the marking verification gate. These are the irreversible ones and they should be settled before anything else is built. Everything downstream is software and can be changed; these cannot.

Then build the thin end-to-end slice: one product, one identifier, one mark, one resolver, one public tier, one authenticated tier, registered in the test registry and archived with a version history. A working narrow path through the whole system in month three is worth more than complete coverage of any single layer, because it converts every remaining unknown from a design argument into an integration task. From there the work parallelises cleanly across the data pipeline, the access tiers, the remaining fields and the language variants.

Reserve the last two months before any go-live for the rehearsal that nobody plans: scan a real unit off the real line with an ordinary phone, in a store, on a poor mobile connection, in a language you do not speak, and have someone with no credentials try to reach data they should not see. Every serious defect we would expect to find in a system like this shows up in that test rather than in unit tests, and finding it in December is a fix while finding it in February is an incident. If you would rather not staff the surge internally, this is a well-bounded scope with a fixed date and clear acceptance criteria, which is exactly the kind of engagement a custom software partner can commit to on outcomes rather than on hours.

Is There Anything Here Worth Having Beyond Compliance?

More than most regulatory programmes, yes, and the teams that get budget approved quickly are the ones that make this argument rather than the fear argument. A per-unit identifier that resolves to a live record, with an append-only event history attached, is the missing primitive in a lot of manufacturing businesses. It is what makes a credible resale or take-back offer possible, because a buyer can verify state of health rather than trusting a claim. It is what turns a warranty process from a paperwork exercise into a lookup. It is what lets a service engineer arriving at a site know precisely which revision is in front of them.

The second-life market is the clearest case. A battery whose degradation history is verifiable is worth measurably more than an identical battery whose history is a spreadsheet in someone's inbox, and the regulation is in effect forcing the creation of the data asset that makes that market liquid. The companies treating the passport as a cost centre will build the minimum, and the companies treating it as a product will have a data set their competitors do not.

There is a defensive angle too. Once passports are public and machine-readable at scale, they become comparable at scale. Recycled content, carbon footprint and durability figures for you and your competitors will sit behind a scan, and someone will build the comparison site within weeks of the first product group going live. That is a strong argument for making sure the numbers you publish are ones you actually stand behind, and for owning the data pipeline that produces them rather than accepting whatever a supplier's PDF asserted.

And the platform compounds. The identifier service, the access tier model, the supplier data pipeline, the archive and the resolver are all horizontal by construction, because the standards that define them are horizontal by design. Build them for batteries in 2027 and the marginal cost of textiles or steel in 2029 is a schema and a data source, not a programme. That is the difference between a compliance line item that recurs every two years and a capability you build once.