How to Register a DPP in the EU Registry, and What Happens After Submission

Registering a Digital Product Passport in the EU Registry is not the act of uploading the complete passport to Brussels. The complete DPP remains decentralised. The economic operator hosts the DPP data itself or uses a service provider, gives the product a Unique Product Identifier that resolves to that data and then registers the required Registry record. If the Registry's checks pass, it creates a persistent unique registration identifier for that registration. There is one current operational caveat that has to be read before the steps below: Commission User Guide v1.02 says successful Battery DPP registration is not currently available because the Battery semantic catalogue/content has not yet been defined. Batteries are the first product group shown in the current workflow, so businesses can rehearse the process but should not mistake workflow availability for completed registration availability.

The journey in one view

Complete DPP hosted outside Registry → verified economic operator → choose applicable product group and granularity → submit Registry data → receive correlation ID → Registry validation → success or failure → unique registration identifier on success → proof/lifecycle management as needed.

If your organisation has not yet passed verification, start with How to enrol your organisation in the EU DPP Registry.

Current operational state

Those operational details are versioned. The legal architecture is more durable than the current interface.

Before registration: the DPP has to exist somewhere else

The most important architectural point comes before the Registry form.

The Registry is an EU-level index and registration system. It is not the repository containing the complete product passport.

Your DPP data remains under the responsibility of the economic operator and may be hosted by the operator or a DPP service provider. The Unique Product Identifier used for registration has to resolve to the hosted DPP data.

That is why where passport data lives is the canonical architecture question. Registration connects the Registry record to a decentralised DPP. It does not replace the DPP.

What the Registry checks

Commission Implementing Regulation (EU) 2026/1778 sets out automated checks around the registration event. Depending on what the applicable product legislation requires, these include:

• semantic conformity of the DPP data
• coherence between mandatory Registry data and data in the DPP
• conformity with the required granularity level
• validity of the commodity code within permitted ranges where relevant
• the link to a service-provider backup where relevant.

Those checks are technical and structural gates.

They are not a regulatory certification of the product. The implementing regulation explicitly leaves substantive correctness to market surveillance under the applicable Union rules. ESPR also says communication of the unique registration identifier is not proof of product compliance.

Keep that distinction in your own data model:

REGISTERED is not a synonym for COMPLIANT.

Step 1: confirm that you are the verified actor responsible for registration

The relevant economic operator must be verified before it can register and manage DPPs in the Registry.

A third party may act on behalf of the economic operator where the law and Registry permissions allow it, but Article 19 of Regulation (EU) 2026/1778 keeps responsibility with the economic operator for the accuracy and completeness of information submitted and for keeping Registry information up to date.

Outsourcing the click does not outsource the obligation.

For the distinction between a verified operator and a software/service provider, read Who is allowed to hold your passport data, and what they may do with it.

Step 2: identify the product law, product group and required granularity

The Registry does not choose the legal level of the passport for you.

The applicable product-specific act determines whether the DPP belongs at model, batch or item level. The implementing regulation then requires the registration to conform to that level and contains relationship rules between item, batch and model where those levels exist.

In the current User Guide v1.02 workflow, Batteries is pre-selected as the first product group and item is the currently available level for that product group.

Do not generalise that into “all DPPs are item-level”. They are not.

Use How many passports a range needs, and why it is not settled for the cross-category rule.

Step 3: make sure the Unique Product Identifier resolves

The current guide requires a Unique Product Identifier, UPI, and describes it as a mandatory URL-form value that resolves to where the DPP data is hosted.

The current UI validation expects HTTPS URL formatting.

That creates three things that are easy to confuse:

1. Unique Product Identifier: identifies the DPP/product object for the registration
2. the hosted DPP: the decentralised data the identifier resolves to
3. unique registration identifier: generated by the Registry after successful registration.

Do not call all three “the DPP URL”. They have different jobs.

For the identifier layer itself, use Barcodes and Product Identifiers.

Step 4: choose the submission route

Online registration form

Under User Guide v1.02, the online form is the single-DPP route.

A user selects the current product group and granularity and supplies the required registration information. For the current Battery item-level route, the guide shows the UPI as mandatory and model/batch identifiers as optional relationship fields in the form.

File upload

The current guide also documents file submission for one or multiple DPPs.

Current v1.02 constraints include:

• XML or JSON
• maximum 100 registration requests in one file submission
• maximum 1 GB file size
• template files available through the interface for the documented formats.

If one DPP in a multi-DPP submission has an error, the guide says all DPPs in that submission are rejected.

That should affect your operational batching strategy. It does not mean the legal maximum should become your default batch size.

API

The implementing regulation establishes an API for registering DPPs and receiving information from the Registry. Article 8 treats secure user interface and API as registration routes and Article 9 allows proof of registration through either route.

As at 3 September 2026, the current economic-operator guide provides detailed operational instructions for the user-interface form/file workflow. ActivateDigital has not verified public production API documentation complete enough to publish stable endpoint, authentication and payload instructions as a standalone implementation guide.

So do not infer them.

Design an API-ready adapter if scale justifies it, but wait for sufficient official integration documentation before treating an assumed API contract as production truth.

Step 5: submit and store the correlation ID

The current guide says a submitted registration request receives a correlation ID and an estimated validation time. The Activity Dashboard is then used to inspect the request status.

Treat the correlation ID as operational reconciliation data.

For every attempt, your internal record should be able to answer:

• which product/DPP was submitted
• by which organisation
• through which route
• using which source data version
• at what time
• with which correlation ID
• what the Registry returned
• whether the attempt needs human action.

That turns a website interaction into an auditable process.

Step 6: distinguish processing, success and failure

User Guide v1.02 describes request outcomes including:

• PROCESSING for requests whose validation has not finished
• SUCCESS for completed successful requests
• FAILURE for failed requests.

For successful requests, the current guide says the details include the UPI, the Registry-generated unique registration identifier and the associated product group.

For failures, it gives the affected UPI, product group and error description, with an option to export error details as CSV.

The key design decision is not the label. It is what your system does next.

A failure should route to one of at least three owners:

• product-data owner if your data is wrong or incomplete
• identity/identifier owner if the UPI/resolution is wrong
• system dependency watch if the Commission validation capability is unavailable.

The current Battery semantic limitation belongs in the third category.

The current Battery limitation

The Commission's v1.02 guide is unusually explicit:

Successful registration of DPPs for batteries is not currently available because the semantic catalogue/content for the product group has not yet been defined.

That sentence prevents a common but important mistake.

The following can all be true at the same time:

• the Registry is operational
• organisations can enrol
• the test environment is operational
• the Battery registration screens exist
• Battery Passport law has an application date of 18 February 2027 for covered batteries
• successful Battery registration is not currently available in the current Registry workflow.

Do not compress those six states into one green “Registry live” flag.

The versioned state belongs on the Registry Operational State Snapshot.

What success creates

When the Registry's required checks succeed, Regulation (EU) 2026/1778 requires it to generate and store a unique and persistent registration identifier as part of the registration data and communicate it to the relevant actor through the interface or API used.

The Registry also stores defined registration information including, where relevant:

• unique identifiers
• commodity code
• service-provider reference
• registrant information including date/time and integrity information.

For the more detailed record, use What the Registry records about you.

What success does not create

A successful Registry event does not mean:

• the DPP content is factually correct in every respect
• environmental claims are substantiated
• conformity assessment has been completed where another law requires it
• every downstream access right is satisfied
• the product is lawful to place on the market simply because a registration identifier exists.

This boundary is explicit in the law, not an ActivateDigital disclaimer added afterwards.

Proof of registration is a separate artefact

After a DPP has been registered, Regulation (EU) 2026/1778 allows the responsible economic operator, or where relevant a third party acting on its behalf, to generate a proof of registration for one or more DPPs.

That proof is evidence that the registration obligation has been fulfilled. It is not a product compliance certificate.

The implementing regulation says it includes at least:

• UPI
• commodity code where relevant
• identity of the verified economic operator
• registration date and time for the latest version
• hash of the DPP version.

It is protected by a qualified Commission seal and electronic timestamp and remains available for 90 calendar days from generation, with regeneration possible.

That distinction is important enough to have its own owner: What proof of registration proves.

Registration is a lifecycle, not a one-off upload

The implementing regulation requires changes to registration data, including creation, modification and deletion, to be logged. It supports versioning and Commission timestamps for updates.

Where Union law sets no specific DPP availability period, the implementing regulation uses a default ten-year retention period for the registration data after registration. Product-specific law can set another period.

A business therefore needs ownership for:

• changes to product identity or registration data
• corrected DPP versions
• changes of responsible operator
• service-provider changes where relevant
• commodity-code changes where relevant
• evidence/proof regeneration
• end-of-responsibility and transfer events.

If the business itself changes hands, use What happens to your passports when the business changes hands.

If the commodity code changes after registration, use DPP Registration and Commodity Code Changes.

A minimum internal registration record

The Registry is the authority for the official registration record. Your own system still needs enough information to operate responsibly.

A useful internal record should retain:

Do not manufacture a unique registration identifier locally. It is generated by the Registry on successful registration.

What to do now

DO NOW

If your organisation expects to register DPPs:

• establish the verified operator identity
• decide where complete DPP data will be hosted
• make the UPI/resolution layer reliable
• keep product group and granularity separate in your model
• create an auditable local registration-attempt record.

TEST NOW

Use the Commission test environment to rehearse the current flow and failure handling. Test batches, UPI failures and organisation verification, not just the happy path.

PREPARE

Build a transport-independent registration service if you expect high volumes. Your business logic should not depend on whether the eventual production submission is made by form, file or API.

WATCH

Watch for:

• Battery semantic catalogue availability
• successful Battery registration becoming available
• new product groups
• changed granularity choices
• updated User Guide constraints
• stable public API technical documentation.

DO NOT HARD-CODE

Do not hard-code the current Battery product selection, item-only UI state, 100-request file limit or current error strings as universal DPP rules.

Direct questions

Does the EU Registry store the complete DPP?

No. The complete DPP remains decentralised. The Registry stores the registration record and defined Registry data.

Can I register by file?

Yes. User Guide v1.02 documents XML/JSON file upload for a single DPP or multiple DPPs, currently up to 100 registration requests per file.

Can I register by API?

The implementing regulation establishes an API registration route. ActivateDigital is not publishing implementation-level endpoint/authentication instructions until sufficiently complete official production documentation is verified.

What do I receive after a successful registration?

The Registry generates a unique persistent registration identifier and communicates it through the route used. A separate proof-of-registration document can then be generated where needed.

Does the registration identifier prove compliance?

No. ESPR expressly says it is not proof of compliance, and the Registry implementing regulation distinguishes automated technical checks from substantive correctness.

Can I register a Battery DPP successfully today?

Under Commission User Guide v1.02, no. The guide says successful Battery registration is currently unavailable because the product group's semantic catalogue/content has not yet been defined.

What would change this page

Recheck on every new Commission Registry User Guide, semantic-catalogue release, product-group release, change to form/file limits or publication of stable production API integration documentation.

Primary and official sources

• European Commission, The DPP Registry

  View official source

• European Commission, DPP Registry User Guide for Economic Operators, v1.02, last published 24 August 2026, especially Chapters 6, 8 and 9

  View official source

• Commission Implementing Regulation (EU) 2026/1778, especially Articles 3, 8, 9, 10, 11, 12 and 19

  View official source

• Regulation (EU) 2024/1781 establishing ESPR, especially Articles 9 to 15

  View official source

• European Commission, Batteries and the Digital Product Passport

  View official source

https://single-market-economy.ec.europa.eu/single-market/digital-product-passport/batteries_en