Source systems
ERP, PLM, PIM, MES, QMS, service and supplier records
Enterprise integration guide
Digital Product Passport API and ERP/PLM Integration
Connect governed product data from existing enterprise systems to a secure, maintainable Digital Product Passport—without creating another manual data silo.
ERP and PLMAPI-led exchangeData governanceLifecycle integration
Integration principle
Reuse authoritative data; do not duplicate its ownership
Most manufacturers already hold product information across ERP, PLM, PIM, MES, QMS and service applications. The DPP layer should map, validate and publish the required information while leaving each source system accountable for the fields it owns.
The essential work is not simply connecting two APIs. It is agreeing identity, semantics, access rights, version behaviour and what should happen when source data is incomplete, conflicting or changes after publication.
Reference architecture
From enterprise source to governed passport
Integration layer
Authentication, mapping, transformation, validation and retry
UniQorn Trace
Identity, templates, evidence, permissions, versions and lifecycle
Access and exchange
QR/NFC resolver, public or restricted views and permitted APIs
A stable identity connects every layer
System-specific record IDs should map to governed product, batch or item identifiers. Free-text names are not a reliable integration key.
Source-system roles
What each enterprise system can contribute
ERP
Product codes, organisations, suppliers, orders, batches and commercial master data
PLM
Engineering specifications, materials, bills of materials, revisions and approved designs
PIM
Market-facing product attributes, descriptions, media and channel-ready information
MES / QMS
Manufacturing context, quality results, release status and production evidence
Service / CMMS
Inspection, maintenance, repair, replacement and asset-status events
Supplier systems
Material declarations, component evidence and governed upstream data
Data ownership
Assign one accountable source for every field
A field-level data contract should define the system of record, DPP representation, owner, format, validation, access class and update trigger.
| Example data | Typical owner | DPP treatment |
|---|---|---|
| Product code and commercial owner | ERP | Reference or validated copy |
| Material and engineering revision | PLM | Versioned structured field |
| Manufacturing and quality evidence | MES / QMS | Evidence link or approved result |
| Public description and imagery | PIM | Published passport content |
| Inspection and repair history | Service / CMMS | Append-only lifecycle event |
| Passport identity, access and publication | UniQorn Trace | Authoritative DPP control |
Exchange patterns
Use the simplest reliable integration that meets the need
Scheduled synchronisation
Import approved changes at a controlled interval when real-time updates are unnecessary.
Event-driven exchange
Create or update DPP records when a source system emits a relevant product, release or lifecycle event.
On-demand API
Retrieve or submit governed data when a user or business process needs it.
Controlled batch import
Use validated CSV or structured files for pilots and legacy environments before deeper integration.
Security and reliability
An integration is only useful if its data can be trusted
Technical controls must reinforce tenant isolation, publication integrity and accountable lifecycle history—not merely move records between systems.
Explore DPP access controls- Authenticate every system and service account
- Authorise access by tenant, role and permitted scope
- Validate identifiers, types, units and mandatory fields
- Preserve source, timestamp and transformation lineage
- Make published passport versions immutable
- Retry safely without creating duplicate products or events
- Log failures and route exceptions to an accountable owner
- Separate public data from restricted commercial evidence
EU DPP Registry boundary
Registration is not the same as hosting the full passport
The EU DPP Registry stores required identifiers, registration data and high-level metadata. Detailed DPP content remains decentralised under the responsibility of the relevant economic operator or its service provider.
The Registry supports both a secure user interface and API registration, allowing integration where appropriate. Product-specific legislation still determines when registration is required and which data must be supplied.
Keep three interfaces distinct
Enterprise integration
Moves governed data between manufacturer systems and the DPP platform
Passport access
Serves permitted product information to people and systems
Registry integration
Registers the legally required identifiers and metadata with the EU service
Integration pilot
Six steps from spreadsheet or source API to working DPP
Choose one product family
Use genuine source records, evidence and a manageable number of serialised or batch identities.
Define field ownership
For every DPP field, name its source system, business owner, validation and update trigger.
Agree the identity keys
Map product, model, batch, item, economic-operator and facility identifiers without fragile free-text matching.
Select an exchange pattern
Begin with a controlled import or API flow suited to the source system and operational need.
Transform and validate
Convert source values into the approved passport schema, units, vocabulary and access class.
Publish and reconcile
Test creation, correction, failure recovery, lifecycle updates and comparison back to the source.
Start with one controlled data flow
Connect a real product family to UniQorn Trace™
Map authoritative data, test identity and validation, publish the passport and prove how corrections and lifecycle updates behave before committing to enterprise-scale integration.
Common questions
DPP API and enterprise integration FAQ
Does a Digital Product Passport replace ERP or PLM?
No. ERP and PLM usually remain authoritative for the data they govern. A DPP platform assembles the required product identity, evidence, permissions and lifecycle view while preserving clear ownership of every field.
What does a DPP API do?
A DPP API can exchange product masters, identifiers, structured attributes, evidence references, lifecycle events, publication status and permitted passport outputs with other systems. The exact contract depends on the product model and applicable requirements.
Is real-time integration always necessary?
No. Update frequency should follow business risk and the source data. A validated batch import may be appropriate for a pilot, while event-driven exchange may suit high-volume product creation or safety-relevant status changes.
Can UniQorn Trace connect to SAP, Oracle, Microsoft Dynamics or Siemens systems?
UniQorn Trace is designed for API-led integration, but a named native connector should only be treated as available after its scope, authentication, data mapping and end-to-end behaviour have been built and tested for the relevant environment.
How does the EU DPP Registry fit into the architecture?
The Registry stores required identifiers, registration data and high-level metadata rather than the complete decentralised passport dataset. Its secure API can support registration from existing systems, subject to the applicable legislation and technical onboarding.
How should manufacturers begin DPP integration?
Start with one representative product family, establish field ownership and identity mapping, then test one controlled data flow through validation, publication, correction and reconciliation before scaling.
Primary sources
See Regulation (EU) 2024/1781, particularly Articles 10–13, and the European Commission DPP Registry guidance. Confirm current product-specific legislation and technical specifications before implementation.
Editorial note: This guide describes integration architecture and is not legal advice or a claim that a named third-party connector is already available.