Why integration should come after the process is understood—not before
During a small Digital Product Passport pilot, manual data entry is not necessarily a problem.
It can actually be useful.
The team learns which fields matter.
Which data is missing.
Which sources are reliable.
Which approval steps are necessary.
But manual work becomes difficult at scale.
Imagine creating passports for 50,000 product variants.
Copying information from ERP into a DPP platform manually is slow and risky.
This is where APIs and system integration become valuable.
What is an API in practical terms?
An API allows systems to exchange data automatically.
For example:
ERP sends product code and batch.
PLM sends composition and BOM.
Compliance platform sends certificate status.
DPP platform receives the approved data.
The employee does not need to type the same information again.
Integration should eliminate duplication
A bad integration copies every field without understanding it.
A good integration solves a specific problem.
For example:
Employees currently enter GTIN in three systems.
Integrate it once from the master source.
Certificate status currently changes manually.
Allow the compliance system to update it.
Supplier facility data is maintained centrally.
Reuse that record instead of recreating it.
Automation should reduce repeated work.
Open architecture matters
ESPR requires Digital Product Passport data to be built around open standards and interoperable, transferable information without vendor lock-in.
This makes API capability particularly important when evaluating DPP platforms.
Ask:
Is the API documented?
Can we read data?
Can we write data?
Can we export records in bulk?
Can other authorised systems access information?
What happens if the platform changes?
Integration is also part of long-term portability.
Use standards where practical
Standards reduce the number of custom connections required between companies.
GS1 Digital Link, for example, provides standardised representation of GS1 identification keys within web addresses and can support links to multiple online resources through resolver services.
Standards do not remove all integration work.
But they create a common language.
Start with high-volume fields
Do not integrate 200 fields immediately.
Find the information causing the most repetitive work.
Usually this includes:
product identifiers
style information
composition
supplier references
production batch
certificate status
Start there.
Then expand once the value is proven.
Monitor integration errors
Automation can make mistakes faster too.
If the wrong source data feeds thousands of passports, the error scales immediately.
Integration needs:
validation
error logs
alerts
approval where appropriate
reconciliation
The goal is controlled automation.
Not blind automation.
Key Ideas
- Manual data entry is acceptable during early learning and pilots.
• APIs become valuable when data volume and repetitive work increase.
• Integration should reuse approved sources rather than create additional copies.
• Open architecture and portability matter for DPP.
• Standards can reduce integration complexity.
• Start automation with high-volume, stable fields.
• Automated data still requires validation and monitoring.
Conclusion
The best time to integrate is not:
“as soon as possible.”
It is:
when the process is understood well enough to automate correctly.
At QUIVK, we believe the sequence should be:
Understand.
Pilot.
Standardise.
Integrate.
Scale.
That creates automation around a good process instead of making a bad process faster.
