“Seamless ERP integration” is a standard promise that in practice is followed by a three-month project. We publish our API playbook so that your IT can check, before signing the contract, what is actually queried. Here is what you should know before an integration project.
What your ERP actually has to deliver
For a DPP to be created, we need per product:
- master data - article number, designation, variants, weights, dimensions, images
- bill-of-materials data - components with quantities and recycled-content shares
- origin data - place of production, batch number, production date
- environmental data - CO2eq per unit, water consumption, energy consumption
- supplier data - who supplies which component (for due diligence)
In your ERP this data is theoretically all present. In practice it is spread across 4 to 7 modules: materials management (MM), production (PP), quality (QM), supplier (LFA1), sometimes a separate EHS module for environmental data, sometimes a PLM system for formulations.
The integration question is not: “Does your ERP deliver data to a DPP?” It is: “How do you bring the data from 5 subsystems together into one coherent data set?”
Three proven integration patterns
Pattern 1: OData / REST pull
Works well with modern ERPs (SAP S/4HANA Cloud, Dynamics 365, Odoo). The DPP provider pulls data via OData or REST. Incrementally, scheduled or event-driven.
Advantages: little development on your side, you provide read credentials, the provider builds the transformation.
Disadvantages: does not work with older SAP ECC installations without an additional API layer. You need governance over data access requests.
Pattern 2: event-based integration
SAP Event Mesh, Apache Kafka, RabbitMQ. Your ERP publishes change events, the DPP provider consumes them.
Advantages: near real-time, elegantly scalable, decoupled.
Disadvantages: the set-up is demanding and needs infrastructure that not every IT department has. For smaller firms usually overkill.
Pattern 3: middleware / ETL
You have an integration layer (Mulesoft, Boomi, Informatica, Azure Data Factory) between the ERP and external systems. The middleware is the contract - the DPP provider talks to the middleware, never directly to the ERP.
Advantages: existing investments can be used, governance is stable, no direct ERP access for third parties.
Disadvantages: your middleware costs scale with it.
What we do differently in concrete projects
Many providers want to connect directly to your ERP. As a matter of principle, we build in an intermediate step: our API accepts a neutral JSON schema that you fill with a tool of your choice. This means:
- you can do the data preparation yourself, with the tools your team knows
- you can replace us - the neutral format is portable
- you retrieve your entire inventory at any time - as CSV, XLSX, JSON-LD and SQL as well as via the REST API
- we provide an import validator that checks your data before the upload
The complete schema and all endpoints are publicly documented as an OpenAPI specification under /apidocs. Your IT can examine the interface before a contract is signed - including example requests, error responses and authentication details.
Timeframe with this approach in practice:
- day 1 to 2: mapping workshop. Which ERP field becomes which DPP field?
- day 3 to 5: first JSON exports from the ERP, through our validator.
- day 6 to 8: error fixing (missing fields, inconsistent codings).
- day 9 to 10: first DPPs are live.
Two weeks, not three months. The crux is the mapping workshop - that is where data quality is decided.
What goes wrong: the most common pitfalls
Product master data in several systems: SAP has the article number, the PIM has the images and marketing texts, the PLM has the bill of materials. Nobody has a consistent picture. Solution: define before the project which system is the “source of truth” for which field.
Certificates as PDF: suppliers deliver GOTS, OEKO-TEX or REACH certificates as a PDF scan. That is not a structured data source. Solution: certification operators increasingly offer API queries (OEKO-TEX is ahead, GOTS lags behind). Or: capture manually, but with a validity date so that no expired certificates appear in the DPP.
Formulation confidentiality: especially in cosmetics, food and pharma: the complete formulation is a trade secret. The DPP is supposed to make it public? Solution: the ESPR three-level model. Publicly the product category is shown, authorities see the full formulation. Almost never a blocker, but it has to be clarified early.
CO2 data on a supplier basis: your supplier gives an average value for its entire portfolio, not per batch. Solution: accept it temporarily, adjust supplier contracts in the long term. The ESPR requires product-specific values from a certain deadline, but current practice is a compromise.
Local language versions: your ERP contains the product designation only in German and English. For 27 EU countries you need more. Solution: machine translation with a terminology database; we have a separate article on this.
The questions you should ask before the project
Before you send an RFP to three providers, answer internally:
- How many products/article numbers should have DPPs? (10, 10,000, 1 million?)
- Which systems hold DPP-relevant data today?
- Which department administers each of the systems?
- Do you have a middleware investment that should be used?
- Is there an already working API layer on top of your ERP?
The answers determine which of the three patterns fits you. And they decide whether a project takes two weeks or six months.