Short answer: On 30 October 2026 the European Commission published the technical documentation for the API of the EU DPP registry. It explains how software registers passports automatically. A service account is a technical account used by software instead of a person. It authenticates each request for a verified economic operator, the company responsible for the product. One submission can hold up to 100 passports. The registry then fetches each passport itself, at the web address in its product identifier. The product-specific registration schema published so far covers batteries only. Eleven days earlier, on 19 October, the Commission's battery guidance V3.2 classified 71 numbered battery data points for February 2027. That guidance creates no legal obligations and does not represent the Commission's official position. The obligation itself comes from Article 77(1) of the Batteries Regulation: from 18 February 2027, batteries for electric vehicles (EV), batteries for light means of transport such as e-bikes (LMT) and industrial batteries above 2 kWh need a battery passport when they are placed on the market or put into service.

What did the Commission publish in October 2026?

All documents are on the Commission's DPP resources and documentation page. The registry went live on 20 July 2026 with a testing environment; our post on the registry launch covers what that meant. Implementing Regulation (EU) 2026/1778 sets the legal rules for the registry. The October documents explain how your systems connect to it. They add to the existing user guide for the registry website.

[HTML EMBED: overview table, see block 2]

According to the Commission, the testing features described in the guidelines "will become available gradually before the Registry goes live". A published interface description therefore does not by itself prove that every function already works. The October guides are version 1.0, the OpenAPI files and the semantic data files version 1.0.0. These are first versions, so expect changes, and check for newer ones before you build. The DPP Registry User Guide for Economic Operators covers the website. The version on the resources page is v1.03 of 16 September 2026, so it predates the October guidelines and cannot reflect them yet. This matters, because the guide warns that at that point battery passports could not yet be registered successfully: the semantic catalogue for batteries had not been defined. The October files now describe that catalogue. Whether registration now works end to end is something you should test yourself before you rely on it.

How does the DPP registry API handle registration?

One submission, up to 100 passports

The API Integration Guide sets the batch size: you submit the registration data for 1 to 100 passports per API request. All entries in one submission must belong to the same product group and, where there is one, the same subgroup, for example EV batteries.

When the registry accepts the request, it answers with HTTP 202 and a task ID. This only means the request has been accepted for processing. It does not tell you whether processing has started or whether the passports are registered. With the task ID you follow the processing in the activity dashboard, the registry's overview of your submissions. You can retrieve the results for each passport as JSON or CSV.

The registry handles each submission on an all-or-nothing basis (the guide calls this atomic). If a single passport fails the check, none of the passports in that submission is registered. The status COMPLETED only means that processing has finished. The outcome can still be FAILED. So check the outcome, and use the results per passport to find the cause.

Send an Idempotency-Key with every submission. This is a unique key you choose yourself, and it prevents a repeated request from being counted twice. If you resend the same submission unchanged, for example after a timeout, reuse the key. If you change the submission, use a new key.

For small volumes, the user guide describes two ways through the website: an online form for a single passport, or the upload of a JSON or XML file. You sign in with EU Login. Our post on how to register a DPP in the EU registry walks through the steps.

The registry reads your passport at its URL

You do not upload the passport itself, only the registration data. The registry then fetches the passport on its own, using the unique product identifier, which has to be an HTTPS web address. If it cannot reach the passport during the check, registration fails. According to the Commission's Semantic Data Guide, the registry requests the passport as JSON, the mandatory format under EN 18216:2026. Your hosted passport therefore has to be available as JSON, whatever else it also offers. The registry keeps a registration record, not the passport. So your identifier and hosting have to be working before you register. Our post on the six harmonised DPP standards explains how the standards fit together.

Which product groups does the API cover so far?

Only batteries. The OpenAPI specification describes the API calls in machine-readable form. Version 1.0.0 contains one submission type only: the registration of battery passports. The semantic data files define the passport data in three layers: a general DPP core, a layer for batteries, and below it one layer each for EV, industrial and LMT batteries. Besides the core, they contain files for batteries only. The package includes JSON schemas that check the structure of the data, SHACL shapes with validation rules for linked data, and JSON-LD contexts that give each JSON field a shared, defined meaning. It also contains shared vocabularies and example documents.

Each battery is registered individually. That does not mean every data point is unique to one battery: the battery guidance generally refers to the battery model and marks the exceptions for individual batteries.

How do service accounts authenticate API requests?

The Service Account Technical Integration Guide describes access for software. A service account is bound to one verified organisation. What it may do is limited to that organisation and to the permissions assigned to the account.

The sign-in works in three steps. First, your system creates a JWT client assertion, a signed proof of identity, and signs it with the account's private key. The guide recommends a validity of 60 to 120 seconds; the absolute maximum is five minutes. Second, your system requests an access token through OAuth 2.0 Client Credentials, a standard procedure for software-to-software access. It authenticates with the method private_key_jwt and sends the signed proof along. The access token is valid for at most 15 minutes. Third, your system sends the token with each registry API call. The private key stays with the economic operator.

Before that, the organisation itself has to be verified. Article 4(2) of Implementing Regulation (EU) 2026/1778 distinguishes whether a legal person is required to be established in the Union. If it is, it proves its identity and establishment with a qualified electronic seal or a qualified electronic attestation of attributes. The latter is a certified electronic confirmation of company details. Different provisions apply to legal persons without that requirement. People working in the registry website sign in with EU Login.

In practice: the economic operator placing the battery on the market or putting it into service is responsible for the registration. Where Union law permits, a verified third party can carry out registration actions on your behalf, but you remain responsible. A DPP provider can host the passport for you. You have to authorise any connection through your organisation's service account. The provider can then only use the permissions assigned to that account. Complete the verification of your organisation before you attempt API registration.

How does the registry access protected passport data?

Parts of a battery passport are not public. The Self-Hosted Authentication Guide describes how the registry reads them anyway. Your host serves the public data to anyone, without sign-in. For the protected data, the registry presents an access token from the Commission's authentication service. Your host, or a hosting provider acting for you, checks this token and its own access rules. Only then does it return the public and protected data together.

The battery schemas split the passport into one public view and three restricted views. Their audiences overlap:

• RES1: persons with a legitimate interest, notified bodies, market surveillance authorities and the Commission
• RES2: notified bodies, market surveillance authorities and the Commission
• RES3: persons with a legitimate interest, for data on the individual battery

Our post on battery passport access rights explains how these views relate to the access rules in the regulation.

Which battery data points does guidance V3.2 classify for February 2027?

The Commission's guidance "Digital Batteries Passport: data points by category" (version 3.2 of 19 October 2026) contains 71 numbered data points. For each data point, it gives the classification for February 2027, separately for EV, LMT and industrial batteries. A field can be mandatory, optional or relevant only in certain cases. Other fields it classifies as not yet to be filled or shown. The guidance itself says that it does not represent the Commission's official position and creates no obligations. The binding rules are in the Batteries Regulation.

Which fields does the guidance classify as not to be filled or shown in February 2027? Examples:

• carbon footprint declaration and label: the guidance points out that their format still awaits an implementing act
• responsible-sourcing information: the guidance refers to the due-diligence obligations, which apply from 18 August 2027
• recycled-content shares for cobalt, lithium, nickel and lead
• printable instructions for use: the guidance refers to the pending Omnibus

These examples report how the guidance classifies the fields. They are not exemptions from the law, so check the applicable legislation before you leave a field empty. Unless stated otherwise, the data refers to the battery model, not to the individual battery. The full list of what goes into the passport, and who needs one, is in our battery passport guide; the data carrier is covered in our post on the battery QR code requirement.

What should you do before 18 February 2027?

• Complete the verification of your organisation in the registry if you have not done so.
• Map your battery data against the V3.2 list, model by model, and mark what the guidance classifies as mandatory in February. Note the fields that apply to the individual battery.
• For every battery that needs a passport under Article 77(1), make sure its product identifier resolves over HTTPS to a passport that is available as JSON.
• Decide who serves the protected views and how the registry token is checked.
• Once the test features are available, submit a test batch. Include a batch that fails the check, resend an unchanged submission with the same idempotency key, and send a corrected one with a new key.

About three months remain. The dates for other product groups are in our DPP timeline and, per product group, on the Compliance page.

How dpp.cloud fits

dpp.cloud builds passports from your product data, for example from a PIM system for product information or an ERP system for business processes. It also creates a QR code following GS1 Digital Link that opens the passport. How that works is described in creating a DPP from PIM data, in DPP integration with SAP and in our post on GS1 Digital Link. dpp.cloud does not register passports in the registry; that stays with you as the economic operator. If you want to go through the guidelines against your own setup, book a strategy session.

Sources

• European Commission, Digital Product Passport: resources and documentation (API Integration Guide, OpenAPI Specifications, Semantic Data Guide and Artifacts, Service Account Technical Integration Guide, Self-Hosted Authentication Guide, all 30 October 2026; DPP Registry User Guide for Economic Operators v1.03 of 16 September 2026; battery guidance V3.2 of 19 October 2026): single-market-economy.ec.europa.eu/single-market/digital-product-passport/resources-documentation_en
• European Commission, "The Digital Product Passport Registry is now live" (20 July 2026): single-market-economy.ec.europa.eu/news/digital-product-passport-registry-now-live-2026-07-20_en
• Implementing Regulation (EU) 2026/1778 (DPP registry), Article 4: data.europa.eu/eli/reg_impl/2026/1778/oj
• Regulation (EU) 2023/1542 (Batteries Regulation), Articles 48 and 77: eur-lex.europa.eu/eli/reg/2023/1542/oj