Registering 100 DPPs at Once: What the DPP Registry Batch File Upload Actually Requires

The EU Central DPP Registry accepts two submission methods: a single-record online form and a file upload that supports either one DPP or a full batch. If you are registering products at scale, the batch file upload path is the one you will use. This article explains exactly what the Registry requires, what causes rejections, and how to track results once a batch is submitted.

Two Submission Methods, One Batch File Upload Path

According to the Commission’s launch announcement, registration is available through either a secure user interface or an application programming interface (API). The user interface covers both the single-record form and the file upload option. The API is the route for operators who want to integrate registration directly into their production or ERP systems.

For teams working in the interface, the file upload option handles both single-DPP submissions and batches. The practical ceiling for a batch is 100 DPPs per submission. If you need to register more than 100, you split the work across multiple submissions.

File Format: XML or JSON Only

The Registry accepts batch files in two formats: XML and JSON. No other formats are supported. The DPP Registry User Guide for Economic Operators provides a downloadable template for each format. Using the template is the safest starting point because the Registry validates structure as well as content. A file that is valid JSON but does not match the expected schema will still be rejected.

The maximum file size is 1 GB. Files above that limit are rejected immediately, and the Registry returns a stated error. In practice, 100 DPP records will rarely approach 1 GB, but the limit matters if you are embedding large data payloads or binary-encoded content inside the file.

File Naming Rules

File names must contain only alphanumeric characters (a to z, A to Z, 0 to 9), plus three permitted special characters: dot, underscore, and hyphen. Spaces, slashes, and any file path navigation characters are rejected. This means a file named batch_2026-07.xml is valid, but batch upload/july.xml is not.

This rule exists because the Registry processes file names as identifiers. Path navigation characters such as ../ or ./ create security risks in server-side file handling, so the Registry blocks them outright. Check your file name before uploading, not after a rejection.

URL Validation Inside the Batch

Each DPP record in the batch will reference one or more URLs, for example the URL pointing to the DPP data itself. Every submitted URL must start with https://. The Registry rejects any URL that is invalid or that uses a non-HTTPS scheme. Plain HTTP URLs will fail validation.

This requirement follows from the security expectations built into the DPP framework. The Registry is not the place to discover that a URL in your product data system is malformed or still pointing to a staging environment over HTTP. Validate all URLs in your source data before generating the batch file.

The All-or-Nothing Validation Rule

This is the rule that catches most teams off guard. The User Guide states clearly that when submitting multiple DPPs, if a single DPP has an error, all the DPPs in the same submission will be rejected. There is no partial success in a batch. One bad record fails the entire file.

The practical consequence is that pre-submission validation is not optional. You need to check every record in the batch before you upload. Common error sources include missing mandatory fields, malformed URLs, file name violations, and data that does not match the expected schema. For a full breakdown of what each error message means and how to fix it, see every DPP Registry error message explained.

If you are building a process to register products regularly, the all-or-nothing rule means your internal validation step must run before the file reaches the Registry, not after. A single data entry error in record 87 of a 100-record batch will cost you the entire submission.

What Happens After You Submit

When the Registry receives a batch file, it assigns a correlation ID to the request. It also provides a time estimate for how long validation will take. You do not need to stay on the page. Status is tracked in the Activity Dashboard, which shows one of three states: PROCESSING, SUCCESS, or FAILURE.

PROCESSING means the file is still being validated. SUCCESS means all records in the batch passed and have been registered. FAILURE means at least one record failed, which under the all-or-nothing rule means the entire batch was rejected.

A successful request detail shows, for each DPP: the Unique Product Identifier (UPI), the URI, and the associated product group. A failed request shows the UPI, the product group, and a specific error description for each failed DPP. You can export those error descriptions as a CSV file, which makes it practical to hand the error list to whoever manages the source data for correction.

Preparing a Batch File: A Step-by-Step Checklist

1. Download the XML or JSON template from the Registry.
2. Populate the template with your DPP records. Keep the batch at or below 100 records.
3. Confirm that every URL in the file starts with https:// and resolves correctly.
4. Check that all mandatory fields are present in every record. A missing field in one record fails the whole batch.
5. Name the file using only alphanumeric characters, dots, underscores, and hyphens. Remove any spaces or slashes.
6. Confirm the file is under 1 GB.
7. Upload the file through the Registry interface or submit via the API.
8. Note the correlation ID assigned to your submission.
9. Monitor the Activity Dashboard until the status moves from PROCESSING to SUCCESS or FAILURE.
10. If the status is FAILURE, export the error CSV, correct the identified records, and resubmit the full batch.

API Submission vs. Interface Upload

The file format and validation rules are the same whether you submit through the interface or the API. The API route is better suited to operators who register products continuously, for example as units come off a production line. The interface route is more practical for periodic bulk registrations, such as registering a new product range at the start of a season.

Both routes produce the same correlation ID, the same Activity Dashboard entries, and the same error output on failure. The choice of route does not affect what the Registry accepts or rejects.

What the Batch File Does Not Cover

The batch file registers the DPP with the Registry. It does not create the DPP data itself. The DPP data, including the fields required under the applicable ESPR delegated act for your product category, must already exist and be accessible at the URL you are registering. The Registry records the pointer. The data must already be behind it.

For battery products specifically, the data requirements are set out in Regulation (EU) 2023/1542, with the fields accessible to different parties defined in Annex XIII. Point 1 of Annex XIII covers data accessible to the general public. Points 2, 3, and 4 cover progressively restricted access tiers for parties with a legitimate interest, notified bodies, market surveillance authorities, and the Commission. For other product categories, the applicable delegated act under the Ecodesign for Sustainable Products Regulation will define the required data. Most of those delegated acts are still in development, with adoption expected in the period from 2026 onward, pending Commission decisions.

If you are ready to start registering DPPs and want a platform that validates your data before it reaches the Registry, visit traceable.digital/pricing to start a free trial. Traceable checks your records against the Registry’s requirements before submission, so a single bad field does not take down your entire batch.