--- title: "EU Digital Product Passport API and resolver architecture" canonical_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/api-and-resolver-architecture" source_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/api-and-resolver-architecture" author: "Sorena AI" description: "Grounded DPP architecture guidance for data carriers, product identifiers, resolver lookup paths, access rights, registry integration, and interoperability without premature protocol mandates." published_at: "2026-05-09" updated_at: "2026-05-09" keywords: - "EU Digital Product Passport" - "DPP API architecture" - "DPP resolver architecture" - "data carrier" - "unique product identifier" - "DPP registry" - "DPP access rights" - "DPP interoperability" - "Digital Product Passport" - "API architecture" - "resolver architecture" - "registry" - "access rights" - "interoperability" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Digital Product Passport API and resolver architecture Grounded DPP architecture guidance for data carriers, product identifiers, resolver lookup paths, access rights, registry integration, and interoperability without premature protocol mandates. *DPP* *Architecture* *EU* ## EU Digital Product Passport API and Resolver Architecture Design the lookup path from data carrier to product passport without hard-coding an unsupported protocol choice. This guide separates binding ESPR requirements from implementation choices for identifiers, resolvers, registries, access control, and interoperable data exchange. The EU Digital Product Passport is not just a public webpage behind a QR code. Under the ESPR, the passport is product-specific data made accessible through a data carrier and connected to persistent identifiers, access rights, registry records, and a Commission web portal. Architecture work should therefore start with the legal objects that must survive implementation choices: the product identifier, data carrier, passport data, registry upload, access-control model, resolver or lookup path, and backup availability. ## Start with the binding ESPR architecture objects The ESPR requires the applicable product-group delegated act to specify the passport data, one or more data carriers, the carrier layout and position, whether the passport is at model, batch, or item level, the pre-contract access method, and which actors can access, create, or update which data. That means an API design should not begin by choosing a fashionable endpoint pattern. It should begin by recording which delegated-act fields, identifier granularity, access rights, and availability period the product group actually requires. At the technical baseline, the passport must be connected through a data carrier to a persistent unique product identifier. The data carrier must be physically present on the product, packaging, or accompanying documentation as specified by the delegated act. Passport data must use open standards, interoperable formats, and be machine-readable, structured, searchable, and transferable through an open interoperable data exchange network without vendor lock-in. - Treat model, batch, and item identity as an architecture decision, not a content-label decision. - Keep the data carrier, unique product identifier, operator identifiers, facility identifiers, and passport data model separately versioned. - Design public access, restricted access, update rights, and authority access as different authorization cases. - Keep personal data out of the passport unless there is explicit customer consent under the GDPR basis referenced by the ESPR. - Maintain a backup-copy path through a DPP service provider where the responsible economic operator uses one. Sources for this answer: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Articles 9 to 11 define the DPP requirement, data carrier connection, persistent unique product identifier, open/interoperable data requirements, access-right controls, and backup-copy expectations. ## Separate the data carrier from the resolver A data carrier is the physical or machine-readable entry point. It may encode or expose a unique product identifier, a web link, or another standards-based identifier form selected by the applicable rules and standards. The resolver is the lookup component that turns the scanned or supplied identifier into the available passport links or data sources. Keeping those responsibilities separate makes it easier to change carriers, add a backup service, support batch lookup, or point different actors to different views without relabelling every product. CIRPASS describes both HTTP URI and decentralized identifier approaches as architectural options, not as a binding mandate. Its user stories show the same core pattern: scan or receive a product identifier, obtain a usable URI or resolver endpoint, receive typed links for that identifier, select the relevant link, and request data from the data source with the credentials appropriate to the requester. - The carrier should be readable for the product context and durable enough for the expected product life. - The identifier should remain stable even when the passport data, hosting provider, or role-specific views change. - The resolver should return enough typed links for public, authority, repair, recycling, and backup use cases without exposing restricted data by default. - The data source should enforce access rights; the resolver should not become a shortcut around authorization. - The architecture should tolerate the responsible operator or a service provider changing infrastructure over time. Sources for this answer: - [CIRPASS D3.2 DPP System Architecture](https://cirpassproject.eu/wp-content/uploads/2024/06/D3.2v1.9.pdf?ref=sorena.io) - CIRPASS provides implementation-neutral resolver flows for HTTP URI and DID architectures, including data-carrier scanning, typed-link resolution, credentialed requests, and backup considerations. - [ETSI TS 103 881 V1.1.1](https://www.etsi.org/deliver/etsi_ts/103800_103899/103881/01.01.01_60/ts_103881v010101p.pdf?ref=sorena.io) - ETSI explains the practical tradeoff between product-carrier storage and online passport access, including the need for URLs or links to remain accessible over the product's circular lifespan. ## Design registry and portal integration as separate channels The ESPR registry is not the same thing as the public passport page or an operator's resolver. The Commission registry stores at least unique identifiers, and for products released for free circulation it stores the commodity code. The economic operator placing the product on the market or putting it into service uploads the registry data; the registry then communicates a unique registration identifier associated with the uploaded unique identifiers. That communication is expressly not proof of compliance. The Commission web portal is a separate public search and-compare layer for data included in passports, constrained by the access rights set in delegated acts. Customs integration is another channel: customs authorities verify, at minimum, that the unique registration identifier and commodity code correspond to data stored in the registry, and the registry is to interconnect with EU CSW-CERTEX for automated customs-system exchange. - Keep the operator passport store or service provider store distinct from the Commission registry upload. - Store registry payload mappings for unique product identifiers, unique registration identifiers, and relevant commodity codes. - Treat the Commission portal as a search and comparison surface, not as the only passport hosting model. - Build evidence that registry data stays current when product identifiers, commodity codes, or passport hosting details change. - Do not describe a registry acknowledgement as legal compliance approval. Sources for this answer: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Articles 13 to 15 define the Commission registry, public web portal, unique registration identifier, customs verification, commodity-code linkage, and EU CSW-CERTEX interconnection. ## Make access control part of the data model, not only the API gateway The ESPR requires free and easy access based on actor-specific rights, and it restricts rights to introduce, modify, or update passport data according to access rights specified in delegated acts. A useful architecture therefore marks each passport data element with audience, source, owner, update authority, verification status, and public or restricted presentation rules before it is exposed through any API. Resolver flows should support anonymous public access for general passport information and credentialed access for actors such as authorities, recyclers, repairers, refurbishers, remanufacturers, and other relevant parties. CIRPASS examples describe credentialed requests for more refined data and update endpoints, while ESPR leaves the exact digital credential procedures to implementing acts. Avoid claiming that one token format, identity framework, or API style is legally required unless the relevant EU act or harmonised standard says so. - Create a field-level access matrix for public users, economic operators, marketplaces, repairers, recyclers, market surveillance authorities, customs authorities, and service providers. - Separate read rights from introduce, modify, update, and withdraw rights. - Record which actor supplied each data element and which actor can correct it. - Expose public data without forcing a vendor-specific app where the carrier and link pattern can support ordinary web access. - Use credentials for restricted or update operations, but keep the credential mechanism replaceable until EU procedures and product-group rules are fixed. Sources for this answer: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Article 11 requires actor-specific access rights, restricted update rights, data authentication, integrity, security, privacy, and fraud avoidance. - [CIRPASS D3.2 DPP System Architecture](https://cirpassproject.eu/wp-content/uploads/2024/06/D3.2v1.9.pdf?ref=sorena.io) - CIRPASS role-based flows distinguish default public access from credentialed access for actors needing more refined DPP data or update capabilities. ## Avoid premature protocol and API mandates The safest public architecture statement is that the DPP must be interoperable, standards-based, searchable, machine-readable where appropriate, and transferable without vendor lock-in. It is not currently safe to state that every DPP must use REST, GraphQL, a specific decentralized identifier method, a specific barcode syntax, or a particular resolver implementation unless the product-group delegated act, harmonised standard, or adopted implementing rule requires it. For engineering work, define replaceable interfaces: carrier decoding, identifier normalization, resolver lookup, typed-link selection, data-source retrieval, credential verification, field-level filtering, registry upload, portal/search feed, and audit logging. This lets a team test architecture assumptions now while preserving the ability to swap standards or sector choices later. - Document protocol choices as implementation decisions, not as EU legal mandates. - Keep an identifier resolver abstraction so HTTP URI and other standards-based schemes can be supported where appropriate. - Use open data formats and semantic mappings so product-group data can interoperate across sectors and actors. - Plan batch lookup for professional buyers, authorities, and internal product reviews that receive lists of product identifiers. - Test failure modes such as stale links, 404 responses, operator insolvency, domain transfer, and backup-provider activation. Sources for this answer: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - ESPR sets open, interoperable, machine-readable, searchable, transferable, and vendor-lock-in requirements without naming a universal API protocol for all passports. - [CIRPASS D3.2 DPP System Architecture](https://cirpassproject.eu/wp-content/uploads/2024/06/D3.2v1.9.pdf?ref=sorena.io) - CIRPASS validates both HTTP URI and DID architecture options and highlights unresolved backup/archive details, supporting a replaceable rather than hard-coded resolver design. ## Architecture evidence to keep before launch A DPP architecture review should produce evidence that a visitor, authority, customs user, or downstream circular-economy actor can follow from the physical product to the right passport data. The evidence should show the carrier value, identifier level, resolver response, source links, role-based filtering, registry upload state, and backup behavior for representative products. The evidence file should also record open points. If a product group's delegated act has not yet specified exact carrier layout, data fields, access rights, or passport level, state that as an implementation dependency rather than filling the gap with unsupported dates, thresholds, or protocol requirements. The review should explicitly validate the update and recovery scenarios that visitors would expect to see in the full architecture: repairer updates, independent refurbisher handover, recycler reporting, remanufacturer replacement of the original passport, and fallback to a backup or archive after operator insolvency. - Data carrier sample, scan result, and decoded identifier for each product label or documentation placement. - Identifier register showing product, operator, facility, and any registry registration identifiers with version history. - Resolver test output showing typed links, public response, restricted response, and fallback behavior. - Access-right matrix mapped to each passport data field and actor class. - Registry and customs data mapping for unique registration identifier and commodity code where applicable. - Backup and persistence plan covering service-provider continuity, domain or endpoint changes, and expected product lifetime. - Validation notes for repair, refurbishment, remanufacturing, recycling, and market-authority access paths. Sources for this answer: - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - ESPR requires accurate, complete, up to date passport data, persistent identifiers, specified access periods, backup copies, registry upload, and authority/customs access. - [CIRPASS D3.2 DPP System Architecture](https://cirpassproject.eu/wp-content/uploads/2024/06/D3.2v1.9.pdf?ref=sorena.io) - CIRPASS identifies the need for validation of HTTP URI and DID architectures, plus backup and archive handling for out-of-business scenarios. - [ETSI TS 103 881 V1.1.1](https://www.etsi.org/deliver/etsi_ts/103800_103899/103881/01.01.01_60/ts_103881v010101p.pdf?ref=sorena.io) - ETSI identifies persistence, authenticity, integrity, verifiability, traceability, and accessible online information as important properties for DPP information over a circular product lifespan. *Recommended next step* *Placement: after evidence section* ## Review your DPP lookup architecture Map carriers, identifiers, resolver responses, access rights, registry fields, and backup behavior before committing to a protocol or vendor implementation. - [Open Research Copilot](/solutions/research-copilot.md): Check DPP architecture claims against cited EU and standards sources. - [Discuss DPP implementation](/contact.md): Review identifier, resolver, registry, and access-control assumptions with Sorena. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng?ref=sorena.io) - Primary legal source for DPP requirements, including data carriers, persistent unique product identifiers, access rights, registry, web portal, customs controls, and interoperability requirements. - Quote: "connected through a data carrier" - [CIRPASS D3.2 DPP System Architecture](https://cirpassproject.eu/wp-content/uploads/2024/06/D3.2v1.9.pdf?ref=sorena.io) - Technical architecture source for resolver concepts, product-identifier-centred flows, HTTP URI and DID options, typed links, credentialed role-based access, and backup/archive considerations. - Quote: "DPP information system architecture" - [ETSI TS 103 881 V1.1.1](https://www.etsi.org/deliver/etsi_ts/103800_103899/103881/01.01.01_60/ts_103881v010101p.pdf?ref=sorena.io) - Standards-oriented source for DPP information quality properties, product identifiers, data carrier versus online access tradeoffs, lifecycle updates, lookup services, and persistence needs. - Quote: "structured collection of product-specific data" ## Related Topic Guides - [Annex III Data Model Planning for EU Digital Product Passports](/artifacts/eu/digital-product-passport/annex-iii-data-model-planning.md): Plan EU Digital Product Passport data fields, identifiers, access rights, update owners, registry inputs, and evidence records against ESPR Annex III and product-specific delegated acts. - [Digital Product Passport vs Digital Twin](/artifacts/eu/digital-product-passport/dpp-vs-digital-twin.md): Compare EU Digital Product Passports with digital twins: legal access duties, identifiers, public and restricted data, evidence, governance, and reuse limits. - [Digital Product Passport vs Paper Product Passports](/artifacts/eu/digital-product-passport/dpp-vs-traditional-product-passports.md): Compare EU regulated digital product passports with paper, PDF, web, and internal product passports across access, identifiers, data carriers, restricted data, customs checks, registry, and interoperability. - [DPP customs access review workflow for ESPR products](/artifacts/eu/digital-product-passport/customs-access-review-workflow.md): Review public, restricted, and customs access for EU Digital Product Passports, including registry handoffs, portal access rights, and release-for-free-circulation evidence. - [DPP Data Governance RACI Template for EU Digital Product Passports](/artifacts/eu/digital-product-passport/dpp-data-governance-raci-template.md): Assign accountable owners for EU Digital Product Passport data, access rights, supplier inputs, resolver links, registry uploads, verification checks, and retained evidence. - [DPP data-model intake workflow for EU Digital Product Passports](/artifacts/eu/digital-product-passport/dpp-data-model-intake-workflow.md): A grounded intake workflow for EU Digital Product Passport data models: product group, delegated-act status, source owner, supplier data, access class, identifiers, carrier, checks, and publication readiness. - [DPP Governance, Verification and Audit Controls](/artifacts/eu/digital-product-passport/governance-verification-and-audit.md): Build EU Digital Product Passport governance controls for data owners, supplier evidence, access logs, validation checks, audit records, and product release gates. - [DPP QR code vs NFC data carrier choices under EU ESPR](/artifacts/eu/digital-product-passport/faq/qr-code-vs-nfc-carrier-choices.md): How to choose QR code, NFC, or another data carrier for an EU Digital Product Passport without assuming ESPR mandates one universal carrier. - [DPP registry and web portal integration under EU ESPR](/artifacts/eu/digital-product-passport/dpp-registry-and-web-portal-integration.md): Grounded guide to EU Digital Product Passport registry and web portal integration under ESPR, covering identifiers, data carriers, access rights, service providers, and lookup design. - [DPP vs Battery Passport: ESPR and Battery Regulation Comparison](/artifacts/eu/digital-product-passport/dpp-vs-battery-passport.md): Compare the ESPR Digital Product Passport framework with the EU Batteries Regulation battery passport by scope, timing, data, access rights, identifiers, registry, governance, and evidence. - [DPP vs EPREL Comparison](/artifacts/eu/digital-product-passport/dpp-vs-eprel.md): Compare the EU Digital Product Passport with EPREL: product-passport scope, energy-label database role, access model, identifiers, data carriers, and overlap limits. - [DPP vs GS1 Digital Link: Duties vs Standard](/artifacts/eu/digital-product-passport/dpp-vs-gs1-digital-link.md): Compare EU Digital Product Passport requirements with GS1 Digital Link: legal scope, identifiers, data carriers, access rights, registry, portal, customs checks, and implementation consequences. - [EU Digital Product Passport access: public, restricted, and customs views](/artifacts/eu/digital-product-passport/public-restricted-and-customs-access.md): How ESPR Digital Product Passport access should be split across public users, restricted actors, authorities, customs, the EU registry, and the web portal. - [EU Digital Product Passport Applicability Test](/artifacts/eu/digital-product-passport/applicability-test.md): Check whether an ESPR delegated act or battery passport rule may require a Digital Product Passport, which operator owns it, and what evidence to keep. - [EU Digital Product Passport architecture and integration](/artifacts/eu/digital-product-passport/architecture-and-integration.md): Grounded guide to EU Digital Product Passport architecture: data carriers, identifiers, access rights, registry, portal, supplier flows, customs checks, and governance. - [EU Digital Product Passport checklist](/artifacts/eu/digital-product-passport/checklist.md): A concrete EU Digital Product Passport readiness checklist covering product-group scope, passport fields, identifiers, data carriers, access rights, supplier evidence, registry preparation, and publication controls. - [EU Digital Product Passport compliance: ESPR requirements](/artifacts/eu/digital-product-passport/compliance.md): Grounded EU Digital Product Passport compliance guide covering ESPR passport data, identifiers, data carriers, access rights, registry readiness, supplier validation, and evidence. - [EU Digital Product Passport Data Carriers, Access Control, and UX](/artifacts/eu/digital-product-passport/data-carriers-access-control-and-ux.md): How to choose DPP data carriers, identifiers, access rights, and scanning UX under ESPR Articles 9-14, with QR, NFC, RFID, registry, and customs constraints. - [EU Digital Product Passport data requirements and fields](/artifacts/eu/digital-product-passport/data-requirements-and-fields.md): How to plan Digital Product Passport data fields under ESPR: delegated-act scope, Annex III data categories, access rights, customs data, and supplier validation. - [EU Digital Product Passport deadlines and compliance calendar](/artifacts/eu/digital-product-passport/deadlines-and-compliance-calendar.md): Grounded EU Digital Product Passport calendar for ESPR and battery passport milestones, with product-group dates flagged as dependent on delegated acts. - [EU Digital Product Passport FAQ](/artifacts/eu/digital-product-passport/faq.md): Direct answers on EU Digital Product Passport scope, creators, product groups, registry, customs checks, access rights, identifiers, data carriers, and governance. - [EU Digital Product Passport identifier and data carrier design](/artifacts/eu/digital-product-passport/unique-identifier-and-data-carrier-design.md): How to design Digital Product Passport identifiers, QR or other data carriers, resolver links, registry records, access paths, and evidence without overclaiming the EU rules. - [EU Digital Product Passport penalties and enforcement](/artifacts/eu/digital-product-passport/penalties-and-fines.md): What ESPR says about Digital Product Passport penalties, Member State fine rules, market surveillance, customs checks, and unresolved product-specific delegated acts. - [EU Digital Product Passport Product Group Readiness](/artifacts/eu/digital-product-passport/product-group-readiness.md): Prepare product groups for EU Digital Product Passport rules by tracking ESPR delegated-act status, data fields, suppliers, identifiers, access rights, and registry handoffs. - [EU Digital Product Passport requirements under ESPR](/artifacts/eu/digital-product-passport/requirements.md): source-linked overview of EU Digital Product Passport requirements under ESPR: product-specific delegated acts, data fields, identifiers, carriers, registry, access rights, supplier data validation, and open points. - [EU Digital Product Passport supplier data validation controls](/artifacts/eu/digital-product-passport/supplier-data-validation.md): Build a supplier data validation file for EU Digital Product Passports: source owner, product link, access class, data model fit, evidence quality, approval record, and release gate. - [EU DPP customs access: registry, portal, and restricted data](/artifacts/eu/digital-product-passport/faq/customs-access.md): FAQ on customs access under the EU Digital Product Passport: what customs can verify, how the registry and public portal differ, and how access rights limit DPP data. - [EU DPP implementation playbook and vendor selection](/artifacts/eu/digital-product-passport/implementation-playbook-and-vendor-selection.md): Select Digital Product Passport vendors against ESPR requirements for identifiers, data carriers, access rights, decentralized storage, registry readiness, portal access, and verification evidence. - [EU DPP Product-Group Readiness Checklist](/artifacts/eu/digital-product-passport/product-group-readiness-checklist.md): A source-grounded checklist for preparing a product group for an EU Digital Product Passport delegated act, covering data fields, suppliers, identifiers, carriers, access rights, and registry readiness. - [EU DPP QR Code and Data Carrier Implementation Guide](/artifacts/eu/digital-product-passport/dpp-qr-code-implementation-guide.md): Grounded guidance for using QR codes and other data carriers in EU Digital Product Passport programs, including unique identifiers, access, resolver testing, and evidence. - [EU DPP supplier data validation workflow](/artifacts/eu/digital-product-passport/supplier-data-validation-workflow.md): A grounded workflow for checking supplier data before it is used in an EU Digital Product Passport, covering product linkage, evidence, owners, access class, and approval records. - [EU DPP unique identifier requirements: product, operator and facility IDs](/artifacts/eu/digital-product-passport/faq/unique-identifier-requirements.md): FAQ on how ESPR Digital Product Passport identifiers connect products, economic operators, facilities, data carriers, resolvers and registry evidence. - [Public vs restricted EU Digital Product Passport data](/artifacts/eu/digital-product-passport/faq/public-vs-restricted-passport-data.md): How to separate public, restricted, authority, and customs access in EU Digital Product Passport designs under ESPR and battery passport rules. - [What is a Digital Product Passport under ESPR?](/artifacts/eu/digital-product-passport/what-is-a-dpp.md): A visitor-friendly explanation of EU Digital Product Passports under ESPR: product data, identifiers, data carriers, access rights, registry, web portal, and delegated acts. - [What is the EU Digital Product Passport registry?](/artifacts/eu/digital-product-passport/faq/dpp-registry.md): FAQ on the ESPR Digital Product Passport registry: what it stores, who uploads data, how identifiers work, and what teams should avoid assuming. - [Which products come first for the EU Digital Product Passport?](/artifacts/eu/digital-product-passport/faq/which-products-come-first.md): FAQ on EU Digital Product Passport product priority: batteries have a separate passport rule, while ESPR product groups depend on the working plan and delegated acts. - [Who must create an EU Digital Product Passport?](/artifacts/eu/digital-product-passport/faq/who-must-create-a-digital-product-passport.md): DPP responsibility under the EU ESPR: how manufacturers, importers, distributors, suppliers, service providers, and delegated acts fit together. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-product-passport/api-and-resolver-architecture