API Requirements for ESPR DPP Systems
ESPR Article 8 requires that the Digital Product Passport be accessible via a data carrier that complies with open standards and is interoperable. In practice, this means that DPP data must be accessible via a REST API that returns JSON-LD data. The API must be publicly accessible (for public data fields), must respond within a reasonable time, and must be available throughout the product's lifetime.
The EU DPP technical specification (published under ESPR Article 13) defines the specific API requirements for DPP systems. These requirements are based on the GS1 Digital Link resolver specification and the W3C JSON-LD standard. Any DPP system — whether self-hosted or provided by a third-party service — must implement these API requirements to be compliant with ESPR.
Core API Requirements
| Requirement | Specification | Notes |
|---|---|---|
| Protocol | HTTPS (TLS 1.2 or higher) | HTTP not acceptable |
| Method | GET | DPP data retrieval is read-only |
| Response format | JSON-LD (application/ld+json) | Content negotiation required |
| HTML fallback | text/html for browser requests | Human-readable page for consumers |
| Response time | <2 seconds (95th percentile) | EU DPP technical specification target |
| Uptime | 99.9% annual availability | Equivalent to <8.7 hours downtime per year |
| Authentication | None for public data; OAuth 2.0 for restricted data | Market surveillance authorities use OAuth |
| Versioning | API version in URL path (e.g., /v1/) | Backward compatibility required |
| Error responses | Standard HTTP status codes with JSON error body | 404 for unknown product, 403 for unauthorised |
GS1 Digital Link Resolver Implementation
The DPP API must implement the GS1 Digital Link resolver specification. When a GS1 Digital Link URL is sent to the resolver (via an HTTP GET request), the resolver must return a link set document (in application/linkset+json format) that lists all available data endpoints for that product. The link set document includes links to the DPP data (application/ld+json), the human-readable product page (text/html), the EU Declaration of Conformity (application/pdf), and any other data endpoints defined in the applicable delegated act.
The link set document is the key to context-dependent data access. A consumer scanning the QR code with their smartphone receives the text/html link and is directed to the human-readable product page. A recycler's software sends an Accept header of application/ld+json and receives the full DPP data record. A market surveillance authority's system sends an OAuth token and receives the restricted data fields including the full technical documentation.
Data Update API
For products with dynamic DPP data fields (such as State of Health for batteries), the DPP system must implement a data update API that allows authorised parties to update the DPP data record. The update API must be authenticated (OAuth 2.0) and must maintain an audit log of all data changes. The audit log must be accessible to market surveillance authorities.
REST API Architecture for ESPR DPP Systems
The EU product database and third-party DPP platforms that integrate with it must implement REST APIs following the OpenAPI 3.0 specification. The core API endpoints for an ESPR-compliant DPP system are: GET /products/{identifier} (retrieve a single product's DPP by its unique identifier), GET /products (list products with filtering by manufacturer, product category, and date range), POST /products (register a new product DPP), PUT /products/{identifier} (update an existing product DPP), GET /products/{identifier}/history (retrieve the version history of a product DPP), and GET /products/{identifier}/verify (verify the cryptographic signature of a product DPP). All endpoints must support JSON-LD as the primary response format, with XML as an alternative format selectable via the Accept header.
Authentication and Authorisation for DPP APIs
ESPR DPP APIs must implement role-based access control to ensure that commercially sensitive data is only accessible to authorised parties. The authentication mechanism will be based on OAuth 2.0 with OpenID Connect, using the EU's eIDAS (Electronic Identification, Authentication and Trust Services) framework for identity verification. Three access levels are defined: public access (no authentication required) for the data fields specified as publicly accessible in the delegated act; economic operator access (EORI-based authentication) for supply chain partners and retailers; and market surveillance authority access (EU authority credentials) for full DPP data including commercially sensitive fields. Manufacturers that operate their own DPP APIs must implement these three access levels and ensure their API is compatible with the EU product database's authentication system.
Rate Limiting and SLA Requirements for DPP APIs
The ESPR regulation requires that DPP data be accessible throughout the product's lifetime. For products with long lifetimes, this means the DPP API must be operational for decades. The EU product database will specify minimum SLA (Service Level Agreement) requirements for DPP APIs, including: minimum uptime of 99.9% (approximately 8.7 hours downtime per year), maximum response time of 500 ms for single product lookups, maximum response time of 5 seconds for bulk data exports, and rate limiting of at least 1,000 requests per minute per authenticated user. Third-party DPP platforms that cannot meet these SLA requirements should not be used for ESPR compliance, as a DPP that is inaccessible when a market surveillance authority attempts to verify it constitutes non-compliance.
DPP API Rate Limiting and Availability Requirements
The ESPR DPP API must be available 24/7 for the lifetime of the product. For products with long lifetimes (construction products, industrial equipment), this means the API must be maintained for 25–50 years. Manufacturers should plan for the long-term maintenance of their DPP API infrastructure, including provisions for technology migration (as web technologies evolve over decades), business continuity (if the manufacturer is acquired, merged, or ceases operations), and data portability (the ability to migrate DPP data to a new platform if the current platform is discontinued). The EU product database established under Article 12 of ESPR provides a fallback for DPP data access if the manufacturer's own API is unavailable, but manufacturers should not rely on the EU product database as their primary DPP data source.
Register Your Digital Product Passport
The EU DPP Registry goes live on 19 July 2026. Register now at Africa's first ESPR-compliant DPP registry.
Register Your Digital Product Passport →API Architecture for ESPR DPP Systems
The API (Application Programming Interface) requirements for ESPR DPP systems define how DPP data is exchanged between manufacturers, registry providers, market surveillance authorities, customs systems, and end-users. The Commission is developing API specifications based on the W3C Verifiable Credentials Data Model and the GS1 Digital Link standard. These specifications will be published in the ESPR implementing regulations and will be mandatory for all DPP registry providers operating in the EU market.
The core API operations required for ESPR DPP systems include: Create DPP (POST /dpp) — creates a new DPP record in the registry; Read DPP (GET /dpp/{id}) — retrieves the DPP data for a specific product; Update DPP (PUT /dpp/{id}) — updates the DPP data for a specific product (for lifecycle updates); Verify DPP (GET /dpp/{id}/verify) — verifies the cryptographic signature of a DPP; Search DPPs (GET /dpp?query=...) — searches for DPPs by product identifier, manufacturer, or product category; and Revoke DPP (DELETE /dpp/{id}) — revokes a DPP (for recalled products). All API operations must be authenticated using OAuth 2.0 or an equivalent authentication protocol.
The API must also support batch operations for manufacturers who need to create or update large numbers of DPPs simultaneously. Batch operations are essential for manufacturers with large product catalogues — a smartphone manufacturer who sells 100 different models in 50 different configurations cannot create DPPs one at a time. The batch API must support the creation of up to 10,000 DPPs per request and must provide detailed error reporting for failed DPP creation attempts.
Frequently Asked Questions
Manufacturers can use a DPP registry provider (such as the National DPP Registry at digitalproductpassports.co.za) to host their DPP data and provide the required API. This is the recommended approach for most manufacturers, as it avoids the need to build and maintain a DPP API infrastructure. Manufacturers who choose to self-host their DPP data must implement an API that meets the ESPR requirements.
The ESPR implementing regulations are expected to require OAuth 2.0 authentication for DPP API access. OAuth 2.0 is the industry standard for API authentication and is supported by all major programming languages and frameworks. The specific OAuth 2.0 flow required (client credentials, authorisation code, etc.) will be specified in the implementing regulations.
Market surveillance authorities must have access to all DPP data, including restricted data that is not publicly accessible. The DPP API must support a privileged access mode for market surveillance authorities that bypasses the normal access control restrictions. The implementing regulations will specify the authentication mechanism for market surveillance authority access.
The ESPR implementing regulations are expected to set minimum uptime requirements for DPP APIs. Given that DPP data must be accessible throughout the product's lifecycle (which may be 25–30 years for some products), the uptime requirements are likely to be stringent — potentially 99.9% or higher. Registry providers must have robust infrastructure and disaster recovery plans to meet these requirements.
The EU customs system (ICS2) is being updated to support DPP verification at EU borders. Customs authorities will be able to query the DPP API to verify that a product has a valid DPP before allowing it to enter the EU market. The DPP API must support customs verification requests and must respond within a specified time limit (likely 5 seconds or less) to avoid delays at customs checkpoints.